fix(tables): expand auto-width tables to fill available page width#2109
fix(tables): expand auto-width tables to fill available page width#2109
Conversation
Tables without explicit w:tblW (or with type="auto") were rendering at a fraction of the page width instead of filling the available content area like Word does.
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
There was a problem hiding this comment.
Pull request overview
This PR fixes table layout behavior for auto-width tables in the measuring-dom layer. Previously, tables without explicit width (or with type="auto") only scaled down when too wide but never scaled up to fill available space, resulting in tables rendering at approximately 1/3 page width instead of filling the content area like Microsoft Word does.
Changes:
- Added
type='dxa'recognition inresolveTableWidth()to correctly identify DXA-width tables as having explicit width - Modified auto-layout branch to scale columns both up and down proportionally to fill available page width, following ECMA-376 autofit behavior
- Replaced the complex
scaleColumnWidths()function with inline scaling logic that uses simpler last-column rounding adjustment
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/layout-engine/measuring/dom/src/index.ts | Added 'dxa' type handling in resolveTableWidth(), removed scaleColumnWidths() helper function, updated auto-layout branch to scale columns proportionally to fill available width |
| packages/layout-engine/measuring/dom/src/index.test.ts | Updated 12 test expectations to reflect new auto-layout behavior where tables expand to fill available width |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…to full page width Updated the table measurement logic to prevent scaling up column widths when explicit widths are defined. Adjusted tests to reflect the new behavior where tables without explicit widths default to filling the available page content width, aligning with Word's autofit behavior.
1 participant
Summary
Closes SD-1956 https://linear.app/superdocworkspace/issue/SD-1956/bug-auto-layout-tables-with-explicit-tblgrid-tiny-tcw-render-squished
w:tblW(or withtype="auto") were rendering at ~1/3 page width instead of filling the available content area like Microsoft Word doesresolveTableWidth()not recognizingtype='dxa'— the most common explicit width type in OOXML — which caused dxa-width tables to incorrectly fall into the auto-layout pathWhy this was happening
The table measurement pipeline in
measureTableBlock()has two branches:hasExplicitWidth || hasFixedLayout): scales columns both up and down to match the declared table widthWhen a DOCX file has no
w:tblWelement (ortype="auto"),resolveTableWidth()returnedundefined, sohasExplicitWidthwasfalse. The auto-layout branch would receive narrow column widths from the import (e.g., 100px per column fromw:tcWcell widths or the fallback grid), and since the total was less than the page width, no scaling occurred.Additionally,
resolveTableWidth()only recognizedtype='pct'andtype='px'/'pixel', but nottype='dxa'— even thoughdxavalues are already converted to pixels during import by the tbl-translator. This meant tables with explicit dxa widths also fell into the auto-layout path.What we changed to prevent this
Scale up auto-layout tables (ECMA-376 §2.4.64): When a table has no explicit width, the layout algorithm (§2.4.49/§2.4.50) uses autofit, which in practice expands the table to fill the available page content width. The auto-layout branch now scales columns proportionally in both directions to match this behavior.
Handle
dxatype inresolveTableWidth(): Addedtype='dxa'alongside'px'/'pixel'so that tables with explicit dxa widths are correctly recognized as having an explicit width, preventing them from being affected by the auto-layout scale-up.Test plan