fix(docx): list export resolves markers through the shared PDF rules#164
Merged
Conversation
The semantic Word backend fell back to the flat-list marker for nested items (PDF uses the depth cascade) and skipped flat-item normalization (author-typed '- item' doubled as '• - item'; blank items emitted marker-only paragraphs). Marker knowledge now has one owner in the node package - ListMarker.defaultForDepth(int) and ListMarker.normalizeItemText(String, boolean) (@SInCE 1.8.0) - and TextFlowSupport and DocxSemanticBackend both delegate to it. Two DocxSemanticBackendTest expectations updated from the old divergent behavior to the parity contract; 6 new DocxListParityTest cases. Full verify: BUILD SUCCESS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two PDF ↔ DOCX list divergences found by the post-merge review of #161:
DocxSemanticBackend.writeNestedItemfell back to the flat-list marker, while the fixed-layout pipeline uses the depth cascade (•→◦→▪→·) — the same session produced◦ childin PDF and• childin Word.marker.prefix()onto raw item text, so an author-typed"- item"doubled up as"• - item"and blank items emitted marker-only paragraphs (the PDF path strips typed markers and skips blanks vianormalizeListItem).How
Marker knowledge gets one owner in the node package:
ListMarker.defaultForDepth(int)andListMarker.normalizeItemText(String, boolean)(@since 1.8.0).TextFlowSupportandDocxSemanticBackendboth delegate; the two private copies inTextFlowSupportare deleted.Verification
DocxListParityTestcases: depth cascade, explicitmarkerForprecedence, author-typed marker stripping (-/•/*/+),**boldnot mistaken for a marker, blank items dropped,normalizeMarkers(false)raw mode.DocxSemanticBackendTestexpectations updated — they pinned the old divergent behavior (the comments now explain the parity contract).word-export-companion.docxpreview verified content-stable (its depth-0 hits the cascade bullet either way; depths 1–2 aremarkerFor-baked) — no asset churn../mvnw verify -pl .— BUILD SUCCESS.