Documents Now Write Headings the Way Univer's Own Ribbon Reads Them
A mismatch between how Documents stored heading levels and how the underlying Univer engine expects them meant headings from templates and imports rendered at the wrong size — now fixed.
Documents has fixed a bug where a document's headings could render at the wrong size — or lose their heading formatting entirely — depending on where they came from.
What was broken
The code that builds Drive's document model, toUniverDocument, was storing a heading's level directly in the field Univer's own rendering engine uses for something more specific: namedStyleType, whose actual enum runs 1 for normal text, 2 for Title, 3 for Subtitle, and 4 through 8 for Heading 1 through Heading 5. Because Drive was writing raw heading levels into that field instead of the enum values Univer expects, an H1 pulled in from a template or a .docx import read as "Normal" to Univer and rendered at body text size, while an H2 read as "Title" and rendered larger than the H1 sitting above it.
The reverse direction had its own bug: when someone applied a heading style from Univer's own ribbon, it wrote a random six-character headingId rather than a plain number. Documents' reader was trying to parse that ID as a numeric level, getting NaN, and silently exporting the heading as an ordinary paragraph — so a heading applied through the UI could quietly lose its heading status on save.
The fix
A new headingLevelOf() function now checks Drive's own h<n> heading marker first — present on every row saved before this fix, including existing content — and falls back to reading Univer's enum second, covering headings that only ever existed in Univer's format. Five tests were written and confirmed failing before the fix landed.
Why it matters
This is a compatibility fix, not a new feature: heading levels set via templates, .docx imports, or the ribbon should now render consistently and survive a save-and-reopen cycle, regardless of which path created them.