Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typst - do not hardcode #figure() in Table writer? #9777

Closed
cscheid opened this issue May 20, 2024 · 3 comments · Fixed by #9778
Closed

Typst - do not hardcode #figure() in Table writer? #9777

cscheid opened this issue May 20, 2024 · 3 comments · Fixed by #9778
Labels

Comments

@cscheid
Copy link
Contributor

cscheid commented May 20, 2024

Would Pandoc take a PR that enabled the Typst writer to disentangle the emission of #figure() from #table()? Or, minimally, a PR that would stop Pandoc from emitting #figure() when no caption or identifier are present?

Explain the problem.

Pandoc currently is unable to emit table code in Typst without also emitting a figure(): https://github.com/jgm/pandoc/blob/main/src/Text/Pandoc/Writers/Typst.hs#L276-L294

$ pandoc -f markdown -t typst
| f | b |
|---|---|
| 1 | 2 |
#figure(
  align(center)[#table(
    columns: 2,
    align: (auto,auto,),
    table.header([f], [b],),
    table.hline(),
    [1], [2],
  )]
  , kind: table
  )

This makes it quite hard to write Pandoc documents that put a Typst table inside a crossref environment of any other kind, or that would include a table without incrementing the table typst counter by virtue of the surrounding #figure().

Typst figures accept kind variables other than table and figure. Notably, we use that in Quarto for subfigures and custom crossrefs ("Supplemental Table..."). In Pandoc 3.2, counters will be necessarily incorrect (and hard to fix) when users refer to tables in different environments.

Pandoc version?

$ pandoc --version
pandoc 3.2
Features: +server +lua
Scripting engine: Lua 5.4
User data directory: /Users/cscheid/.local/share/pandoc
Copyright (C) 2006-2024 John MacFarlane. Web: https://pandoc.org
This is free software; see the source for copying conditions. There is no
warranty, not even for merchantability or fitness for a particular purpose.
@jgm
Copy link
Owner

jgm commented May 20, 2024

I think it would make sense to omit the figure when there is no caption. That would be an easy change.

The only other thing needed, then, would be a way to affect the kind.
Would it be terrible to make typst:kind="foo" do this? Technically the kind property belongs to the enclosing figure, but since the table itself can't have a kind property, that doesn't lead to any ambiguity. I'm just trying to avoid a proliferation of slightly different syntaxes for affecting typst stuff.

@cscheid
Copy link
Contributor Author

cscheid commented May 20, 2024

I think it would make sense to omit the figure when there is no caption. That would be an easy change.

Ok. I can make that change in my PR. For what's worth, that's what I used in my original attempt, but I realized two things:

  1. This behavior is inconsistent with Table in other writers, and would break existing Pandoc behavior. The LaTeX writer uses longtable which automatically bumps LaTeX's table counter specifically. (It would be nice if longtable* were used in caption-less tables in LaTeX, but that's a different story)
  2. The explicit choice to not use #figure() allows the resulting code to not have the alignment call #align(center)[...]. That has some minor benefits for users that want the "pure" table output. If we make the change to detect captions, then a separate decision needs to be made about alignment and, in that case, I think it would be useful to have an option that omits the alignment as well.

Would it be terrible to make typst:kind="foo" do this?

I think using colons would be great. I like that kind is short, but looking to the future, the word kind is overloaded for both figure kinds and gradient kinds: https://typst.app/docs/reference/visualize/gradient/#definitions-kind and https://typst.app/docs/reference/model/figure/#parameters-kind.

I'm just trying to avoid a proliferation of slightly different syntaxes for affecting typst stuff.

I hear you. I should have remembered that our earlier Typst properties work used colons instead of dashes. I'll definitely fix that.

@cscheid
Copy link
Contributor Author

cscheid commented May 20, 2024

In #9778:

  • I changed the attribute from typst-figure-kind to typst:figure:kind (though I'm open to typst:kind if you prefer terseness over the ambiguity with the gradient attribute)
  • I changed the class from typst-no-figure to typst:no-figure. I haven't changed the logic to detect the lack of captions and use the "no-figure" mode before I heard a response from you wrt consistency with the LaTeX writer and alignment configuration.

@jgm jgm closed this as completed in #9778 Jun 3, 2024
jgm pushed a commit that referenced this issue Jun 3, 2024
…#9778)

This extends support for fine-grained properties in Typst.

If the `typst:no-figure` class is present on a Table, the table will not be placed in a figure.

If the `typst:figure:kind` attribute is present, its value will be used for the figure's `kind`.

These features are documented in `doc/typst-property-output.md`.

Closes #9777.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants