What happened?
A Hebrew (RTL) Word document with three sections — single-column, two-column continuous, single-column continuous — where all three sectPr declare <w15:footnoteColumns w:val="1"/>.
Word lays the footnotes out as one strip across the whole content area, with the short w:separator rule at that strip's right edge. SuperDoc lays them out one body column wide, with the rule at that column's left edge.
These are two independent defects that happen to surface together.
1. w15:footnoteColumns is never read, so the band reuses the body's w:cols
Geometry read out of the DOM in Chrome against the packaged dist (data-layout-story identifies the note band), for A4 with 1800tw side margins and a 708tw gutter:
| Element |
x |
width |
| body paragraph, single-column section |
516 |
554 |
| body paragraph, column 0 |
516 |
253 |
| body paragraph, column 1 |
816 |
253 |
note band (data-layout-story="footnote:*") |
516 |
253 |
| what Word draws |
516 |
554 |
The numbers follow from the XML exactly: content area 11906 − 1800 − 1800 = 8306tw = 554px at 96dpi; one body column (8306 − 708) / 2 = 3799tw = 253px.
A second symptom falls out of the same reuse: the one note measurement width is the minimum body column width across the whole document, so a single two-column section in the middle narrows the notes of every single-column section as well.
2. The separator rule is pinned to the note column's left edge
<w:separator/> is not engine decoration — it is a run, inside its own paragraph in footnotes.xml (w:footnote w:type="separator", id -1). Its horizontal placement is therefore that paragraph's resolved inline direction, w:jc and w:ind.
In this document that paragraph declares no direction of its own:
<w:footnote w:type="separator" w:id="-1">
<w:p><w:pPr><w:spacing w:after="0" w:line="240" w:lineRule="auto"/></w:pPr>
<w:r><w:separator/></w:r></w:p>
</w:footnote>
and inherits from w:docDefaults/w:pPrDefault, which carries <w:bidi/> and <w:jc w:val="both"/>. Word draws the rule on the right.
Worth stating explicitly, because it is the tempting wrong fix: the section's w:bidi is not the signal here. The axes are independent (§17.6.1 for the section, §17.3.1.6 for the paragraph), and they do come apart — a Hebrew section whose separator paragraph resolves LTR gets a rule on the left in Word, and an LTR section whose separator paragraph resolves RTL gets one on the right. Keying the placement on the section direction renders both of those backwards.
Steps to reproduce
No attachment needed; the relevant markup is small enough to build a synthetic document from.
word/document.xml — three sections, the middle one two-column, w:bidi throughout, all three declaring a one-column note band:
<w:sectPr>
<w:footnotePr><w:numFmt w:val="hebrew1"/></w:footnotePr>
<w:type w:val="continuous"/>
<w:pgSz w:w="11906" w:h="16838"/>
<w:pgMar w:top="1440" w:right="1800" w:bottom="1440" w:left="1800"
w:header="708" w:footer="708" w:gutter="0"/>
<w:cols w:num="2" w:space="708"/>
<w:bidi/>
<w15:footnoteColumns w:val="1"/>
</w:sectPr>
word/styles.xml — an RTL paragraph default, which is what a Hebrew document normally carries:
<w:docDefaults><w:pPrDefault><w:pPr><w:bidi/><w:jc w:val="both"/></w:pPr></w:pPrDefault></w:docDefaults>
word/footnotes.xml — the default separator paragraph as Word writes it (shown above), plus one or more footnotes anchored in both body columns of the middle section.
- Open in SuperDoc, open the same file in Microsoft Word, and compare the note area on the page holding the two-column section.
Expected (Word): one note strip spanning the content area, its rule at the right edge.
Actual: a strip one body column wide, its rule at that column's left edge.
SuperDoc version
superdoc@2.11.1-next.1 / @superdoc/docx-engine@0.10.1-next.1
Browser
Chrome
Additional context
- Display only, not data loss: an open→export round trip returns
w15:footnoteColumns unchanged in all three sectPr.
- The element is a Word 2012 extension (
http://schemas.microsoft.com/office/word/2012/wordml) and appears in mc:Ignorable, so skipping it is well-formed — just not faithful.
- Fixing this needs both halves of the stack: the layout side (the band's own column layout, the measurement width, the reference→stack mapping, the reserve, and the separator's x) and the importer side (reading
w15:footnoteColumns off sectPr, and resolving the separator paragraph's w:pPr through its style chain). A PR for the layout half follows this issue.
- Happy to split this into two issues if you would rather triage the band geometry and the separator placement separately.
What happened?
A Hebrew (RTL) Word document with three sections — single-column, two-column
continuous, single-columncontinuous— where all threesectPrdeclare<w15:footnoteColumns w:val="1"/>.Word lays the footnotes out as one strip across the whole content area, with the short
w:separatorrule at that strip's right edge. SuperDoc lays them out one body column wide, with the rule at that column's left edge.These are two independent defects that happen to surface together.
1.
w15:footnoteColumnsis never read, so the band reuses the body'sw:colsGeometry read out of the DOM in Chrome against the packaged dist (
data-layout-storyidentifies the note band), for A4 with 1800tw side margins and a 708tw gutter:data-layout-story="footnote:*")The numbers follow from the XML exactly: content area
11906 − 1800 − 1800 = 8306tw = 554pxat 96dpi; one body column(8306 − 708) / 2 = 3799tw = 253px.A second symptom falls out of the same reuse: the one note measurement width is the minimum body column width across the whole document, so a single two-column section in the middle narrows the notes of every single-column section as well.
2. The separator rule is pinned to the note column's left edge
<w:separator/>is not engine decoration — it is a run, inside its own paragraph infootnotes.xml(w:footnote w:type="separator", id-1). Its horizontal placement is therefore that paragraph's resolved inline direction,w:jcandw:ind.In this document that paragraph declares no direction of its own:
and inherits from
w:docDefaults/w:pPrDefault, which carries<w:bidi/>and<w:jc w:val="both"/>. Word draws the rule on the right.Worth stating explicitly, because it is the tempting wrong fix: the section's
w:bidiis not the signal here. The axes are independent (§17.6.1 for the section, §17.3.1.6 for the paragraph), and they do come apart — a Hebrew section whose separator paragraph resolves LTR gets a rule on the left in Word, and an LTR section whose separator paragraph resolves RTL gets one on the right. Keying the placement on the section direction renders both of those backwards.Steps to reproduce
No attachment needed; the relevant markup is small enough to build a synthetic document from.
word/document.xml— three sections, the middle one two-column,w:bidithroughout, all three declaring a one-column note band:word/styles.xml— an RTL paragraph default, which is what a Hebrew document normally carries:word/footnotes.xml— the default separator paragraph as Word writes it (shown above), plus one or more footnotes anchored in both body columns of the middle section.Expected (Word): one note strip spanning the content area, its rule at the right edge.
Actual: a strip one body column wide, its rule at that column's left edge.
SuperDoc version
superdoc@2.11.1-next.1/@superdoc/docx-engine@0.10.1-next.1Browser
Chrome
Additional context
w15:footnoteColumnsunchanged in all threesectPr.http://schemas.microsoft.com/office/word/2012/wordml) and appears inmc:Ignorable, so skipping it is well-formed — just not faithful.w15:footnoteColumnsoffsectPr, and resolving the separator paragraph'sw:pPrthrough its style chain). A PR for the layout half follows this issue.