Repository navigation
Read a free text box's border width from /Border when it has no /BS - #118
Merged
bobsingor merged 3 commits intoNov 15, 2026
Merged
Conversation
A free text box without /BS took the default 1 pt border even when its /Border array says 0, so a box PDF.js wrote (/Border [0 0 0], no /AP, no /RC) got a frame and a text plate inset by 2 pt on every side. Its rect fits the text as PDF.js measured it, so the text then wrapped and the second line was clipped away. - Without /BS, the box's border width is the /Border array's, as the callout already reads it. - A plain box (no /RC) whose border is 0 lays out as PDF.js draws it: lines break only at line breaks, text too wide or too tall for the box is drawn smaller to fit (CPDF_RichTextLayout::Options:: shrink_to_fit), and each paragraph reads in its text's direction.
A borderless plain box lays out like every other box: its lines wrap in the box. Choosing a layout from the border width would stop every borderless plain box from wrapping, whoever wrote it. The test now checks the width rule: /Border draws as the same width in /BS does, frame and text plate alike; 1 pt with neither; /BS first.
bobsingor
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A free text box without
/BSalways got the default 1 pt border, even when its/Borderarray gives another width. Under ISO 32000-1 12.5.2, an annotation with no/BStakes its border from/Border(default[0 0 1]). So a box with/Border [0 0 0]and no appearance stream drew a 1 pt frame and inset its text by 2 pt on every side, and text in a tightly sized box wrapped and was clipped.The plain box was the only free text border reader that skipped
/Border. The callout, the shape generators andEPDFAnnot_GetBorderStylealready take its width when there is no/BS. The viewer therefore read width 0 (no frame, text at the box edge) while the drawn appearance had a frame and an inset.Change
/BS, a plain free text box's border width comes from/Border, as the callout reads it. With neither key, the border stays at the ISO default of 1 pt./BSstill wins when both are present.FreeTextPlate, twice the border width).Layout is unchanged: a borderless box wraps its text in the box like any other box. An earlier version of this PR also changed how plain borderless boxes lay out (no wrapping, shrink to fit, direction from the text). That part was dropped: it chose a layout from the border width, so every borderless plain box would stop wrapping.
Tests
CPDFGenerateAPTest.FreeTextBorderWidthFromBorderArray:/Border [0 0 0]draws no frame with the plate equal to the box, and draws the same stream as/BS << /W 0 >>;/Border [0 0 3]draws as/BS << /W 3 >>; neither key draws as/BS << /W 1 >>(framed, plate inset 2 pt);/BSwins over/Border./Borderarray, so no golden changes.