Possible Typst writer extensions

[wlupton]

Please see lvignoli/typst-pandoc#3 for some experimental Typst custom writer updates. I'd like to kick off a discussion here, perhaps resulting in some agreed enhancements to the official Haskell Typst writer.

My central desire was to be able to pass attributes to Typst. For example, with this input:

% cat note.md
::: note
This is a note.
:::

...the current (3.1.6.1) Typst writer gives this (attributes have been discarded):

% pandoc note.md -t typst
This is a note.

...but "my" Typst writer gives this (I've omitted some generated preamble):

% pandoc note.md -t writer.lua
...
#block[
This is a note.
] <cls:note>

Unfortunately, Typst doesn't support more than one label per element, so I've used nested box/block elements to permit this (example below), which works, but is messy (plus there are some edge cases). I've initiated a discussion about that on the Typst Discord server.

Thoughts?

---

More complex example, illustrating multiple attributes.

% cat note.md
::: {#my-note .note .other name=value}
This is a note.
:::

% pandoc note.md -t ../typst-writer.lua
...
#block[ #block[ #block[ #block[
This is a note.
] <name::value> ] <my-note> ] <cls:note> ] <cls:other>

[jgm]

Rendering a Div with an identifier as a block with a label might make sense, though I'm not sure it's better than what the typst writer currently does (put the label at the beginning of the Div's contents).

Abusing the label to represent a class does not seem right.

[wlupton]

Re identifiers, I don't think that the current behavior is correct, because "inserting a label into content attaches it to the closest previous element that is not a space", so in the following Typst fragment:

This is *a para*

<my-note>
This is *a note*

#[This is *another para*] <my-other-note>

<my-note> is associated with the preceding strong("a para"). I believe that <my-other-note> works as expected.

As for abusing a label to represent a class, if this was not intended then I wonder why show rules can be associated with labels. But anyway, I asked the Typst community and they agree that labels shouldn't be used for styling, and suggest using template functions. In other words, rather than this:

#show <note>: block.with(fill: blue.lighten(90%))
#[Note styled via label]<note>

do this:

#let note = block.with(fill: blue.lighten(90%))
#note[Note styled via template function]

I'll experiment with the template function approach.

[jgm]

I've fixed the label issue in commit cc371a9

I will close this issue but if you have particular suggestions for typst writer improvements they could go in separate issues.

[wlupton]

Thanks! BTW, I assume that we agree that something (as yet undetermined) has to be done with the note class here.

% cat note.md
::: note
This is a note.
:::

[jgm]

I don't agree that something has to be done with it. It depends what the options are in typst.
I wouldn't want to emit

#note[Note styled via template function]

because that breaks unless the note function has been defined. We don't want to make a change that will result in generating typst documents that don't compile.

A more conservative approach would be to hook up this behavior to an attribute like typst-style.

[wlupton]

One possible advantage of the label approach is that nothing will break if no Typst style is associated with the label (cf CSS). And one possible way round the fact that the note function would need to be defined is that it might be possible to define an empty function that could be overridden in a template (not sure; would have to check). We'd also have to think about namespace conflicts (note might be OK but block wouldn't be).

#[Note styled via label]<note>
#note[Note styled via template function]

If I understand you correctly, one problem with typst-style would be that the source markdown would have to change to support styled Typst output. I've so far managed to convert several quite complex documents to quite nicely styled Typst PDF without making a single change to the markdown. However, I guess there could potentially be a metadata item mapping pandoc classes to Typst template functions.

[jgm]

the source markdown would have to change to support styled Typst output

Not necessarily; you could use a small filter to populate typst-style with the existing class attribute.

[wlupton]

True. Thanks!