Description
Currently, only raw, image and table are figure kinds, that are recognized automatically. The default figure kind is image.
However, the allowed figure kinds span a lot more element function names. Below is a (probably incomplete) list of names I tried.
I just checked it and the behaviour is very inconsistent. I'll leave the text stuff out.
Allowed figure kinds, documented, behave as expected
Allowed figure kinds, not assigned automatically:
- math.equation
- outline
- bibliography
Allowed figure kinds, but need specification of supplement, not assigned automatically:
- grid
- list
- cite
- document
- figure (!)
- footnote
- quote
- enum
- par
- parbreak
- ref
- terms
Disallowed figure kinds:
Now I will argue for two things here:
- More things should have their kind automatically assigned in figures.
- The default figure kind should be figure instead of image.
The first point is very obvious, and doesn't break anything. The only real point to discuss, is if it makes sense to also automatically change the figure supplement. In my opinion this should be the case, as this is the current behaviour for tables, too.
I would recommend the following elements for automatic kind:
- enum/list/terms (obvious choice, often used in figures)
- quote
- math.equation
I don't see the others really making sense. All of the text functions are not used in figures, except in libraries. The others are rather structural elements, and I don't see a footnote or a ref/link/cite being used in a figure.
Now the second point is a bit more controversial but let me explain.
If we ever see svg (and pdf) figures to be modifiable inside a typst context, e.g. changing the font of an svg, the image kind will be used for doing these kind of stylings. figure is a more generic kind, that doesn't hint at a specific content type.
Use Case
The most obvious use is the easier use of more Model element functions in figures. For lists or quotes, it is not uncommon to feature a caption.
Now for math.equation there is another use case. Usually, equations are not placed inside figures. However, I needed an equation outline, and if you query for equations, this is akward, because the outline will look something like
- Eq.1 ...
- Eq.2 ...
...
It is rather nice, to assign titles to equations, be it only for the outline. Do achieve this, I used the following code.
#outline(target: selector(figure.where(kind: math.equation)))
#show figure: it => {
if it.kind == image and it.body.func() == math.equation {
return figure(it.body, caption: it.caption, kind: math.equation)
}
it
}
#show figure.where(kind: math.equation): it => {
it.body
}
The show rules achieve, what I propose to be the default. I don't think this use case is that uncommon.
Description
Currently, only raw, image and table are figure kinds, that are recognized automatically. The default figure kind is image.
However, the allowed figure kinds span a lot more element function names. Below is a (probably incomplete) list of names I tried.
I just checked it and the behaviour is very inconsistent. I'll leave the text stuff out.
Allowed figure kinds, documented, behave as expected
Allowed figure kinds, not assigned automatically:
Allowed figure kinds, but need specification of supplement, not assigned automatically:
Disallowed figure kinds:
Now I will argue for two things here:
The first point is very obvious, and doesn't break anything. The only real point to discuss, is if it makes sense to also automatically change the figure supplement. In my opinion this should be the case, as this is the current behaviour for tables, too.
I would recommend the following elements for automatic kind:
I don't see the others really making sense. All of the text functions are not used in figures, except in libraries. The others are rather structural elements, and I don't see a footnote or a ref/link/cite being used in a figure.
Now the second point is a bit more controversial but let me explain.
If we ever see svg (and pdf) figures to be modifiable inside a typst context, e.g. changing the font of an svg, the image kind will be used for doing these kind of stylings. figure is a more generic kind, that doesn't hint at a specific content type.
Use Case
The most obvious use is the easier use of more Model element functions in figures. For lists or quotes, it is not uncommon to feature a caption.
Now for math.equation there is another use case. Usually, equations are not placed inside figures. However, I needed an equation outline, and if you query for equations, this is akward, because the outline will look something like
...
It is rather nice, to assign titles to equations, be it only for the outline. Do achieve this, I used the following code.
The show rules achieve, what I propose to be the default. I don't think this use case is that uncommon.