Comparing changes

@page

Add comprehensive test suite (FeatureVerificationTests.cs) that verifies all 8 resolved features in the WmlToHtmlConverter gaps document: - @page CSS rule generation (GeneratePageCss setting) - Table DXA width conversion (twips to points) - Borderless table detection (data-borderless attribute) - Theme color resolution (ResolveThemeColors setting) - Document language on <html> element - Foreign text language spans (lang attributes) - Font fallback improvements (serif/sans-serif/monospace) - CJK font-family fallback chains (Japanese, Chinese, Korean) All 15 tests pass, confirming the features work correctly. Also updates gaps document with verification summary table.

test(converter): add feature verification tests for resolved gaps

When rendering footnotes/endnotes, Word documents contain runs with w:footnoteRef or w:endnoteRef elements that display the note number inside the note text. Since we add note numbers separately (via footnote-number span in paginated mode or <ol> value in non-paginated mode), these runs produced empty styled spans causing whitespace issues. This fix detects runs containing only w:footnoteRef or w:endnoteRef and returns null, preventing the creation of empty spans in the HTML output. - Add check in ConvertRun() to skip footnoteRef/endnoteRef-only runs - Add tests for both paginated and non-paginated footnote rendering

- Remove brackets from footnote/endnote reference numbers ([2] → 2) - Put inside anchor tag like LibreOffice does - Skip span wrapper for runs containing only footnote/endnote references to prevent whitespace issues from nested elements - Move backref arrow inside last paragraph to prevent line breaks - Skip runs containing only w:footnoteRef/w:endnoteRef placeholders Before: <a>[2]</a> After: <a class="footnote-ref">2</a> LibreOffice: <a class="sdfootnoteanc">1</a>

fix(converter): skip footnoteRef/endnoteRef runs to prevent empty spans

…ment

…ce-alignment feat(converter): align footnote/endnote rendering with LibreOffice

- Remove white-space: pre-wrap from default CSS to match LibreOffice behavior - Add ConvertTextWithNbsp() to convert significant whitespace to   entities (multiple consecutive spaces, leading/trailing spaces in text runs) - Add NormalizeInlineWhitespace() to remove whitespace text nodes between inline elements in the XElement tree - Add ToHtmlString() helper method for proper HTML serialization that removes formatting whitespace between inline elements while preserving indentation This ensures that HTML formatting (newlines/indentation) doesn't create visible spaces between adjacent spans/anchors in the rendered output, matching how LibreOffice generates HTML from DOCX documents.

Use \u00A0 character instead of   entity to ensure HTML output can be parsed as valid XML by tests.

feat(converter): align whitespace handling with LibreOffice HTML output

…output Previously, DefineLineHeight() unconditionally added `line-height: 108%` to all unidirectional paragraphs. This made text appear more compressed than LibreOffice's HTML output, which doesn't set any explicit line-height and lets browsers use their default (~120%). Changes: - Remove the hardcoded 108% line-height default from DefineLineHeight() - Line-height is now only set when explicitly specified via w:lineRule in the document (already handled by CreateStyleFromSpacing) This improves visual alignment with LibreOffice's HTML rendering for paragraph and line spacing.

fix(converter): remove default 108% line-height to match LibreOffice output

Fix incorrect multi-level list numbering when items continue a flat sequence at different indentation levels. Documents with items like 1., 2., 3. at level 0 followed by item at level 1 (with start=4) now render as "4." instead of "3.4". The fix adds "continuation pattern" detection in ListItemRetriever.cs: - Detects when a deeper-level item continues a flat list sequence (start value equals parent counter + 1) - When detected, uses level 0's format string with current counter - Tracks continuation state per level with inheritance - Resets deeper level tracking when going to shallower levels Also adds: - docs/ooxml_corner_cases.md for documenting OOXML edge cases - CLAUDE.md section on documenting corner cases

…ontinuation patterns When a list item is detected as a "continuation pattern" (deeper-level item that continues a flat sequence), the converter now uses level 0's properties for: - Run properties (rPr) - fixes underline appearing incorrectly - Paragraph properties (pPr) - fixes tab stops and indentation Changes: - FormattingAssembler.cs: Use GetEffectiveLevel() in NormalizeListItemsTransform, ParaStyleParaPropsStack, and AnnotateParagraph functions - ListItemRetriever.cs: Made ContinuationInfo class internal for cross-file access - Updated CHANGELOG.md and docs/ooxml_corner_cases.md with fix details

Added two tests to verify the continuation pattern fix: - HC050_ContinuationPattern_RendersCorrectNumber: Verifies items at ilvl=1 with start=4 render as "4." instead of "3.4" - HC051_ContinuationPattern_UsesLevel0Formatting: Verifies continuation items use level 0's run properties (no underline when level 1 has underline) These tests create programmatic documents with multi-level numbered lists to verify the fix handles the edge case correctly.

…tting Clone numberingParaProps before removing non-indent elements to avoid mutating the original numbering definition. This was causing subsequent list items using the same numbering level to lose their tab definitions, resulting in inconsistent wrapper span widths (0.5in instead of 0.25in). Also updated CalculateSpanWidthTransform to check accumulated properties (pt:pPr) first for indentation and tabs, falling back to direct properties (w:pPr) if not found.

…tion fix(converter): handle legal numbering continuation pattern

Per ECMA-376, the w:id attribute on footnoteReference/endnoteReference elements is a reference identifier linking to definitions, not the display number. Display numbers should be sequential (1, 2, 3...) based on document order. Previously, we incorrectly used raw XML IDs (e.g., 2, 3, 4...) as display numbers, causing footnotes to be numbered starting from 2 instead of 1. Changes: - Add FootnoteNumberingTracker class to map XML IDs to sequential display numbers based on document order - Update ProcessFootnoteReference/ProcessEndnoteReference to use display numbers instead of XML IDs - Update RenderFootnotesSection/RenderEndnotesSection to order notes by document order and use correct display numbers - Update RenderPaginatedFootnoteRegistry for pagination mode - Update documentation in docs/ooxml_corner_cases.md

fix(converter): use sequential display numbers for footnotes/endnotes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Dec 21, 2025

Commits on Dec 22, 2025

Commits on Dec 23, 2025

Commits on Dec 24, 2025

This comparison is taking too long to generate.

Uh oh!