Skip to content

revtex's frontmatter shares its page: three quarters of page one were blank - #353

Merged
tannevaled merged 1 commit into
mainfrom
revtex-frontmatter-span
Sep 11, 2026
Merged

tannevaled merged 1 commit into
mainfrom
revtex-frontmatter-span

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Six papers in the corpus are too long with nothing reported missing. The smallest of them, 2203.15077, told the whole story:

page 1, ink
gotex y 70..141 of 660
reference y 44..603

Three quarters of our first page was blank. The title block landed on it and the page ended.

Why

In revtex's reprint (two-column) mode the frontmatter — title, authors, affiliations, abstract — became a one-column region of its own. Regions are page-aligned, because \onecolumn and \twocolumn both \clearpage, so the body started on page two.

Reduced to ten lines: one column fills the page correctly, two columns never do, and plain article with [twocolumn] is fine — so it is not the general mechanism, it is the revtex path.

The fix, which the code already had a name for

revtex's frontmatter is \twocolumn[...] in all but name: a full-width block across the top of the region's first page, with the body flowing in two columns below it on that page. paginateTwoColList already places exactly that — its own comment calls it "the region's own \twocolumn[span]/frontmatter span". So the frontmatter is handed over as the region's span instead of becoming a region.

page 1, ink
before y 70..141
after y 70..613
reference y 44..603

A frontmatter taller than the text block has no page to share, and a span is placed whole and cannot be broken, so that case keeps the old behaviour — with its own test.

Measured

157 arXiv papers, against a baseline rebuilt from the current main: Σ|err| 335 → 326 (−9), glyphs +0, no paper losing content. Thirteen papers each lose the wasted page, and six land exactly on their reference — 2203.15077, 2307.10113, 2308.02700, 2310.04950, 2403.04273, 2408.08814.

Sixteen of the 154 papers with a valid reference are revtex, so this is over 10% of the corpus.

Two test helpers were blind

treeText and pageChars walked only the main vertical list, so a span was invisible to them: a revtex title block looked absent when it had merely moved. Both collect the regions' spans now — which is what a figure*/table* band needs too. The rendered output is byte-identical in text: pdftotext gives the same title, authors and abstract before and after.

TestRevtexReprintTwoColumn asserted the old contract ("a one-column frontmatter region precedes a two-column body region") and now asserts the new one.

🤖 Generated with Claude Code

… blank

In reprint (two-column) mode the frontmatter — title, authors, affiliations,
abstract — became a one-column region of its own. Regions are PAGE-ALIGNED, since
\onecolumn and \twocolumn both \clearpage, so the body started on page TWO and
most of page one stayed empty.

Measured on 2203.15077: our page 1 carried ink from y=70 to y=141 of 660 where
the reference fills it to y=603, and the paper set in 6 pages against 5.

revtex's frontmatter is \twocolumn[...] in all but name: a full-width block across
the top of the region's first page, with the body flowing in two columns BELOW IT
on that same page. paginateTwoColList already places exactly that — its own
comment calls it "the region's own \twocolumn[span]/frontmatter span" — so the
frontmatter is handed over as the region's span instead of a region of its own.

A frontmatter taller than the text block has no page to share, and a span is
placed whole and cannot be broken, so that case keeps the old behaviour.

Corpus: Sigma|err| 335 -> 326 (-9), glyphs +0, NO paper losing content. Thirteen
papers each lose the wasted page; six land exactly on their reference (2203.15077,
2307.10113, 2308.02700, 2310.04950, 2403.04273, 2408.08814). Sixteen of the 154
papers with a valid reference are revtex.

Two test helpers walked only the main vertical list and so could not see a span at
all — a revtex title block looked absent when it had merely moved. They collect
the regions' spans now, which is also what a figure*/table* band needs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

1 participant