Using markup in crossref labels?

[iandol]

Description

I would like to use strong emphasis for my figure labels.

![**figure description** — legend content](figure){#fig-one}

But when this is rendered (to DOCX or HTML at least) I get something like:

Figure 1: figure description — legend content

How can I get the crossref generated "Figure 1:" text to be bold. Markup is not accepted within the {}, but I can put fig-title: "**Figure**" in the metadata but it fails to apply to the number. Markup works in title-delim but not labels.

Minimal sample doc:

---
title: Legend Test
author: Jane Doe
crossref:
  fig-title: "**Figure**"
  labels: "**alpha a**"
  title-delim: "**:**"
---

# Test

Text.

![**figure description** — legend content](Fig1){#fig-one}

Text, please see **@fig-one**.

[cscheid]

Unfortunately that's not trivial to do, because it involves changing the code that renders a Figure (and Table, Listing, etc). In 1.4 prereleases, what you can do is write an empty Lua filter which installs a custom FloatRefTarget renderer for the docx format, taking over the rendering process entirely.

We don't have great documentation for that yet, but the skeleton to get started is here: https://quarto.org/docs/prerelease/1.4/lua_changes.html#custom-formats-and-custom-renderers

The docx renderer for FloatRefTarget nodes is here: https://github.com/quarto-dev/quarto-cli/blob/main/src/resources/filters/customnodes/floatreftarget.lua#L370-L437 You'll want to start there.

If you want to change the rendering in HTML formats, then you'll also need to install a custom HTML renderer. That code is here: https://github.com/quarto-dev/quarto-cli/blob/main/src/resources/filters/customnodes/floatreftarget.lua#L350-L368C5

[iandol]

OK, thank you for the workarounds

[cscheid]

workarounds

Just to set the expectations clear, these are not workarounds: they are the mechanisms by which users extend formats (which is what you're intending to do).

We indeed still need to do a good amount of work on our side in creating reusable portions of the work in our Lua API so that this kind of extension is easier to write. Nevertheless, the long-term direction in the project is to enable general extensibility in this way, because it's not feasible to create configuration options to cover everyone's requests cleanly.