Columns ignore the section's w:bidi: the first column renders on the left in RTL documents

[Nathaniel-260]

What happens

In a section that carries w:sectPr/w:bidi, columns fill left to right. The first paragraph of a two-column Hebrew section lands in the left column and overflow spills into the right one.

Word does the opposite: in an RTL section the first column is the rightmost.

Why it is more than a cosmetic flip

Selection follows the fill order, so the mirrored layout breaks dragging in a way that looks like a selection bug:

1. Press inside the column a Hebrew reader starts from — the right one.
2. Drag down a few lines. So far so good.
3. Keep dragging into the left column.

Everything already highlighted below the anchor disappears, and the left column lights up instead. Measured on a 44-paragraph document: 8 highlighted lines in the right column drop to 5 the moment the pointer crosses the gutter. The engine is faithful to the order it built; the order is what is mirrored.

Two more consequences fall out of the same axis:

• A point inside the right column but below its last line is not clamped to that column — the head lands in the left column at the same y.
• Shift+ArrowDown does not cross the column boundary at all: from a verified caret on line 23 it ends up selecting 04–23, i.e. the head jumped above the anchor to the top of the first column.

So there is no keyboard workaround either. Selecting inside a single column works, and Ctrl+A works.

Reproduction

Any Hebrew document with two columns. Minimal path:

1. New document, section with <w:bidi/> (Word writes this for a Hebrew document).
2. Layout → Columns → Two.
3. Type or paste enough text to overflow into the second column.
4. Observe that paragraph 1 is on the left.

The exported .docx is correct throughout — <w:cols w:num="2" w:equalWidth="1"/> and <w:bidi/> both round-trip, and the file opens correctly in Word. The damage is in rendering and interaction only.

Where it comes from

SectionDirectionContext in packages/layout-engine/contracts/src/direction-context.ts already documents pageDirection (from w:sectPr/w:bidi) as governing "section-level chrome only (page numbers, columns, gutters)". But ColumnGeometry measures x "from the content-area left edge", and no function in the column geometry takes a direction. The axis is documented and never consumed.

A control run confirms it: the same document in English, with no w:bidi at all, produces byte-identical geometry — so direction is not read on the column axis in either case.

Environment

superdoc@2.10.0 (@superdoc/docx-engine@0.9.0). Also checked 2.11.0-next.9: layout-engine/contracts/src/column-layout.d.ts is byte-identical there, and no column-geometry signature takes a direction, so this is still open on next.

I have a fix for the geometry side and will open a PR referencing this issue.

[linear-code]

IT-1557

[Nathaniel-260]

Status note, so this does not get re-reported or closed early.

#3953 implements the consumer half of this and is open for review, but it will not close this issue. I have dropped the Fixes keyword from it deliberately: merging it does not change what a real document renders.

What #3953 does: ColumnLayout gains an optional direction, and buildColumnGeometry mirrors the column strip when it is 'rtl', so the first column is painted on the right while index stays fill order. That is the geometry half of the problem described here, and it is tested.

What is still missing, and why this stays open: nothing assigns that field. Verified across the tree —

• grep -rn "pageDirection" returns only the field declaration in direction-context.ts and two generated .d.ts copies. Nothing constructs a SectionDirectionContext anywhere in production code.
• No importer parses w:sectPr/w:bidi. Every bidi reference in production code is paragraph-level (w:pPr/w:bidi) or run-level (w:rtl); section-level w:bidi appears only inside comments describing behaviour that was never implemented.
• No other open or merged PR wires it. The nearest, fix(direction): auto-detect paragraph base direction via dir="auto" #3714, is paragraph base direction via dir="auto" — ECMA-376 keeps §17.3.1.6 paragraph direction and §17.6.1 section direction separate, and that is the former.

So the section-direction contract is a declared-but-unbuilt surface that predates this work. Closing the gap needs an importer change: read w:sectPr/w:bidi and set SectionBreakBlock.columns.direction from it. That is a different subsystem from column geometry, which is why it is not bundled into #3953.

Happy to take that on as a follow-up if a maintainer wants it from me — say so here and I will open it against main once #3953 lands.

[caio-pizzol]

Thanks for putting this together @Nathaniel-260. We confirmed that your PR covers the public layout-engine part of the fix. In our full pipeline, the section direction is already read, but we still need to connect it to the column layout internally. We’ll review your PR and handle that internal connection separately. The two selection problems are separate issues, and we’re tracking those independently.

[caio-pizzol]

Thanks again for the detailed report and PR. We’ve now fixed the RTL column order, and the fix is available in superdoc@2.12.0-next.20. We tested it with your original RTL document and an LTR control.

We also confirmed that the two selection problems are separate issues. We’re working through those next and will follow up here once those fixes are ready.