pdf-codec has no shared text-line grouping, so consumers hand-roll it and repeat the same two bugs

[Mearman]

pdf-codec exposes positioned text runs and I couldn't find a function in it that groups them into lines and words, so each consumer writes its own. A downstream consumer did, and its review turned up two bugs that any hand-rolled version is likely to repeat:

A tolerance for "same baseline" taken from the line's anchor run lets a large heading absorb the small line below it (a 30pt heading swallowed the 9pt line beneath it), and the join then sees a negative gap and drops the space too, producing the run-together text the grouping exists to prevent. The tolerance should come from the smaller of the two runs.

When a run has no advance width, defaulting it to zero makes the previous run's end its own start, so the whole advance reads as a gap and spaces appear inside words ("Com plete ly"). No width should mean no space.

If pdf-codec already does this somewhere I missed (I only looked for line-joining and baseline logic in src), the ask is to expose it and document it; if not, a tested grouper there, with those two cases as tests, would save every consumer from redoing it.

[github-actions]

🎉 This issue has been resolved in version 7.20.35 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Mearman]

You were right that nothing in pdf-codec did this. What I did find is that both of the bugs were already sitting in this repo's own two hand-rolled versions, which is a fair bit of evidence for the general claim:

documents.js's reconstruct.ts scaled its baseline tolerance by whichever run it happened to be admitting, so a 9pt kicker 12pt above a 30pt title fell inside the title's 15pt window; the merged line then sorted by x into a sequence whose gaps were negative, and a negative gap reads as one word, so it came out "QuarterlyResults". Same file read an absent width as zero everywhere it decided a space, a tab or a cell boundary, and produced "Com plete\tly" — a tab, not just a space, because the phantom gap was wide enough. document-outline.js's pdf-regions.ts clustered baselines in a fixed 2pt window regardless of font size, and counted table cells off the same zeroed width, so a line of separately-shown words counted one cell per word and read as a table row. Both are fixed, with the failing-first tests to prove it.

The shared grouper is groupPdfTextRuns in pdf-codec 5.1.0, with the two rules also exported on their own (runsShareBaseline, runGapPt) since documents.js interleaves its duplicate-paint collapsing with the clustering and needed the rules without the pipeline. pdf-codec/text-group serves it without dragging in the write half and the vendored fonts.

On the tolerance: it is a fraction of an em of the smaller of the two runs, defaulting to two thirds. Bounded above because two consecutive lines are never closer than solid setting puts them, one full em; bounded below because a superscript raised by at most a third of its parent's size at no less than half that size shifts by at most two thirds of its own em, and anything tighter cuts footnote markers off the line they annotate. On the width: runGapPt returns undefined, not zero, and the callers treat that as no evidence of anything.

Gaps that are derivable become a word space at an eighth of an em and a column boundary past a full em, so a table row comes out "North\t4.2m\t11%" rather than as a sentence. Limits are in the doc comment and the README: no page segmentation (so two columns offset vertically can still read as one line, with the gutter reported as a column boundary), visual rather than logical order for RTL, no vertical writing mode (filed separately as #1358), and a hyphen at a line end stays put.

PR #1354. Released as pdf-codec@5.1.0, documents.js@7.20.35, document-outline.js@3.9.17. Verified both cases against the published tarball in a clean install.