[KnifeLemon]

What does this change?

Implements the Project 4 item "Layout engine: honor stored HWP/HWPX line layout (fidelity mode)".

Stacked on #834 (paragraph layout). The base is engine/paragraph-layout for a readable diff; it moves to builtin-engines once #834 is merged.

Why

An HWPX that 한글 saved stores each paragraph's lines (hp:linesegarray: start, height, baseline, position, width). 한글 itself draws from them when it opens the file; it does not break the lines again. I checked this with 한글 through automation:

• In the 강사카드 form from PPT/한글(HWP) -> PDF 이런 변환은 글자 배열이 틀어지네요. #49, the stored line of 75 hyphens no longer fits. 한글 keeps it on one line and narrows the space between characters to fit it in.
• With the stored lines removed from the same file, 한글 breaks it into 70 + 5 characters, exactly where Filee breaks it.

Reader: 한글 positions → model positions

• Counting rules: 한글's text positions follow the control-character table of Hancom's HWP 5.0 format document.
  • Eight positions for every inline or extended control: tab, field begin/end, section and column definitions, tables, objects, equations, notes, header/footer, numbers, bookmarks, title marks.
  • One position for a line break, non-breaking space, fixed-width space or hyphen.
• Conversion: the paragraph builder counts both ways while it reads, and converts the stored starts into positions in the layout's text (HLineLayout.Starts).
• No positions kept: for a paragraph that a table splits, and for a start that falls inside an object.

Layout

• When stored lines are used: the lines are not marked as estimated by Filee, and every font of the paragraph is installed under its name or another of its names.
• What the lines take from the stored layout:
  • their starts, with a list number put in front;
  • their stored height and baseline;
  • their place beside an object (horzpos / horzsize).
• A stored line wider than its line now is squeezed between its characters.
• Otherwise the paragraph is broken again, and ParagraphBox.StoredLinesIgnored says why.
• ParagraphLayouter(storedLines: false) and FileeRenderer.ToPdf(storedLines: false) turn it off, for tests and a future preview setting.

Measured on the HWPX files attached to Filee's issues (#49, #51, #65; not in the repository)

• Conversion: 768 of the 769 paragraphs with stored lines convert. The converted starts fall on spaces and syllable boundaries.
• Against 한글's own PDF (exported by 한글 automation), 행정정보동의서 (single column):
  • line agreement goes from 46.4% to 82.1%;
  • every line of body text is the same as 한글's;
  • the rest is the table area and the page break after it.
• The other three documents are dominated by tables, two-column pages and equations, which later items lay out. Their document-level numbers mean little until then.

Tests

• DocumentModelTests: positions convert across a tab, a footnote, a line break and an equation. A start inside an equation keeps no positions, and neither does a paragraph split by a table.
• ParagraphLayoutTests:
  • lines start where they were stored, with the stored height and baseline;
  • a stored line that no longer fits is squeezed;
  • a list number shifts the stored starts;
  • a line beside an object keeps its place;
  • stored lines are ignored when estimated, when a font is missing or when they don't map;
  • the off switch works.
• Engines suite locally: 2308 passed, 0 failed.

🤖 Generated with Claude Code