-
Notifications
You must be signed in to change notification settings - Fork 208
fix(layout): place the first column on the right in RTL sections #3953
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
95cf92d
fix(layout): place the first column on the right in RTL sections
Nathaniel-260 99cc234
fix(layout): order RTL balancing by document order, and cover the axi…
Nathaniel-260 5552e2c
fix(layout): gate the RTL column separator on the fragment edge that …
Nathaniel-260 b9e7e51
fix(painter): resolve a separator's neighbouring column by ownership,…
Nathaniel-260 2438bd9
fix(painter): attribute a fragment to its column by overlap, not by i…
Nathaniel-260 db5947e
fix(painter): bound column attribution by the page, and by both box e…
Nathaniel-260 f2a36d8
docs(painter): name the fragment kinds that actually record a column
Nathaniel-260 02fe513
style(painter): put the columnOwningSpan signature on one line
Nathaniel-260 3da48e3
fix(painter): trust a fragment's origin by its width, not by its righ…
Nathaniel-260 18c7b65
test(painter): guard the width gate with a shape that can reach it
Nathaniel-260 ad9bde6
fix(contracts): resolve an RTL column boundary the way geometry place…
Nathaniel-260 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
293 changes: 293 additions & 0 deletions
293
packages/layout-engine/contracts/src/column-layout.test.ts
Large diffs are not rendered by default.
Oops, something went wrong.
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
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 High
4. No producer wires w:bidi into columnlayout.direction
🐞 Bug≡ CorrectnessAgent Prompt
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation toolsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-verified this today, and it still holds on the current tip — recording the evidence here because the earlier answer went into a top-level comment, which left this thread looking unanswered.
grep -rln "columns.*direction\s*[:=]" packages/outside tests matches exactly one file:packages/layout-engine/contracts/src/column-layout.ts, which is where the field is defined and read. No importer, adapter, or section-processing path assigns the resolved section bidi to it. So the finding is right as stated: this PR is the axis, not the end-to-end fix, and a real Hebrew or Arabic multi-column document still renders unchanged after it merges.That is deliberate —
mainhas no column direction at all, so the axis has to exist before anything can feed it — but it has a consequence worth flagging before merge rather than after:This PR says
Fixes #3952, so merging it will auto-close #3952 while the reported behaviour is still present for users. That is the wrong outcome for the issue tracker whichever way the scoping goes. Two ways out, and I am happy with either:Fixeskeyword to a plain reference, and Columns ignore the section's w:bidi: the first column renders on the left in RTL documents #3952 stays open until a producer lands.Fixesis accurate.Say which you prefer and I will do it. Leaving this thread open until then, since it is a live decision and not a closed loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Went looking for whether anything else already wires this up, since if a producer were in flight the scoping question would answer itself. It is not, and the reason turns out to be structural rather than an oversight in this PR.
What I checked:
dir="auto"— paragraph-level inline direction, touchingrtl-styles.ts,render-line.tsandParagraphNodeView.js. Different axis entirely; ECMA-376 keeps §17.3.1.6 paragraphw:bidiand §17.6.1 sectionw:bidiseparate, and that PR is the former.document-api/src/sections/. None touch section direction.The structural part, which is the actual answer to "why has nobody done this":
SectionDirectionContext.pageDirection— the field this PR's description cites as already governing section chrome — has no producer either.grep -rn "pageDirection"overpackages/andshared/returns three hits: the field declaration indirection-context.ts:47and two generated.d.tscopies. Nothing constructs aSectionDirectionContextanywhere;grep -rn "SectionDirectionContext"outside tests anddistgives only the type definition and its re-export fromindex.ts.And no importer parses
w:sectPr/w:bidiat all. Everybidihit in production code is paragraph-level or run-level (document-api'sLANG_ALLOWED_KEYS,MARK_RUN_LANG_KEYS, and theSet paragraph base directionoperation). Section-levelw:bidiappears only inside comments in the contracts package, describing behaviour that was specified and never implemented.So the section-direction contract is a declared-but-unbuilt surface that predates this PR. I wrote a consumer against the half that exists. That does not change the conclusion you drew — this PR alone still does not move a real document — but it does mean the missing producer is a gap in the contract rather than something this PR skipped, and wiring it needs an importer change that is a different subject from column geometry.
Which makes me lean toward option 1 from my previous comment: drop
Fixes #3952to a plain reference here, and let the issue close when a producer lands. Happy to go the other way if you would rather see it done in one piece — still your call, and I have not changed the keyword yet.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Went with option 1 rather than leave this hanging on your reply — the keyword is now dropped.
Fixes #3952in the description is a plain "Part of #3952" reference, with the reason stated inline, so merging this no longer auto-closes a live issue. I also left a status note on #3952 itself recording what has landed and what is missing, so it does not get re-reported or closed by someone reading the merge.Reversible in one edit if you would rather have the producer in this PR after all. My reasoning for not bundling it: reading
w:sectPr/w:bidiand settingSectionBreakBlock.columns.directionis an importer change, a different subsystem from column geometry, and it needs an RTL multi-column fixture — which undertests/README.md's privacy rules has to be synthetic and verifiable. That is a reviewable unit on its own and a poor fit stapled onto a PR already carrying two others.Offered on #3952 to do it as a follow-up once this lands, if you want it from me.