docs(text): correct what the RTL notes say about table cells and lists - #680
Merged
Conversation
Three places still described a table cell as having no writing direction, which stopped being true when #558 gave DocumentTableStyle a direction of its own: the examples README twice, in the Hebrew invoice row and its section, and the PdfRenderEnvironment Javadoc, which also said a table cell is never reordered although the table-cell path marks reordered text the way the paragraph and chip paths do. The recipe catalogue row for text direction named paragraphs only. The Arabic article section also said a list declares align(RIGHT) or its bullets land on the wrong side. align(RIGHT) moves each item to the right margin, but an item is still a left-to-right paragraph with the bullet as its text prefix, so the bullet stays at the item's left end. - examples/README.md: the Hebrew invoice row and section stop giving a missing cell direction as the reason for rows, and the section says a table cell takes one through DocumentTableStyle.direction(...); the Arabic article section says what align(RIGHT) moves and what it leaves. - docs/recipes.md: the text-direction row names table cells too. - PdfRenderEnvironment.markReorderedText: set from the paragraph, chip and table-cell paths.
DemchaAV
added a commit
that referenced
this pull request
Sep 12, 2026
Brings the 2.4.0 engine work onto the promotion branch: native letter spacing (#676), opt-in list hanging indent (#674), the resolved timeline rail (#671-#673), the row-child margin fix, the RTL documentation corrections (#679, #680) and the templates japicmp gate (#681). Eight files conflicted. CHANGELOG.md is a union of both v2.4.0 sections, with the branch-local "### Deprecated" folded into the house heading "### Deprecations" and the sections ordered the way released entries are. The other seven are generated and were regenerated from the merged source rather than resolved by side: knowledge/api/templates.json and .md through extract-api --from-reactor, and the five cv preview PDFs by re-rendering their example classes. Five qa baselines moved, all from f75def6, which stops a row child's horizontal margin being taken off twice. Each of the four layout snapshots changes by exactly one node's own horizontal margin - HeadingRule_EXPERIENCE +9.0, EducationHeadingRule +11.285, FooterDueIcon -3.479 (a negative margin) and FooterSite +1.693 (a right margin) - with startPage and endPage unchanged, so no page ownership moved. cobalt_rota keeps its geometry snapshot and moves only in pixels, inside composed table cells, which emit fragments rather than PlacedNodes and so cannot appear in a layout snapshot; the changed region is the day-header and note cells. One of 126 pixel baselines changed, verified by checksum before and after.
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.
Why
Four statements about right-to-left text no longer match the code.
DocumentTableStyleadirection(...)of its own: the Hebrew invoice row and section inexamples/README.md, and thePdfRenderEnvironment.markReorderedTextJavadoc, which adds that a table cell is never reordered, although the table-cell path marks reordered text the way the paragraph and chip paths do.align(RIGHT)or its bullets land on the wrong side.align(RIGHT)moves each item to the right margin, but an item is still a left-to-right paragraph with the bullet as its text prefix, so the bullet stays at the item's left end.The recipe catalogue row for text direction also named paragraphs only.
What changed
examples/README.md: the Hebrew invoice row drops the stale reason, and the section says the line items are rows and that a table cell takes a writing direction throughDocumentTableStyle.direction(...), which is whatHebrewInvoiceExample's own Javadoc already says. The Arabic article section says whatalign(RIGHT)moves and what it leaves.docs/recipes.md: the text-direction row names table cells as well as paragraphs.PdfRenderEnvironment.markReorderedTextJavadoc: set from the paragraph, chip and table-cell paths (PdfParagraphFragmentRenderHandler,PdfTableRowFragmentRenderHandler). Comment only.Verification
com.demcha.documentation.*plusEnginePdfBoundaryTest(links and anchors, recipe catalogue, canonical surface, coverage) 115 green; qaDocumentationSnippetCompileTest+DocumentationExamplesTest18 green.RtlTableCellTest8 green;javadoc:javadocongraph-compose-render-pdfclean (0 warnings, 0 errors)../mvnw -f examples/pom.xml test) 75 green.node knowledge/tools/claims/check-claims.mjs --checkandnode knowledge/tools/routing/check-routes.mjsgreen;git diff --checkclean.Notes
docs/recipes/text-direction.mditself. The two are independent: nothing here links to docs(recipes): say that a table cell takes a direction too #679's new anchor, so they merge in either order.ArabicArticleExampleJavadoc and code comment and in the released v2.2.0 CHANGELOG entry, and the README's Indic-reordering line, which needs its own investigation.Lane: canonical — documentation and one Javadoc comment; no code.