GraphViz diagrams have fixed width, causing horizontal overflow on mobile

[jimjam-slam]

Bug description

Most chunk outputs are wrapped in a figure, then in a div.quarto-figure. The figure has width: 100% and the plot output itself (at least in the case of an img.img-fluid has max-width: 100%. All up, the plot shrinks from its native width at narrower widths.

GraphViz output appears to not be wrapped in .quarto-figure, so its enclosing figure does not receive width: 100%, and the sig itself has max-width: none, so it does not shrink from its native width, causing horizontal overflow.

I wondered if this might be coming from this SVG code in Quarto, but it looks like that's designed for a use case where an explicit height and width has been provided. I haven't in this case (unless that's something that GraphViz does under the hood). Not sure if this code is being inadvertently triggered, if it's triggered by design and I've missed something, or I'm incorrectly attributing the problem to this.

Steps to reproduce

Repro (already rendered): https://github.com/jimjam-slam/test-quarto-graphviz-sizing/tree/main

Expected behavior

For the GraphViz SVG to shrink proportionally to container width, as the R plot above it does.

Actual behavior

The SVG remains at its native width, causing a horizontal scrollbar to appear (sorry, it's one of those disappearing Mac ones, so you can't see the scrollbar in this screenshot).

(Have verified this on Edge 123 and Safari 17.2.1)

Your environment

macOS 14.2.1
VSCode 1.87.2

Quarto check output

Quarto 99.9.9
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.11: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.41.0: OK
      Typst version 0.10.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 99.9.9
      commit: 26172cb90eb6c2d41742df662771c1d4b2197a3f
      Path: /Users/rensa/code/quarto-cli/package/dist/bin

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

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/rensa/Library/TinyTeX/bin/universal-darwin
      Version: 2021

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

[✓] Checking Python 3 installation....OK
      Version: 3.9.7 (Conda)
      Path: /Users/rensa/miniforge3/bin/python
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with conda install jupyter

[✓] Checking R installation...........OK
      Version: 4.2.1
      Path: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources
      LibPaths:
        - /Users/rensa/Library/R/arm64/4.2/library
        - /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library
      knitr: 1.42
      rmarkdown: 2.21

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

[cderv]

Thanks for the report.

Some notes about this:

Diagram are supposed to be responsive by default as we document (https://quarto.org/docs/authoring/diagrams.html#sizing)
It happens at

quarto-cli/src/core/handlers/dot.ts

Lines 148 to 164 in d39cb2f

	if (
	isJavascriptCompatible(handlerContext.options.format) &&
	!isIpynbOutput(handlerContext.options.format.pandoc)
	) {
	const responsive = options?.[kFigResponsive] ??
	handlerContext.options.context.format.metadata
	?.[kFigResponsive];
	svg = (await parseHtml(svg)).querySelector("svg")!.outerHTML;
	if (
	responsive && options[kFigWidth] === undefined &&
	options[kFigHeight] === undefined
	) {
	svg = await makeResponsive(svg, fixupRevealAlignment);
	} else {
	svg = await setSvgSize(svg, options, fixupRevealAlignment);
	}

However, this won't apply ever I believe because even if a user does not define a fig-width or fig-height, one will be set by default for a format

quarto-cli/src/format/formats-shared.ts

Lines 197 to 204 in d39cb2f

	function defaultFormat(displayName: string): Format {
	return {
	identifier: {
	[kDisplayName]: displayName,
	},
	execute: {
	[kFigWidth]: 7,
	[kFigHeight]: 5,

So I don't think this has ever worked. It would probably need to be like when checking kfigResponsive and look into the context

quarto-cli/src/core/handlers/dot.ts

Lines 152 to 154 in d39cb2f

	const responsive = options?.[kFigResponsive] ??
	handlerContext.options.context.format.metadata
	?.[kFigResponsive];

using

index d20ebfdef..44fb3bea8 100644
--- a/src/core/handlers/dot.ts
+++ b/src/core/handlers/dot.ts
@@ -155,8 +155,10 @@ const dotHandler: LanguageHandler = {
 
       svg = (await parseHtml(svg)).querySelector("svg")!.outerHTML;
       if (
-        responsive && options[kFigWidth] === undefined &&
-        options[kFigHeight] === undefined
+        responsive && handlerContext.options.context.format.metadata
+            ?.[kFigWidth] === undefined &&
+        handlerContext.options.context.format.metadata
+            ?.[kFigHeight] === undefined
       ) {
         svg = await makeResponsive(svg, fixupRevealAlignment);
       } else {

But even this may not be enough here, because somehow the SVG created uses some unit pt

<svg width="135pt" height="169pt"

and the width value does not trigger the apply of the responsive

quarto-cli/src/core/svg.ts

Lines 222 to 226 in d39cb2f

	if (numWidth > 650) {
	changed = true;
	svg.setAttribute("width", "100%");
	svg.removeAttribute("height");
	}

and the final svg ends up with the pt size instead of the format defined size (that are set otherwise when not responsive)

quarto-cli/src/core/handlers/dot.ts

Lines 164 to 166 in d39cb2f

	}
	svg = mappedConcat(["```{=html}\n", svg, "\n```\n"]);

So definitely something to look into with this responsive feature. 🤔

[jimjam-slam]

A workaround that works for me in the reprex (see reprex branch workaround) is to brute-force override the max-width:

.cell-output-display > div:not(.quarto-figure) figure svg {
  max-width: 100% !important;
}

(It's not working in my actual use case, but that's probably down to some sort of CSS conflict. But good to know that it works in the basic case!)

[jimjam-slam]

Also note that the diagram doesn't respond to specifically setting //| fig-responsive: true.

[cderv]

Also note that the diagram doesn't respond to specifically setting //| fig-responsive: true.

Yes that is what I meant by "Diagram are supposed to be responsive by default as we document" 😄

The code shared above referred to that option - fig-responsive does not work as it should, and that is the main issue here.

[jimjam-slam]

Ah, gotcha! 😊

[cscheid]

Just to clarify a bit here. The test document is this:

---
title: "GraphViz sizing test"
---

Here's an R plot chunk. It's wrapped in `.quarto-figure`, which means that its enclosing figure gets `width: 100%`:

```{r}
hist(c(3, 4, 5, 5, 6, 8, 3, 1, 2, 5, 8, 9, 4, 1))
```

Now here's a GraphViz chunk. It doesn't have a `.quarto-figure` wrapper, and it has `max-width: none` set inline:

```{dot}
graph G {
  layout=neato
  run -- intr;
  intr -- runbl;
}
```

The claim there is that the R plot from the code cell has a .quarto-figure wrapper, but that's not the case. In 1.5, I see this as the relevant output:

<div class="cell-output-display">
<div>
<figure class="figure">
<p><img src="9249_files/figure-html/unnamed-chunk-1-1.png" class="img-fluid figure-img" width="672"></p>
</figure>
</div>
</div>

The fix for diagrams, I think, is to remove max-width: none from the SVG element and add img-fluid, which is (effectively)

.img-fluid {
    max-width: 100%;
    height: auto;
}

[cscheid]

Like @cderv said, our conditional check for responsive images is failing because of the default fig-width and fig-height set.

I also think that our makeResponsive call is bad, and should just be instead adding img-fluid to the svg element.

[cscheid]

This default fig-width and fig-height problem goes further. I think dot and mermaid diagrams should ignore fig-width and fig-height (!). These diagrams are almost always computed with some layout algorithm, and can't easily conform to a preferred width, height or aspect ratio.

Right now, what we end up doing is changing the svg width and height, but that causes all the breakage we're seeing, in addition to making impossible to make good decisions about font size, etc, since we're resizing the SVG.

However, this also shows another issue of a recurring Quarto design flaw, where we can't easily tell which options were set by default, and which options were explicitly set by users. Currently, we either ignore fig-width and fig-height at all (default or user-specified), or we use it (and can't tell if it was the default or user-specified).

I want to do the correct fix here, and not the small fix.