[KnifeLemon]

Summary

Fixes the latest report in #49: in a HWP file, a table inside a table cell (the 연번/행정정보명 table in the user's form) was drawn about 55 mm (156 pt) lower than in 한글, on top of the paragraph below it. The same document saved as HWPX was fine.

Cause

• 한글 stores the line of a paragraph that anchors a floating table (treatAsChar=0, vertRelTo=PARA, TOP_AND_BOTTOM) below the table.
• rhwp export-hwpx marks its output with META-INF/rhwp-hwp5-origin. For files with that marker, rhwp follows the stored line positions.
• Inside a table cell taller than its text, that means rhwp draws the table from the stored line instead of the top of its paragraph. The table ends up shifted down by its own height.

Fix

• RhwpInput.Prepare gains AnchorTablesInCells. It applies only to HWPX converted from HWP, i.e. files with the marker.
• It targets a paragraph inside hp:tc/hp:subList that holds just one such table, no text, and a single lineseg.
• For that paragraph it moves the line's vertpos back to the paragraph start: vertpos − vertOffset − margins − height. That is only done when the result stays between the previous line and the original one.
• Nothing is drawn on that line, so only the table moves.
• The marker itself is kept, because it changes other rhwp behaviour for HWP files.

Result on the user's file

• The inner table is drawn where the HWPX version draws it.
• The content below it sits 0.85 mm lower than in the HWPX rendering. The HWP rendering follows 한글's stored positions, so it is actually closer to 한글.
• The HWPX input renders exactly as before.

Test plan

• New RhwpInputTests build a minimal HWPX in code. They cover the fix-up, paragraphs it must not touch, files without the marker, and a real rhwp render checked with PdfPig.
  • With the fix disabled, two of them fail.
• Engines, Core and dotnet format pass.
• Checked on the user's file in an isolated temp folder (not committed).

🤖 Generated with Claude Code