#8857·typst

`repr` of a fully-auto stroke denotes a different value than the stroke itself

Author: sghngCreated Sep 15, 2026Updated Sep 15, 2026
Labelsbug

Description

#repr(stroke())  // "1pt + black"
#repr(stroke(1pt + blakc))  // "1pt + luma(0%)"

So we have funny behaviors such as

#stroke() == stroke(black)          // false
#stroke() == stroke(1pt)            // false
#stroke() == stroke(1pt + black)    // false
#stroke() == eval(repr(stroke()))   // false

The other simple-stroke repr forms are faithful. A bare color or length casts back to the same stroke value wherever a stroke is expected, keeping the remaining fields auto, and the combined form even round-trips through eval:

#(2pt + red) == eval(repr(2pt + red))  // true

The all-auto case is a hardcoded string in crates/typst-library/src/visualize/stroke.rs (line 321, v0.15.1):

(Smart::Auto, Smart::Auto) => r.push_str("1pt + black")

Found while matching implementing Typst stroke support for pandoc: https://github.com/jgm/typst-hs/pull/76#discussion_r4011113216

Operating system

macOS

Typst version

  • I am using the latest version of Typst