cross references not working in typst

[edenian-prince]

Description

I get this error when I try to make a cross reference when outputting to the Typst format:

[typst]: Compiling index.typ to index.pdf...error: cannot access fields on type auto
    ┌─ index.typ:108:26
    │
108 │   let sup = it.supplement.text.matches(regex("^45127368-afa1-446a-820f-fc64c546b2c5%(.*)")).at(0, default: none)
    │                           ^^^^

Here's a reprex - see the @fig-idk reference and how it doesn't work:

index.qmd

---
title: hello
author: me
format: 
  typst: 
    columns: 1
    number-sections: true
  native: default
  html: default
---


# Header
some text

# Another Header

gonna put an image here - 

![an image with a caption](assets/nwpage_logo.png){#fig-idk fig-align="center"}


i cannot reference the image in typst like this:

reference @fig-idk - this errors out


a weak work around that isn't really a work around is removing the reference:

some caption here referencing [@fig-idk]{.content-visible when-format="pdf"}

This might just be a Typst problem, but would appreciate if someone has thought of a workaround. I'm trying to figure out how I can lua filter my way out of this but it has been challenging

quarto check

Quarto 1.5.22
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.11: OK
      Dart Sass version 1.69.5: OK
      Deno version 1.37.2: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.5.22
      Path: /opt/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: (not installed)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Tex:  (not detected)

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.11.7 (Conda)
      Path: /home/frank/anaconda3/bin/python
      Jupyter: 5.5.0
      Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.4.0
      Path: /opt/R/4.4.0/lib/R
      LibPaths:
        - /home/frank/R/x86_64-pc-linux-gnu-library/4.4
        - /opt/R/4.4.0/lib/R/library
      knitr: (None)
      rmarkdown: (None)

      The knitr package is not available in this R installation.
      Install with install.packages("knitr")
      The rmarkdown package is not available in this R installation.
      Install with install.packages("rmarkdown")

[edenian-prince]

I also tried to label the figure different but get the same error

:::{#fig-idk}
![a cap](assets/nwpage_logo.png)
:::

```{r}
#| label: fig-idk
knitr::include_graphics('./assets/nwpage_logo.png')

[cscheid]

I can't reproduce on main. Can you try https://github.com/quarto-dev/quarto-cli/releases/tag/v1.5.43?

[cderv]

So here is what I did to reproduce

• Set QUARTO_TYPST to a newer version of Typst (the one in Quarto 1.5 with version 0.11.0)
• Run quarto render with Quarto 1.4.455

This means that Quarto 1.4 is now running Typst 0.11.0 instead of 0.10.0 is this is not expected. The source of the bug if from here because now Quarto 1.4 with Pandoc 3.1.11 is producing a .typ file that is not compatible with Typst 0.11.0

I use NixOS, so i used the quarto-package that is provided by nixpkgs.
Unfortunately distributed binaries dont work on NixOS, so they just remove the bin/tools directory in the finished package.
They wrap the quarto program with the definition of the env-variable QUARTO_TYPST, but this points to the newest version of typst available in nixpkgs. This is also why there is (unknown hash) inside of the version number, i guess.

This is the problem and you should report to the persons who are packaging quarto for NixOS. A quarto version should only be used with the tools version that are defined in configuration and for Quarto 1.4 this is

quarto-cli/configuration

Line 17 in 1f5fd5e

export TYPST=0.10.0

So they should be sure to use this specific version.

@cscheid what about throwing a warning of even an error if we detect that the tools version is not the one expected by Quarto ?
AFAIK we currently do not check this and do not throw warning even in quarto check.

[cscheid]

@cscheid what about throwing a warning of even an error if we detect that the tools version is not the one expected by Quarto ?
AFAIK we currently do not check this and do not throw warning even in quarto check.

Yes, that's a very good idea. (To be perfectly frank, it shouldn't be our responsibility to ensure "Quarto" works when third parties package a broken version and we don't. But here we are.)

[mcanouil]

In some regards, related to:

• How to use the pre-installed deno executable? #10028

[cderv]

(To be perfectly frank, it shouldn't be our responsibility to ensure "Quarto" works when third parties package a broken version and we don't. But here we are.)

This is what I thought initially, then I told myself that we added env vars that act as escape hatch to use other than the included versions of tools and so I came to the conclusion this our responsibility to make it clear that when they are used, this is not ok

• either being very strict and not allowing different version than expected - only different path
• or being less strict but making clear this is not expected version which used and even unwarranted, at user's risk and prone to error 😅

I'll make an issue to make this happen

[cderv]

• Check for tools version when not expected ones are used  #10047