Color leakage and no page break for `.callout` environments

[kandolfp]

Bug description

If I enclose some code into a .callout that is longer than a page in LaTeX there are no page breaks and we see color leakage such that normal text afterwards is not shown.

Interesting enough, if I actually run the code i.e. #| eval: true there is still no page break but the color leakage is not happening.

Steps to reproduce

--- 
title: "foo"
---
:::: {.callout-caution icon=false}
## Self implementation 

Implement the code yourself by filling out the missing sections:

```{python}
#| code-fold: true
#| eval: true
#| code-summary: "Code fragment for implementation."
import numpy as np
import matplotlib.pyplot as plt
%config InlineBackend.figure_formats = ["svg"]

frequ = 2 * np.pi * 50
f = lambda t: 0.8 * np.sin(t * frequ)
diod = lambda t: (np.exp(1.2 + t) - 1)

t = np.linspace(0, 2 * np.pi / frequ, 1024, endpoint=False)
x = np.linspace(np.min(f(t)) * 1.3, np.max(f(t)) * 1.1, 1024)

ic = lambda t: diod(f(t))

k = np.arange(0, 16) * 1 / 16

# The provided figures where used to create the illustation
if True:
    plt.figure()
    plt.plot(f(t), t)
    plt.plot([np.min(t),np.max(t)], [0,0], "gray")
    plt.axis("off")
    plt.savefig("sin.svg", transparent=True)
    plt.figure()
    plt.plot(x, diod(x))
    z = np.array([0, np.min(f(t)), np.max(f(t))])
    plt.plot(z, diod(z), "bx")
    plt.axis("off")
    plt.xlim([-2,5])
    plt.gcf().patch.set_visible(False)
    plt.savefig("diode.svg", transparent=True)

    plt.figure()
    plt.plot(t, ic(t))
    plt.plot(2*np.pi*k/frequ, ic(2*np.pi*k/frequ), "ro")
    plt.axis("off")
    plt.savefig("ic.svg", transparent=True, bbox_inches ="tight")

y = ic(k)
yhat = (np.fft.fft(y))
#Necessary correction factor for the FFT
factor = 1 / 16
yy = factor * yhat

ic_mean = np.mean(ic(np.linspace(0, 1/50, 2**20)))
c0 = yy[0].real
effective_value = np.linalg.norm(yy[1:])
harmonic_distortion = np.linalg.norm(yy[3:-2])/np.linalg.norm(yy[1:])
```
::::

Some text that will not be displayed in the correct color.

Expected behavior

I run:

quarto render file.qmd --to pdf

I expected a pdf to be produced, containing the code spread over multiple pages enclosed in a caution box, also spanning multiple pages and all text in black.

Each of the environments on their own are able to span multiple pages so I assumed a combination should work as well.

Actual behavior

Render works without problem

quarto render file.qmd --to pdf

The output has no page break for the code and the line

Some text that will not be displayed in the correct color.

Is written in white.

Your environment

• Ubuntu 24.04
• Quarto > 1.6.39 (tested also with latest build on github)
• matplotlib to plot the figures for the almost correct version

Quarto check output

quarto check
Quarto 1.7.3
[✓] Checking environment information...
      Quarto cache location: ~/.cache/quarto
[✓] 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.7.3
      Path: /tmp/quartodebug/.venv/lib/python3.12/site-packages/quarto_cli/quarto-1.7.3/bin

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

[✓] Checking LaTeX....................OK
      Using: Installation From Path
      Path: /usr/bin
      Version: 2023

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

[✓] Checking Python 3 installation....OK
      Version: 3.12.3
      Path: /tmp/quartodebug/.venv/bin/python3
      Jupyter: 5.7.2
      Kernels: python3

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

[✓] Checking R installation...........(None)

      Unable to locate an installed version of R.
      Install R from https://cloud.r-project.org/

[mcanouil]

Could you properly format your post using code blocks for code and terminal outputs? Thanks.
If your code contains code blocks, you need to enclose it using more backticks, i.e., usually four ````.
See https://quarto.org/bug-reports.html#formatting-make-githubs-markdown-work-for-us.

I'm pretty sure this (a similar issue) has been discussed somewhere in the repository (I'll update once I found it)

• Page Break Issue with Long Lists in Callout Boxes for PDF Rendering #11212

[kandolfp]

Sorry, I forgot to close the first code block... Thanks for having a look!!

[kandolfp]

I looked at this a bit more and you are doing a code injection to modify the default pandoc behavior in a couple of cases. I quickly tried the following:

diff --git a/src/resources/filters/layout/meta.lua b/src/resources/filters/layout/meta.lua
index 349b89bea..3915c7d9d 100644
--- a/src/resources/filters/layout/meta.lua
+++ b/src/resources/filters/layout/meta.lua
@@ -95,9 +95,15 @@ function layout_meta_inject_latex_packages()
         
         -- redefined the 'Shaded' environment that pandoc uses for fenced 
         -- code blocks
-        metaInjectLatex(meta, function(inject)
-          inject("\\ifdefined\\Shaded\\renewenvironment{Shaded}{\\begin{tcolorbox}[" .. tColorOptions(options) .. "]}{\\end{tcolorbox}}\\fi")
-        end)
+        if (string.find(bgColor, "ffffff") or string.find(bgColor, "FFFFFF")) then
+          metaInjectLatex(meta, function(inject)
+            inject("\\ifdefined\\Shaded\\renewenvironment{Shaded}{}\\fi")
+          end)
+        else
+          metaInjectLatex(meta, function(inject)
+            inject("\\ifdefined\\Shaded\\renewenvironment{Shaded}{\\begin{tcolorbox}[" .. bgColortColorOptions(options) .. "]}{\\end{tcolorbox}}\\fi")
+          end)
+        end
       end

Where I redefine Shaded to an empty environment in case the background color is set to white via code-block-bg: "#ffffff".

This is neigter generic nor beautiful but before I invest more time and possible create a PR I thought I make this quick and dirty version as a proof-of-concept and ask if:

an option that deactivates the tcolorbox around code blocks

is something that could find its way into upstream?

[cscheid]

PRs are always welcome, but I want to emphasize that they are pull requests: we don't promise that we will be willing to merge them. It all depends on how the feature ends up looking like, interactions with other parts of the system, tests, documentation, etc.