test(render): cover text-state invalidation around inline graphics#202
Merged
Conversation
The paragraph render handler invalidates its tracked font/colour after an inline image or shape so the following text span re-emits Tf/rg rather than trusting state the graphic disturbed. ParagraphTextStateDedupTest covered single-style dedup and multi-style re-emit but never paired same-style text across an inline graphic — the exact case the invalidate guards. Add a shape case and an image case (same-style text on both sides of the graphic) that assert two setFont operators. Both use the rich-text builder so the runs keep their declared [text, graphic, text] order. Mutation-checked: removing either invalidate() collapses the count to one and fails the matching case.
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
1 participant
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.
Why
PdfParagraphFragmentRenderHandlertracks the last-written font andnon-stroking colour within a paragraph's
q...Qblock so a single-styleparagraph emits one
Tf/rginstead of one per span. After an inline imageor shape it calls
TextRenderState.invalidate(), because the graphic ends thetext block and runs its own graphics-state/colour ops — so the next text span
must re-emit
Tf/rgrather than trust the disturbed state.ParagraphTextStateDedupTestcovered single-style dedup (one
Tf) and multi-style re-emit (≥2Tf) butnever paired same-style text across an inline graphic — the exact path the
invalidate()guards. A droppedinvalidate()would render the trailing textin whatever font/colour the graphic left set and no test would catch it.
What changed
Added two cases: same-style text on both sides of an inline shape, and of an
inline image, each asserting two
setFontoperators. Both use the rich-textbuilder (
p.rich(r -> r.plain(...).diamond(...)/.image(...).plain(...))) so theruns keep their declared
[text, graphic, text]order — theParagraphBuildertext()/shape()chain collapses the text into one field, which is why the richseam is the right surface here. Test-only; no production change.
Verification
./mvnw test -pl .→ BUILD SUCCESS, 1387 tests, 0 failures.textState.invalidate()calls collapses theoperator count to one and fails both new cases while the two existing dedup
cases stay green — confirming each case drives its own invalidate site.
Lane: canonical (
document.backend.fixed.pdfrender guard). No public API change.