New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LaTeX: problems (frame, color) when long code line wraps over a page limit in some circumstances #10610
Comments
This does not fix entirely sphinx-doc#10610 but it does sufficiently for it not to require reverting sphinx-doc#10577 which tried to solve sphinx-doc#8686 conundrum. In extreme cases, the sphinx-doc#8686 problem meant that some contents disappearing at page bottom, so it is probably better that to maintain sphinx-doc#10577 which will avoid anysuch overflow of code beyond its frame, even though in some specific cases (a colored entity such as a long string is partly on both pages), some syntax highlighting gets lost. There are anyhow other issues with colors for wrapped code lines, even with no pagebreaks involved, such as sphinx-doc#10615. This patch does not change the situation there.
This does not fix entirely sphinx-doc#10610 but it does sufficiently for it not to require reverting sphinx-doc#10577 which tried to solve sphinx-doc#8686 conundrum. In extreme cases, the sphinx-doc#8686 problem meant that some contents disappeared at page bottom, so it is probably better to maintain sphinx-doc#10577 which will avoid any such overflow of code beyond its frame, even though in some specific cases (a colored entity such as a long string is partly on both pages), some syntax highlighting gets lost. There are anyhow other issues with colors for wrapped code lines, even with no pagebreaks involved, such as sphinx-doc#10615. This patch does not change the situation there.
This is a difficult problem which one can experience with pure LaTeX via this example \documentclass[a4paper]{article}
\usepackage{framed}
\usepackage{color}
\definecolor{shadecolor}{rgb}{0.8,0.8,0.8}
\begin{document}
\vspace*{18cm}
\begin{shaded}
\textcolor{blue}{a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line a very long line}\newline
I am invisible
\end{shaded}
Hello
%\showoutput
\end{document} On page 2, the long code line has lost its color. Moreover the line "I am invisible" is invisible because it acquires the color of the gray background. The problem is due to a separation of a "color push" on page 1 and "color pop" on page 2, and the reason the background color is used is related to internals of core LaTeX In the case of Sphinx, there are differences because it does both framing and background colors. I found also buggy situations with pure LaTeX+framed and its I do not expect a fix anytime soon of the remainning problems so putting the milestone at 6.0.0. edit: unexpectedly I could fix this. But this required a deep plunge into LaTeX core color interface, as some of its features are the root cause of this problem. |
Describe the bug
Unexpected loss of frame on page 1 and color on page 2
How to Reproduce
Expected behavior
No response
Your project
N/A
Screenshots
OS
Mac
Python version
3.10.4
Sphinx version
5.x (v5.1.0+/12e86ff0e)
Sphinx extensions
No response
Extra tools
No response
Additional context
Relates #8686.
The #10577 works generally, but here something strange happens with a code-block as item in a numbered list.
edit:
Bug clearly related to the long code line being almost entirely an argument to a
\PYG
macro. Some problems with "groups" in TeX modifying scopes of certain things, presumably.edit:
This has to do with Pygmentize mark-up assigning some color (not background color, which would create unbreakable box, here only foreground color) via
\textcolor{<color>}{<long input>}
to a long input which ends up split across pages (prior to #10577 the text would have spilled into bottom margin of first page). I have noticed that already LaTeX packageframed
has problems in such circumstances (the framing is partially contaminated by the text color, but text on second page has correct color). Inserting into a Sphinx LaTeX documentat a location such that pagebreak occurs within it is enough to trigger the problem. With one level less of grouping
{...}
, the frame on first part reappears, but the color is still wrong on second page.The text was updated successfully, but these errors were encountered: