Skip to content

fix alignment-token early return inside nested boxing groups#2775

Merged
brucemiller merged 2 commits intobrucemiller:masterfrom
dginev:patch-alignment-token-early-return
Mar 17, 2026
Merged

fix alignment-token early return inside nested boxing groups#2775
brucemiller merged 2 commits intobrucemiller:masterfrom
dginev:patch-alignment-token-early-return

Conversation

@dginev
Copy link
Copy Markdown
Collaborator

@dginev dginev commented Mar 11, 2026

Summary (generated)

digestNextBody() was prematurely returning on \cr/\lx@hidden@cr tokens even when deep inside nested hbox/vbox groups within a tabular cell. This caused cascading errors when \adjustbox{valign=t}{\begin{subfigure}...} was used inside \tabular, as the \\ inside subfigure leaked out as \lx@hidden@cr and triggered the alignment early-return check.

Fix: guard the alignment-token check with a boxing-depth comparison so it only fires at the original alignment nesting level, not inside deeper boxing groups.

Also includes minor whitespace reformatting by latexmllint.

Minimal test

\documentclass{article}
\usepackage{subcaption}
\usepackage{adjustbox}
\begin{document}
\begin{figure}
\begin{tabular}{c}
  \adjustbox{valign=t}{\begin{subfigure}{2cm}B\\C\end{subfigure}}
\end{tabular}
\end{figure}
\end{document}

Easy diff

https://github.com/brucemiller/LaTeXML/pull/2775/changes?w=1

Disclosure

Diagnostic and patch via Claude Opus 4.6 "heavy effort".

I have manually verified this patch recovers arXiv:2401.06604v3 out of regression status.

digestNextBody() was prematurely returning on \cr/\lx@hidden@cr tokens
even when deep inside nested hbox/vbox groups within a tabular cell.
This caused cascading errors when \adjustbox{valign=t}{\begin{subfigure}...}
was used inside \tabular, as the \\ inside subfigure leaked out as
\lx@hidden@cr and triggered the alignment early-return check.

Fix: guard the alignment-token check with a boxing-depth comparison
so it only fires at the original alignment nesting level, not inside
deeper boxing groups.

Also includes minor whitespace reformatting by latexmllint.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@dginev dginev requested a review from brucemiller as a code owner March 11, 2026 20:14
@dginev
Copy link
Copy Markdown
Collaborator Author

dginev commented Mar 12, 2026

Note that if this PR looks good, there is a second fix using the same method. I have branched it off from here to ensure there isn't cross-talk between the bugs (there wasn't). If it looks promising I can point the other PR over to the master branch, when this one is merged:

dginev#12

@brucemiller
Copy link
Copy Markdown
Owner

Another curious one. I still had my tentative patch to #2776 (which essentially is fixing \hbox) in place when I ran the above test and it gave me no errors, but it's missing the B in the output. Hmm. I got exactly the same result with your patch (also missing the B). That suggests to me that my proposed patch is a more fundamental one; although, possibly the same sort of test should mask the alignment tokens in digestNextBody? At any rate, there's still something off.

@dginev
Copy link
Copy Markdown
Collaborator Author

dginev commented Mar 17, 2026

Interesting. Still quite slippery.

To salvage the B we likely need to avoid running into the alignment behavior of \\ within the subfigure? Maybe a Let('\\\\', '\lx@newline'); added to the start of sub beforeFloat, so that we override any outer rebindings of par ?

(Tried the suggestion, B is recovered. Though naturally the subfigure contents get yanked out of the ltx:tabular since subfigure tries to float up.)

@brucemiller
Copy link
Copy Markdown
Owner

I was pondering along the same lines (rebinding \\): unclear why the "wrong" \\ should disappear the B, though. At any rate, the whole thing's got schema issues. Would seem to want a smarter Alignment strategy (can't put this stuff in a table, so use css/flex/whatever)

@dginev
Copy link
Copy Markdown
Collaborator Author

dginev commented Mar 17, 2026

Would seem to want a smarter Alignment strategy (can't put this stuff in a table, so use css/flex/whatever)

Just to be clear -- that sounds completely out of scope for my "arXiv regression patching" sprint I am trying to complete for v0.9. If we recover content but "get bruised" on markup fidelity, that is ok for now.

So I'm happy with this kind of PR, if you are :-)

Copy link
Copy Markdown
Owner

@brucemiller brucemiller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks!!

@brucemiller brucemiller merged commit 7050832 into brucemiller:master Mar 17, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants