Skip to content
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

Color lost on split footnote #1

Open
FrankMittelbach opened this issue Nov 11, 2017 · 19 comments
Open

Color lost on split footnote #1

FrankMittelbach opened this issue Nov 11, 2017 · 19 comments
Assignees
Labels
bug category base (latex) category graphics long-term issues (or enhancements) that will not be resolved any time soon but should be considered eventually

Comments

@FrankMittelbach
Copy link
Member

FrankMittelbach commented Nov 11, 2017

Brief outline of the bug

This is a bug (but perhaps impossible to fix) I came across the other day: The color inside a footnote is partially lost if LaTex decides to split the footnote.

Minimal example showing the bug

\RequirePackage{latexbug}
\documentclass{article}

\usepackage{lipsum,color}

\setlength\textheight{16\baselineskip}

\begin{document}

\lipsum*[1]\footnote{\color{blue}\lipsum[2] Color partially lost on a split footnote!}

\lipsum*[3]\footnote{foo}

\end{document}

Log (and possibly PDF) file

colorbug.log

colorbug.pdf

@davidcarlisle
Copy link
Member

davidcarlisle commented Nov 11, 2017 via email

@josephwright
Copy link
Member

Probably for the L3 colour experiments I should have multiple stacks built-in :)

@josephwright
Copy link
Member

@FrankMittelbach Do we need 'category' in the label? Wouldn't just 'graphics' cover it? BTW, nice use of the 'machine' user (@latexteam) ;)

@FrankMittelbach
Copy link
Member Author

FrankMittelbach commented Nov 11, 2017 via email

@ghost
Copy link

ghost commented Nov 12, 2017 via email

@FrankMittelbach
Copy link
Member Author

Well, offering the advice to use bigfoot is better than saying tough (or not saying anything :-).
For 2e that might be all we ever want to do but going forward I think @josephwright is right that some colorstack model might be in dire need

@ghost
Copy link

ghost commented Nov 12, 2017 via email

@josephwright
Copy link
Member

I don't follow the comment about pdfTeX: it has a colour stack in the same way dvips does.

@josephwright
Copy link
Member

Or at least, that's my understanding of the fact it has separate stacks ...

@josephwright
Copy link
Member

Of course, pdfTeX/LuaTeX in PDF mode is only a subset of what needs to work, so the bigfoot approach is probably the only generally-viable one (at least until/unless stacks work in dvips and (x)dvipdfmx).

@FOCCOF
Copy link

FOCCOF commented Mar 11, 2018

@josephwright Yes, I think so. I immediately thought about \marks associated with any color whatsit to be able to track the colour stack and complete it as necessary. Certainly the same sort of "bug" could be shown with the multicols package, although i've not written an example yet ;-(

Anyway, i HATE footnotes that split accross pages ! Some books print footnotes with a footnote rule in the middle of the page. Depending on what sort of book it is, the result is not necessarily ugly...)

@josephwright
Copy link
Member

Probably fixable for pdfTeX, maybe not for dvips, etc.

@GMS103 GMS103 mentioned this issue Aug 14, 2019
davidcarlisle added a commit that referenced this issue Aug 15, 2020
davidcarlisle added a commit that referenced this issue Aug 18, 2020
* first draft of default unit code in picture mode

* latexrelease guards

* fix includeinrelease guards

* update for default units

* too much macrocode

* correction to dashbox change

* update for default units rollback

* undefine internal space command from robust versions in rollback code

* update for default units rollback

* picture mode commands in ltboxes

* different length registers for vertical and horizontal

* picture mode test

* update for default units rollback

* update for default units rollback

* updated filehook-006 test mostly from lthooks2 branch

* updated filehook-006 test mostly from lthooks2 branch

* #2 not #1  in picture box update

* spurious < in rollback code

* documentation

* [ci skip] ltnews entry for picture extensions

* [ci skip] change log entry for picture extensions

* document using advance with defaultunitsset

* wording clarification as suggested in review of PR

* Move comment back to matching place in the code (accidentally moved while adding latexrelease guards)

* old syntax version of test 01

* correct 7mm value
@FrankMittelbach
Copy link
Member Author

It's funny to see all these spurious references. I scratched my head for a moment but the reason is simple: people have replied showing code with arguments from mail so the code got interprreted and @ macros became users (what what they thought getting referenced if they happened to exist :-) ) and the #1 ended up here. Dosn't seem possible to delete thos spurious ones.

Anyway, I think we are finally able to resolve this issue in the fall release of LaTeX (if we get configuration points then), so I tentatively penciled that in now,

@FrankMittelbach FrankMittelbach added this to the Release 2021 Fall milestone May 4, 2021
@FrankMittelbach FrankMittelbach self-assigned this May 4, 2021
@josephwright
Copy link
Member

@FrankMittelbach Fix isn't too bad, it's a question partly of if we are happy saying 'works in pdfTeX, LuaTeX, recent-XeTeX/dvipdfmx routes, but not dvips' (I guess 'doesn't even feature' for dvisvgm)

@FrankMittelbach
Copy link
Member Author

But with the coming fall release we will (or should be) able to detect a split footnote stream and thus can handle tagging and color for it regardless of the back end. And given that there will be no fix before that release (or only in a summer "dev") I see not much point in a partial fix, or am I missing something?

@josephwright
Copy link
Member

@FrankMittelbach Ah, right, I see how you are imagining a fix. I was thinking of engine colour stacks not of breaking this down at the LaTeX level.

@FrankMittelbach
Copy link
Member Author

@josephwright well, we need the machinery for paragraphs anyway, so yes, color could could be handled differently, but what would we really gain by that? I guess not much, but who knows, it is certainly a possible option we have available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug category base (latex) category graphics long-term issues (or enhancements) that will not be resolved any time soon but should be considered eventually
Projects
Status: Pool (unscheduled issues)
Development

No branches or pull requests

4 participants