[layout] HWP5 계보 조판 프로파일이 줄 상자를 15px 넘는 두 글자를 받아들이고 자간을 균등 축소한다 — 같은 문서 HWPX 는 44자, HWP5 계보는 46자 (한/글 정본 44, #7416 선행축)

[planet6897]

관측된 문제

같은 내용의 HWPX 두 본을 rhwp 가 재조판하면 한 줄에 담는 글자 수가 다릅니다. 내용·글자모양·문단모양·글꼴·칸 속성이 모두 같은데, HWP5 계보 표시가 있는 본은 줄 상자를 15px 넘는 두 글자를 더 받아들이고 자간을 균등 축소해 밀어 넣습니다.

한/글 출력은 두 글자를 받지 않습니다.

재현 — 마커 한 줄

rhwp export-hwpx 는 HWP5 에서 변환한 HWPX 에 META-INF/rhwp-hwp5-origin 마커를 넣습니다. 이 마커가 Document::layout_profile() 의 hwp5_origin_hwpx 를 켭니다.

# 1) 원본 HWP5 를 HWPX 로 변환
rhwp export-hwpx samples/issue6639/rhwp-table-cell-minimal-repro.hwp /tmp/orig.hwpx
# 2) 대상 칸 10문단의 hp:linesegarray 를 제거해 rhwp 가 직접 조판하게 한다
# 3) 그 파일에서 META-INF/rhwp-hwp5-origin 만 빼고 다시 압축한다
rhwp export-svg /tmp/orig_nocache.hwpx  -o /tmp/a   # 마커 있음
rhwp export-svg /tmp/no_marker.hwpx     -o /tmp/b   # 마커 없음

	연속 줄 글자	대상 칸 줄 수	글자 전진폭
마커 있음 (HWP5 계보 프로파일)	46	24	11.0748px
마커 없음 (HWPX 프로파일)	44	25	11.40px
한/글 정본 PDF	44	25	—

기준: pdf/issue6639/issue6639-original-160-2020.pdf. 같은 문서의 한/글 저장 HWPX(issue6639-hancom-160.hwpx)에서 같은 문단의 줄 캐시만 지운 본도 44 입니다.

실측 — 받아들인 뒤 균등 축소한다

SVG 의 글자별 x 간격을 직접 재면 줄 전체가 균일합니다.

44자 줄   간격 11.4000  × 43   (자연 전진폭, 맑은 고딕 9pt 장평 95%)
46자 줄   간격 11.0748  × 45

46 × 11.40  = 524.4px   ← 자연 폭
줄 상자                = 509.44px
524.4 → 509.44 압축비   = 0.97147  = 11.0748 / 11.40

즉 폭을 다르게 잰 것이 아니라, 상자를 14.96px 넘는 두 글자를 받아들인 뒤 줄 전체를 0.97147배로 균등 축소한 것입니다. 두 렌더의 glyph scale(0.9747,1) 은 동일하므로 글꼴 축도 아닙니다.

line_break_tolerance_hwp 의 여유는 상자 폭 509.44px(38,208 HWPUNIT)에서 최대 50 HWPUNIT(0.67px)이라 두 글자(1,710 HWPUNIT)를 설명하지 못합니다.

배제한 후보 — 두 입력은 이 마커 말고 같습니다

항목	결과
hh:paraPr 원문	borderFillIDRef id 외 완전 동일(BREAK_WORD / KEEP_WORD / condense=0 / snapToGrid=0 / LEFT)
hh:charPr 원문	id·borderFillIDRef 외 완전 동일(height 900, ratio hangul 95 / latin 92, spacing 0)
글꼴 표	HANGUL·LATIN 모두 id=0 → 맑은 고딕 로 동일
대상 문단 본문 XML	hp:p id / charPrIDRef 외 동일
hp:tc (칸 33개)	양쪽 모두 lineWrap 속성 없음
hh:layoutCompatibility	rhwp 본을 한/글 본과 같게 치환해도 46 유지 → 배제
hh:linkinfo pageInherit	1 로 맞춰도 46 유지 → 배제
lastSavedWith.product	양쪽 모두 hancom-office-2020
META-INF/rhwp-hwp5-origin	제거하면 46 → 44

왜 지금 찾았나 — #7416 의 선행축입니다

#7416(자기 모순 저장 사다리)에서 「사다리를 버리면 정본에 맞는가」를 A/B 하다 나왔습니다. 대상 문서의 사다리를 버리면 24줄 / 46자 / 상자 15px 초과가 되어 정본(25줄 / 44자)에서 더 멀어집니다. 원인이 사다리 판별자가 아니라 이 프로파일이었습니다.

이 결함을 먼저 고치면 #7416 의 사다리 폐기가 정본과 정확히 일치합니다(44자·25줄·26 글줄, 위 표의 「마커 없음」 행).

조사 및 완료 조건

• 코드 게이트가 아직 특정되지 않았습니다. native_hwp5_layout 은 HeightMeasurer 로 가고, hwp5_origin_hwpx 의 현재 유일한 소비처 uses_hwp3_origin_flow_spacing_before(document_core/queries/rendering.rs:766)는 HWP3 계보 전용이라 이 문서(HWP5)와 무관합니다. 줄 채움 쪽에 다른 경로가 있습니다.
• 코퍼스 범위를 측정하지 않았습니다. samples/** 의 형식 분포는 hwp5 596 · hwpx 523 · hwp3 26 이고 native HWP5 는 전부 같은 프로파일을 탑니다. 다만 이 갈래는 저장 줄이 없어 재조판할 때만 드러나므로 실제 발현 빈도는 별도로 재야 합니다.
• 프로파일이 상자 초과를 허용하는 것이 의도된 호환 동작인지 확인해야 합니다. 의도라면 이 문서에서 왜 한/글과 갈리는지, 아니라면 어느 조건에서 꺼야 하는지를 정합니다.
• 수정 뒤에는 쪽수 원장·넘침/겹침 래칫·정본 대조로 A/B 합니다. 상자 초과를 막는 변경은 줄 수를 늘리므로 쪽수에 영향이 갈 수 있습니다.

비범위

• #7407 의 A2a(#7410)·A2b(#7414)는 줄 상자와 글자 폭 축이며 이 이슈와 별개입니다. 두 경로가 같은 상자 509.44px 를 쓰는 것은 위 실측으로 확인했습니다.
• #7416 의 사다리 유효성 판별은 이 이슈가 해결된 뒤 재판정합니다.

[planet6897]

근인을 특정했습니다 — 문단 좌우 여백을 안 뺀 칸 상자가 세 곳 더 남아 있습니다

프레임이 잘라 주는 구간 폭을 직접 찍었습니다.

마커 있음(HWP5 계보)   D_CARVE n=1 widths_hu=[40808]   × 47회 전부
마커 없음(HWPX)        D_CARVE n=1 widths_hu=[39208]   × 25회
                       D_CARVE n=1 widths_hu=[40808]   × 10회

차이 1,600 HWPUNIT = 이 문단의 좌우 여백 800 + 800 입니다.

40808 은 #7407 A2a 에서 확인한 수정 전 값(칸 안쪽 폭 전체)이고, 39208 은 한/글이 그 칸에 적어 둔 horzsize 입니다.

산술도 맞습니다.

40808 − 내어쓰기 1000 = 39808 HWPUNIT = 530.77px
530.77 / 11.40 = 46.6  →  46자      (관측 46자)
39208 − 1000 = 38208 HWPUNIT = 509.44px
509.44 / 11.40 = 44.7  →  44자      (관측 44자 · 한/글 정본과 같음)

측정 입력은 두 본이 동일합니다

프레임 채움의 토큰 폭을 찍으면 두 입력이 같습니다.

D_FILLW tok=5..132 base_per=11.4000 per=11.4000 ncw=127 nbcw=127 kern=false   (양쪽 동일)

즉 글자 폭·커닝·장평 축이 아니고, 오직 프레임에 넘어간 가용 폭만 다릅니다. 앞 코멘트에서 「받아들이고 압축한다」고 쓴 것도 정확히는 더 넓은 상자로 채운 뒤 좁은 상자에 그린 것입니다.

남아 있는 세 곳

ParagraphBox 는 frame_with() 로 프레임을 만들고, recompose_stored_lines_in_frame_with_known_square_band 는 그 box 를 인자로 받습니다. 즉 어떤 box 를 건네느냐는 호출부가 정합니다. 제품 코드에서 아직 여백을 안 뺀 생성자를 쓰는 곳:

위치	함수
src/renderer/composer.rs:1985	칸 적합 판정
src/renderer/composer.rs:2294	reflow_cell_line_ignoring_stored_segs
src/renderer/composer.rs:2319	recompose_horizontal_cell_lines_for_width

세 곳 모두 ParagraphBox::content_width_px(cell_inner_width, dpi) 입니다. #7410 이 content_for_style 로 바꾼 자리와 같은 결함이며, 그 PR 이 닿지 않은 형제 경로입니다. HWP5 계보 프로파일은 이 중 한 경로로 들어갑니다.

ParagraphBox::body 의 주석이 경고하는 그대로입니다 — "One paragraph must not get two different boxes depending on which route reached it."

그래서 수정 방향

세 호출부를 #7410 과 같은 ParagraphBox::content_for_style 로 통일하는 것이 자연스럽습니다. 다만 각 경로의 적용 조건이 다르므로 경로별로 적용/비적용을 확인해야 하고, 칸 폭을 바꾸는 recompose_horizontal_cell_lines_for_width 는 편집 계약이 걸려 있을 수 있습니다.

미검증

• 이 문서가 세 곳 중 어느 경로로 들어가는지는 좁히지 않았습니다(구간 폭 40808 로 확인했을 뿐).
• 세 곳을 모두 바꿨을 때의 코퍼스 A/B(쪽수 원장·래칫·정본 대조)는 미실행입니다. #7410 이 samples 1,148 전수에서 쪽수 변화 0 이었으므로 비슷할 것으로 보이나 측정 전에는 단정하지 않습니다.
• 진단 probe(RHWP_DIAG_FILLW)는 커밋하지 않았습니다. 측정 SHA 는 3d18a31ec(#7414 head)입니다.

[planet6897]

수정 제출 — PR #7424

근인 코멘트에서 지목한 세 호출부를 #7410 과 같은 ParagraphBox::content_for_style 로 통일했습니다.

위치	함수
src/renderer/composer.rs:1985	칸 적합 판정
src/renderer/composer.rs:2294	reflow_cell_line_ignoring_stored_segs
src/renderer/composer.rs:2319	recompose_horizontal_cell_lines_for_width

새 조건·임계값·문서별 예외는 넣지 않았습니다.

기대값과 회귀 검사

pdf/78494-virtual-convergence-industry-decree-2020.pdf 37쪽 첫 줄이 법인 또는 단체일 것 한 줄입니다.

한/글 정본     … 지원센터의      / 설치 목적 … 가능한 / 법인 또는 단체일 것
도입 전 rhwp   … 지원센터의 설치 / 목적 … 법인 또는   / 단체일 것
수정 후 rhwp   … 지원센터의      / 설치 목적 … 가능한 / 법인 또는 단체일 것

tests/cases/issue_7422_recomposed_cell_frame_uses_paragraph_margins.rs 가 render tree 에서 그 줄을 확인하며, 부모 3d18a31ec 에서 FAIL, 이 PR bd0660d31 에서 PASS 입니다.

⚠ 처음 쓴 검사는 결함을 잡지 못했습니다. issue6639 의 한/글 HWPX 를 썼는데 그 입력은 이미 #7410 이 고친 경로를 타서 수정 전에도 통과했습니다. 실제 결함 경로를 타는 문서로 다시 썼습니다.

검증

전체 nextest 10,210 중 10,209 통과(실패 1건은 골든 CRLF 환경 실패로 #7414 CI 에서는 통과), lint 5단계 통과, 쪽수 원장 594문서 개선 0 회귀 0, samples/** 1,148건 SVG A/B 변화 3문서·쪽 수 변화 0건입니다.

프로파일 갈림은 사라졌습니다 — META-INF/rhwp-hwp5-origin 마커 유무가 더 이상 결과를 바꾸지 않고, 양쪽 모두 44자·25줄로 한/글 정본과 같습니다.

이 이슈의 완료 조건 대비

• 「코드 게이트 특정」 — 완료(위 세 곳).
• 「프로파일이 상자 초과를 허용하는 것이 의도된 호환 동작인지」 — 비해당으로 판명. 프로파일이 초과를 허용한 것이 아니라, 그 프로파일이 타는 경로가 여백을 안 뺀 상자를 받았을 뿐입니다.
• 「코퍼스 범위 측정」 — 실제 발현은 3문서였습니다(samples 1,148 전수).
• 「수정 뒤 A/B」 — 완료(위 표).

남는 것은 세 쪽의 기존 세로 어긋남이며 이 이슈의 범위 밖입니다. PR 병합 후 #7416 의 사다리 폐기 A/B 를 다시 돌리면 #7407 이 닫힙니다.