Figure width is not respected when using CairoMakie

[tpoisot]

Description

I am running into a problem with quarto 1.5.47 when generating a pdf from a file using CairoMakie to generate the figures. Specifically, there seems to be no way to get the figures in the PDF to use the textwidth.

This used to work on previous versions of quarto, and this is not an issue with e.g. pandoc, for the record.

Here is an example document that shows the issue: the scatter plots overflow from the text.

---
title: "Untitled"
format: pdf
engine: julia
---

```{julia}
import Pkg
Pkg.activate(joinpath(homedir(), ".julia", "environments", "v1.10"))
```

```{julia}
using CairoMakie
```

Plot with no options

```{julia}
scatter(rand(1000))
```

Plot with size options

```{julia}
#| fig-width: 100%
scatter(rand(1000))
```

[cscheid]

In Jupyter, we currently only support fig-width etc as a document-wide option.

[tpoisot]

Sure, but even this is not working. Maybe this is because I'm using engine: julia.

Regardless -- is there a way to ensure that in the PDF, figures do not get larger than \textwidth?

[tpoisot]

I've been trying to troubleshoot this a little bit more, and the documentation says

By default figures are displayed using their actual size (subject to the width constraints imposed by the page they are rendered within). You can change the display size by adding the width and height attributes to the figure.

This refers, I suppose, to the fact that my .tex output will get something like:

\includegraphics[width=20.83333in,height=20.83333in]{chapters/classification_files/figure-pdf/fig-classification-decision-output-1.png}

which should not overflow from the page because the template includes

\usepackage{graphicx}
\makeatletter
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
\makeatother
% Scale images if necessary, so that they will not overflow the page
% margins by default, and it is still possible to overwrite the defaults
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}

And yet - the figures do overflow:

[cscheid]

Here's a relevant part of the keep-md: true output:

::: {.cell execution_count=1}
``` {.julia .cell-code}
f = Figure(; size=plotsize)
ax = Axis(f[1,1])
scatter!(ax, rand(100))
f
```

::: {.cell-output .cell-output-display execution_count=1}
![](issue-10602_files/figure-pdf/cell-6-output-1.png){width=1885 height=942 fig-pos='H'}
:::
:::

This is the source of the problem, and there's not much that Quarto can do here. Those width and height values (width=1885 height=942) are going to be interpreted in inches, and so that's going to cause trouble.

The next step is to understand why those values are being provided like that, but I'm not a CairoMakie expert (or even user), so I can't help much.

@jkrumbiegel, sorry to tag you here, but maybe you have some input on what's going on here?

[tpoisot]

A workaround is to specify a higher DPI and a value of px_per_unit in CairoMakie, then to scale figures very explicitely by knowing their physical dimension. For example, a 7in by 6in figure with dpi: 600 and px_per_unit=5 needs to have the following dimensions:

f = Figure(; size=(7, 6).*(600/5))

For the specific document in which I'm having this problem, this works since I know the exact dimension of the textbox.

[jkrumbiegel]

So I've run a little test. This is the notebook I ran, once with fig-dpi: 96 and once with fig-dpi: 192:

---
title: "Untitled"
format: pdf
engine: julia
keep-md: true
fig-dpi: 96
execute: 
  daemon: false
---

```{julia}
using CairoMakie

function testfig(size, px_per_unit)
    f = Figure(; size, backgroundcolor = :tomato)
    Label(f[1, 1], "$size\npx_per_unit=$px_per_unit", fontsize = 20)
    f
end

testfig((200, 100), Makie.current_default_theme()[:CairoMakie][:px_per_unit][])
```

```{julia}
testfig((300, 200), Makie.current_default_theme()[:CairoMakie][:px_per_unit][])
```

This is the result for 96 dpi, the px_per_unit value is set to 1.0 (this is done by a CairoMakie package hook within QuartoNotebookRunner which picks up fig-dpi):

and in the intermediate md, I get these sizes annotated for the images:

width=200 height=100
width=300 height=200

This is the result for 192 dpi, the px_per_unit value is set to 2.0 instead:

and in the intermediate md, I get these sizes instead:

width=400 height=200
width=600 height=400

So what can we conclude from that?

• CairoMakie picks up the fig-dpi and sets px_per_unit to figdpi / 96. This is correct because one "unit" in CairoMakie is a CSS pixel and there are 96 of these in an inch. So for 96 dpi or pixels per inch we need a px/unit ratio of 1.
• The pixel sizes of the rendered pngs correspond correctly to that, a 300x200 units figure has resolution 300x200 pixels when rendered with 96 dpi and 600x400 pixels when rendered with 192 dpi.
• The annotation in the intermediate md doesn't make sense, this just mirrors the pixel size of the png, but not the logical size of the image (which would correspond to the Figure(size = ...)). Because of this, images with higher dpi get blown up in the resulting latex doc. The two images in doc 1 should be the same resulting size as in doc 2.

If I render only an ipynb with QuartoNotebookRunner directly, I find these pieces of metadata in there:

"data": {
                        "image/png": some image data
                    "metadata": {
                        "image/png": {
                            "width": 300,
                            "height": 200
                        }
                    }

These width/height things just report the pixel resolution of the png image. I assume that this is where the problem originates, although I'm not sure if quarto uses this value incorrectly as a logical size or QuartoNotebookRunner should populate this differently, as a logical size and not a resolution.

[cscheid]

This is super helpful, @jkrumbiegel, thank you! One small comment:

If I render only an ipynb with QuartoNotebookRunner directly

Quarto's jupyter engine detects and handles a keep-ipynb: true option, and produces a document_name.quarto_ipynb file, which holds the .ipynb result of executing the code before converting it to Markdown for further processing. I wonder if it makes sense for the julia engine to do so as well.

[jkrumbiegel]

Mentioning here that I'm planning to have QuartoNotebookRunner write a dpi-corrected size into this metadata field if dpi is available in the png file PumasAI/QuartoNotebookRunner.jl#248

If not, images will continue to be sized as if they had 96 dpi, as it currently works.