How to have a two-column layout to be non-float when compiled to PDF?

[tamas-ferenci]

Description

Consider the following example:

---
title: "Untitled"
format:
  pdf:
    keep-tex: true
    fig-pos: H
---

![Elephant](elephant.png)

With layout:

:::: {layout="[0.5, 0.5]"}

:::{}
Text
:::

:::{}
![Elephant](elephant.png)
:::

::::

The first figure is compiled to PDF as this:

\begin{figure}[H]

{\centering \pandocbounded{\includegraphics[keepaspectratio]{elephant.png}}

}

\caption{Elephant}

\end{figure}%

I.e., it is not actually float (due to H with the float package). However, the second is like this:

\begin{figure}

\begin{minipage}{0.50\linewidth}
Text\end{minipage}%
%
\begin{minipage}{0.50\linewidth}

\begin{figure}[H]

{\centering \pandocbounded{\includegraphics[keepaspectratio]{elephant.png}}

}

\subcaption{Elephant}

\end{figure}%

\end{minipage}%

\end{figure}%

I.e., this will be a float! (Yes, there is an H for the inner figure environment, but it doesn't really matter at all, as it is already within a minipage.)

How can I achieve that the two-column layout itself is non-float, similar to the first figure...?

As you can see, the minipage is embedded in a figure. The fact that it is unnecessary is already documented (#9108), but in my particular case it wouldn't pose a problem if I were able to add [H] to this embedding figure environment. But I am unable to do so, in particular, adding fig-pos: H to the header does not add this. I have updated the example to show that even adding fig-pos: H to the header does not add [H] to the figure environment embedding the minipage.

Result of quarto check:

Quarto 1.6.40
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.6.40
      Path: C:\Program Files\Quarto\bin
      CodePage: 1250

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

[>] Checking LaTeX....................OK
      Using: TinyTex
      Path: C:\Users\username\AppData\Roaming\TinyTeX\bin\windows\
      Version: 2024

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

[>] Checking Python 3 installation....OK
      Version: 3.13.1
      Path: C:/Program Files/Python313/python.exe
      Jupyter: 5.7.2
      Kernels: python3

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

[>] Checking R installation...........OK
      Version: 4.4.2
      Path: C:/PROGRA~1/R/R-44~1.2
      LibPaths:
        - C:/Users/username/AppData/Local/R/win-library/4.4
        - C:/Program Files/R/R-4.4.2/library
      knitr: 1.49
      rmarkdown: 2.29

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

[mcanouil]

Since this is done either by Quarto or Pandoc, you are currently left with using raw content block.

• https://quarto.org/docs/authoring/markdown-basics.html#raw-content

Unfortunately, not everything can be abstracted as everyone wants in Markdown for all supported formats.

[tamas-ferenci]

Thanks! What I found strange (bug?) that it does add [H] to the inner figure environment (where it is actually meaningless in this case), but for some reason it does not add it to the outer one, where it would make sense.

[mcanouil]

I really don't understand your issue with the fact that "is is actually meaningless".

The image is rendered the same way in both cases of your example (see below to make a reproducible example which yours is not).

---

You can share a self-contained "working" (reproducible) Quarto document using the following syntax, i.e., using more backticks than you have in your document (usually four ````).
See https://quarto.org/bug-reports.html#small-is-beautiful-aim-for-a-single-document-with-10-lines.

If you have multiple files (and if it is absolutely required to have multiple files), please share as a Git repository.

R	Python
````qmd --- title: "Reproducible Quarto Document" format: html engine: knitr --- This is a reproducible Quarto document. {{< lipsum 1 >}} ```{r} x <- c(1, 2, 3, 4, 5) y <- c(1, 4, 9, 16, 25) plot(x, y) ``` {#fig-placeholder} {{< lipsum 1 >}} The end after @fig-placeholder. ````	````qmd --- title: "Reproducible Quarto Document" format: html engine: jupyter --- This is a reproducible Quarto document. {{< lipsum 1 >}} ```{python} import matplotlib.pyplot as plt x = [1, 2, 3, 4, 5] y = [1, 4, 9, 16, 25] plt.plot(x, y) plt.show() ``` {#fig-placeholder} {{< lipsum 1 >}} The end after @fig-placeholder. ````

Additionally and if not already given, please share the output of quarto check within a code blocks (i.e., using three backticks ```txt), see https://quarto.org/bug-reports.html#check.

[tamas-ferenci]

Thanks I have updated my example accordingly, using four backticks and adding the results of quarto check.

[tamas-ferenci]

"The image is rendered the same way in both cases of your example." It is surely my lack of understanding, but this is not what I see: in the first case we have \begin{figure}[H] (i.e., non-float) in the LaTeX code, while in the second case we have \begin{figure} (i.e., float!).

I don't actually really see why minipage is embedded within a figure environment to begin with, but if it is done this way, the embedding figure also should have an [H] to prevent floating. This is not the default, but more interestingly, even fig-pos: H in the YAML header doesn't make this.

[mcanouil]

Since this is done either by Quarto or Pandoc, you are currently left with using raw content block.

• https://quarto.org/docs/authoring/markdown-basics.html#raw-content

Unfortunately, not everything can be abstracted as everyone wants in Markdown for all supported formats.

[mcanouil]

Images / figures don't have the same treatment.
In Quarto a figure has a caption and an ID starting with fig- otherwise it's an image.
You can play around a bit more to fully understand the behaviour.

Since it works, what's the harm? (I am not saying there are no improvements to be made to be clear)

[tamas-ferenci]

Thank you very much, adding #fig-something to the two-column layout (i.e., :::: {#fig-something layout="[0.5, 0.5]"}) indeed solved to problem! The only further thing I needed was fig-pos: H in the header.

[mcanouil]

For reference as it may be related:

• Multiple columns and figure environment (LaTeX) #9108

[tamas-ferenci]

Yes, that's what I also noticed! I don't know why the embedding figure is needed. But if we had it, somehow we should be able to add [H] to it. It is not done by default, and fig-pos in the YAML header seems to have no effect, unfortunately.

[tamas-ferenci]

My wording might have been confusing, and I am sorry about that, but now I see that this whole issue boils down this question: how can I add [H] to this -- unnecessary -- figure environment? The issue linked shows that it is unnecessary, but in my particular case it wouldn't pose any problem if I were able to add [H] to it. But I am not, in particular, fig-pos: H in the YAML header seems to have no effect for some reason. I updated the question with this aspect.

[mcanouil]

The figure is needed to allow the whole "layout" to be a cross-reference for instance when you want to make composite figure/table/whatever.

The answer to add H or whatever:

---
format: pdf
---

::: {layout-ncol="2" fig-pos="H"}

::: {#first-column}
{{< lipsum >}}
:::

::: {#second-column}
![Image]({{< placeholder >}})
:::

:::

[tamas-ferenci]

Aaaah, indeed! It works! I should add fig-pos to that particular fenced div, not to the header. Thanks you very much!! Although I still do not understand why fig-pos: H in the YAML header doesn't do this (isn't it supposed to have the same effect?), but the important thing is that it solves the issue. Thank you once again!

[mcanouil]

Well, as I said here the figure environment is used for the cross-reference feature thus it "supports" fig-pos as attribute from the fenced div, as in: it adds the attribute back to the element.
But fundamentally, the layout div is not a figure per se.

The (custom) cross-reference feature is as handy as it is complex because it has to work across all formats regardless of how the format technology can actually support the feature in the first place.
Because, LaTeX was really built as a patchwork of things, it comes with many conflict issues which tend to make things very complicated, but you probably already know this if you used LaTeX natively.

[tamas-ferenci]

I see, thanks for the explanation!