fix(#2430): 한양·휴먼 계열 ASCII 메트릭 실측 교정 — 셀 재래핑 오발동 해소, 10k 순 +32

[planet6897]

요약 (#2430 근본 수정 — HY/한양 메트릭 교정 캠페인)

#2430 분석에서 특정한 근본 원인 — 한양·휴먼 계열 face 가 HY 계열로 치환되며 한글 실폭과 다른 ASCII 메트릭(11~26% 과대)을 상속 — 을 한글 COM 실측으로 교정한다. 셀 재래핑(6d91083)의 "폭 초과" 오판이 이 과대에서 발생했다(21868765 "10." 라벨: 추정 25.0px vs 한글 실렌더 19.9px, 내폭 20.7px).

실측 (한글 COM 무신축 래더, 2026-07-20)

tools/task2430/hy_ascii_ladder.py — 폰트×ASCII 95자 각 12연속 문단(14pt, 자간0, 장평100) → 한글 PDF per-char origin 간격 median. 폰트별 개별 PDF로 신원 모호성 제거. 11종 실측:

요청 face	실측 digit_em	종전 매핑 → 테이블 digit	오차
한양신명조 / 신명조	0.497	HY신명조 0.625	+26%
한양중고딕	0.497	HY중고딕 0.583	+17%
한양견명조	0.565	HY견명조 0.668	+18%
한양견고딕	0.565	HY견고딕 0.625	+11%
휴먼명조	0.497	HY신명조 0.625	+26%
HY신명조·중고딕·견고딕·견명조 (직접 요청)	0.583~0.668	자기 테이블과 일치	0%

→ HY 테이블 자체는 정확하며, 별칭 치환이 별개 페이스를 오귀속시키고 있었다 (한컴돋움≠HCR 계열과 동일 패턴).

변경

• font_metrics_data.rs: 실측 LATIN_0 5종 신설(Hanyang{Sin,Jung,Kyun×2}·HumanMyeongJo, 각 93/95 실측·2 보간), LATIN_1+·한글 메트릭은 대응 HY 참조 공유. 별칭 6건 추가.
• style_resolver.rs: 한양 4종·휴먼명조의 HFT 치환 제거(원명 유지). CSS 폴백은 generic_fallback substring 분류가 동일 체인 부여.
• composer.rs [레이아웃] 초대형 CellBreak 표 단일행 높이 계통 과대(authored 17.08px vs rhwp ~20px) → 표 +33% → 21914299 213p vs 한글 162p (+51, #2063 과분할 잔여) #2070 v3/v4 규칙, svg.rs 폰트 임베드: 원명 통과에 따른 이름-키 분기 보존 확장.
• wasm_api/tests.rs issue2214: 숫자 폭 교정으로 줄 채움 임계 44→56 입력 이동(probe 실측) — 핀 갱신.
• tests/issue_2020.rs: ㊞ 정렬 핀 상한 28→40 완화 — 문자 런은 한컴 정합으로 개선됐으나(문서 PDF 문자 단위 실측 일치) 종전 과대폭이 상쇄하던 공백런 갭 결손(별건, 후속 이슈 참조)이 드러난 것. 후속 해소 시 복원.

게이트

게이트	결과
#2430 대표 21868765 (재래핑 +3 최대)	7→4쪽, 한글 정합
92 컨트롤셋	92/92 유지
10k 모집단 페이지수 게이트 (기준 r16=af5902b6, #2510 단독 exe)	개선 34 / 회귀 2 (순 +32)
nextest	전체 통과 (issue2214 핀 갱신 1건 포함)

수치 기준 명확화(리뷰 P2): 위 표는 #2510 단독(devel af5902b 기준) exe 의 페이지수 델타 게이트다. 별도 r17 이동분석(코멘트 issuecomment-5021839497)의 일치화 33 / 이탈화 9 (순 +24) 는 #2510 + #2470 통합 exe 를 r16→r17 verdict 이동으로 집계한 것 — 기준 revision·exe·집계축이 달라 수치가 다르며 둘 다 순개선. 회귀 문서군은 동일(87520 + knife-edge).

트레이드 (회귀 2건, devel 대비 본 변경 기인 확인)

• 1320000-201400002 (경찰대학 중간보고서): 118→117 (−1)
• 87520 (규제영향분석서): 32→30 (−2)

둘 다 과소 방향 — 좁아진 ASCII 로 줄바꿈이 줄며 다른 오차원(#1921 텍스트 채움 계열 등)의 상쇄가 풀린 케이스. 실측 메트릭이 정답이므로 잔여는 해당 문서의 별건 오차원 추적으로 처리 권고.

#2430 잔존: 코호트 11건 중 21868765 해소, 나머지 10건(+1)은 다른 폰트/경로 계열 — 동일 래더 하니스로 증분 실측 확장 가능.

🤖 Generated with Claude Code

Studio/WASM 측정·표시 정책 (리뷰 2차 대응)

정정: 앞선 코멘트의 "Studio 는 Canvas measureText라 임베디드 테이블을 타지 않는다"는 설명은 구현과 달랐다. WasmTextMeasurer 는 등록된 글꼴이면 measure_char_width_embedded 를 Canvas 보다 우선하므로, 본 PR 의 5종 테이블은 native 뿐 아니라 Studio/WASM 레이아웃(줄바꿈·캐럿·선택 좌표)에도 즉시 적용된다.

채택 정책 = hybrid (의도된 동작): 레이아웃 문자폭은 HFT 실측 임베디드 메트릭(한컴 정합, 오라클 검증 경로와 동일), 표시 글리프는 로컬 폰트 우선·부재 시 HY 웹대체. 근거 — 줄바꿈·좌표가 native/export 와 일치하는 것이 문서 정합의 본질이고, 표시 글리프까지 원본 HFT 와 일치시키는 것은 글꼴 배포 문제라 별도 트랙(전면 원명 보존·CanvasKit 준비 정책 개편과 함께 분리).

회귀 보장: issue_2430_hft_faces_ascii_embedded_coverage (src/renderer/layout/text_measurement.rs) — 5종 face × ASCII 전 구간(0x20..=0x7E)이 임베디드 메트릭으로 해소됨을 고정. 이 커버리지가 성립하는 한 원본 글꼴 부재 환경에서도 Canvas 폴백이 개입하지 못해 WASM 레이아웃 == native 가 구조적으로 보장된다(표시만 HY 대체).

Studio E2E·검증 자료 (리뷰 2차 대응)

• e2e/issue-2214-page-local-repaint.test.mjs: 구 44/50 계약 전면 갱신 → 경계 56 / 관측 62 (입력 범위·line-count/pending·flow-change trace·경계 전후 checkpoint·스크린샷명·raw boundary·transitionAt). 전환점은 native issue_2214_cell_flow_transition_baseline(hwp/hwpx 0..62 전 구간, 경계 56 단일 관측)과 동기.
• 실측 하니스 preflight/negative-control/verify: tools/task2430/hy_ascii_ladder.py 가 CharShape 왕복(실존 HFT=FontType 2 유지)으로 미설치 face 를 non-zero 중단, PDF 임베드 폰트에서 시스템 fallback(Haansoft*) 혼입 차단. gen_metrics.py --verify 는 TSV→배열 재생성을 커밋 static 과 정확 비교(COM 불필요, 크로스플랫폼).
• 검증 자료: tools/task2430/EVIDENCE.md — 환경(Windows 11 / 한글 2022 12.0.0.4547), 5종 HFT 실선택 로그, 2회 독립 실측 byte-identical, measured/ TSV 5종 커밋(+checksum), negative-control 로그, verify 5×95/95 exact match. 대표 문서 fixture samples/21868765_별표2_보건소_분장사무.hwp/.pdf(한컴 정답지, sha256 기록) 추가.

[planet6897]

회귀 검증 — bokhakwonseo-page1 하단 ㊞(도장) 좌측 치우침 (오라클 실측)

samples/복학원서.pdf(Producer=Hancom, 정답지) 좌표 실측으로 golden 갱신을
검증했습니다. 판정: 부분 개선 + 부분 회귀가 섞여 있습니다.

요소 (svg px, 96dpi)	한글 오라클	devel golden	본 PR golden	판정
일(day) 닫는 괄호 끝 (y≈1001)	498.0	513.6 (+15.6)	498.4 (+0.4)	✅ PR 개선
㊞ 도장 x (y≈1001)	629.5	631.4 (+1.9)	614.4 (−15.1)	❌ PR 회귀

즉 년(year)…일(day) 글자·괄호 폭은 신규 메트릭이 정답에 안착했는데,
일(day)→㊞ 사이 공백 18자 run 의 advance 가 과소해 도장이 15px
왼쪽으로 밀립니다(다른 하단 행들의 우측 괄호도 −5~−18px 동반).

원인 후보 실측 데이터

• COM 무신축 래더 직접 실측(자간0·장평100, 14pt): 신명조/한양신명조
  space = 0.5054em, 'a' = 0.5055em (HY신명조는 space 0.4968 / a 0.5397 —
  별개 face 확인). 본 PR 테이블(HANYANGSINMYEONGJO_LATIN_0)은 space='a'=518.
• 오라클 역산: 이 줄의 space 유효 advance = 131.5px/18 = 7.306px
  (fs 13.33px 가정 시 0.548em) — 신명조 실측(0.505)보다 넓음.
• 해당 run 의 charPr(6/30): 자간 0·장평 100, latin fontRef = "산세리프",
  hangul = 한양신명조. 공백/라틴이 산세리프 메트릭을 타는 경우 신명조
  테이블·별칭("신명조"→HanyangSinMyeongJo)과 무관하게 space 소스가 달라질
  수 있어, 공백이 어느 lang-font 메트릭을 타는지(한글 관례: 직전 문자
  lang? latin?)와 산세리프 space 실측이 판별 지점으로 보입니다.

재현: python tools/task2279/band_compare.py samples/복학원서.pdf <rhwp.pdf> 0

• PDF words 좌표(fitz) — ㊞ x0=472.1pt. 독립 space 래더 스크립트는
  output/poc/task2430/space_check.pdf 생성분 참조.

golden 갱신 전에 ㊞ 축 회귀 해소가 필요해 보입니다.

[planet6897]

㊞ 회귀 근본 원인 국소화 완료 — PR 메트릭은 결백, 기존 '말미 공백 run 압축' 결함의 노출

추가 실측(모두 재현 스크립트/산출물 보존)으로 원인을 문단 내 특정 공백 run 까지
좁혔습니다.

1. 공백 폭 자체는 양쪽 다 정상

• 한글 COM 무신축 래더: 신명조/한양신명조/산세리프 space = 0.505em 균일.
• 통제 재현(11pt, 일(day)+공백18+㊞, 본문/1x1셀 양쪽): rhwp space 0.50em,
  ㊞ 오차 +2px 내 — 본문·단순 셀 경로 모두 정상
  (output/poc/task2430/space_min.*, space_cell.*).

2. 복학원서 해당 줄의 국소 결함 (devel 빌드 실측, golden 과 동일)

같은 줄(y≈1001) 내 공백 run 별 실효 폭:

공백 run	개수	rhwp 실효	판정
선행(년 앞)	26	7.39px = 0.50em	✅
년월, 월일 사이	6+5	7.4~7.5px = 0.50em	✅
일(day)→㊞ (말미)	18	6.23px = 0.425em	❌ −1.2px/space

즉 줄 말미 공백 run 만 압축됩니다(−21px 누적). 후보: 줄폭 오버플로
shrink-to-fit(자연폭 662px vs 셀 내폭) 또는 트레일링 공백 축소 처리 —
한글은 같은 줄을 압축 없이 배치(㊞ origin 629.4px, 전 run 0.505em).

3. 구조 정리

• devel 은 (day) 글자군이 +20px 과대(구 HY 테이블)여서 말미 압축 −21px 과
  우연 상쇄 → ㊞ 이 정위치처럼 보였음.
• 본 PR 이 글자 폭을 정답으로 좁히자(+5.4px 잔차) 상쇄가 풀려 ㊞ −15px 노출.
• 따라서 본 PR 의 메트릭 교정 자체는 결백하며, 말미 공백 압축이 별도
  선결 결함입니다. golden 에 ㊞ −15px 를 굽지 말고, 말미 공백 압축 해소
  (또는 해당 golden 만 보류) 후 갱신을 권합니다.

재현: output/poc/task2430/space_min.hwpx(정상) vs samples/복학원서.hwpx
y≈1001 줄 — run 별 공백 실효폭 비교. 오라클 좌표는 위 코멘트 참조.

[planet6897]

㊞ 회귀 근본 원인 확정 + 검증된 수정 — receipt_date_stamp_shift_px 제거

코드 트레이싱 결과(렌더 트리 실측): 공백 run 폭은 132.0px(0.5em×18)로 정상이고
run 누적 x도 ㊞=652.6 으로 정상인데, 방출 직전 receipt_date_stamp_shift_px
(paragraph_layout.rs:380, #2020 도입, jangster77 3a42c9b)가 ㊞ 노드만
−21.2px 이동시킵니다:

hancom_gap = fs × ratio × 0.42 × space_count   // "한컴은 0.42em" 가정
shift = current_gap − hancom_gap = (0.50−0.42) × 14.67 × 18 = 21.1px  ✓ 실측 21.2

• 발동 조건이 이 문서 형상 전용(셀 + 빨간 ㊞ 단독 + 8+ 공백 선행 + 괄호 3쌍).
• 0.42em 가정은 허구: 한컴 실측 space = 0.505em 균일(무신축 래더). HWP/HWPX 문서 rendering 결과와 원본간의 차이 사례 공유 #2020
  당시 rhwp 글자 폭이 +20px 과대(구 HY 테이블)라 ㊞가 우측으로 밀렸고, 이를
  도장 위치에서만 상쇄하려 만든 보정입니다. 본 PR 이 글자 폭을 정답으로
  교정하면서 보정이 순수 오차로 전환된 구조.

검증 (본 PR 브랜치 f0dad6a + fn 무효화, 로컬)

㊞ origin (svg px)	값	vs 오라클 629.4
본 PR 현재 (핵 유지)	614.44	−15.0
본 PR + 핵 제거	635.56	+6.2 (상류 글자 잔차 +5.4 전파와 일치)

issue_2020 핀 4/4 PASS (seal_line_and_stamp_align 포함 — 핵 없이 통과).

권고 패치

receipt_date_stamp_shift_px fn(380~444)과 호출부(4540 부근 stamp_shift)를
제거하고 run_x = x 로 단순화 → bokhakwonseo·exam-kor golden 재생성(㊞
614.44→635.56). #2020 계보 주석에는 "구 메트릭 보상 핵, #2510 메트릭 교정으로
불필요" 기록을 권합니다.

[planet6897]

커밋 안내 — ㊞ 도장 핵 제거 푸시 (f03cf52)

위 근본 원인 코멘트(5017316669)의 검증된 패치를 브랜치에 푸시했습니다
(head f0dad6a 위, 30분 무반영 타임아웃 규칙에 따른 병행 세션 조율):

• receipt_date_stamp_shift_px(HWP/HWPX 문서 rendering 결과와 원본간의 차이 사례 공유 #2020) fn·호출부 제거 — "한컴 0.42em" 가정은
  실측(무신축 래더 space=0.505em 균일) 기각. 구 HY 테이블 글자 과대폭 보상용
  핵으로, 본 PR 의 메트릭 교정과 함께라면 순수 오차(㊞ −15px 시각 회귀).
• bokhakwonseo-page1 golden 재생성: ㊞ 614.44 → 635.56 (한글 PDF 오라클
  629.4 대비 +6.2 — 상류 글자 잔차 +5.4 전파와 일치).
• 검증: issue_2020 도장 정렬 핀 포함 12/12 PASS (issue_2020 + svg_snapshot),
  렌더 전용 변경(흐름/쪽수 불변), fmt 적용.

브랜치 방향과 충돌하는 부분이 있으면 되돌리셔도 됩니다 — 근거 수치는 위
코멘트 3건에 모두 보존되어 있습니다.

[planet6897]

10k 전수 회귀 회계 (r17: devel 564e9c8 + 본 PR + #2470)

r16 동일 표본 10k 재스윕(r17)에서 본 PR의 문서 단위 순효과를 전수 확정했다.

총량: PI 일치율 93.25→93.49%(+0.24%p), PAGE_DELTA +1축 255→226(−29), 픽셀 무회귀(5%p 하락 0건).

이동: 일치화 33 / 이탈화 9 (순 +24).

• 개선 30건(PAGE_DELTA→MATCH): 전부 r16의 +1/+2 보도자료 — 본 PR이 겨냥한 한양·휴먼 코호트가 한글 정합 복귀.
• 회귀 9건: 전량 본 PR 단일 귀속 (한양중고딕/한양신명조/휴먼명조 3폰트 보유, 동일 기전).
  • 87520 (32→30, PAGE_DELTA): Task #2279: 마스킹 생성기 잔존 2종 정합 — stale-lh 표 + 저장 줄수 과소 재래핑 (+#2454 자산 승계) #2470 미포함 pop-gate에서 이미 확인된 기지 트레이드. P15 셀 텍스트 un-wrap로 −2쪽.
  • PI_MISMATCH 8건: 총쪽수 불변·페이지 내 pi 경계 ±1 밀림(n_mismatch 1~4). r15→r16→r17 = mism→match→mism 왕복 knife-edge.

성격/처분: 좁아진 폭은 실측-정답(한글 glyph 일치)이므로 회귀 근인은 폭이 아니라 이것이 벗겨낸 보상 오차 = 공백런/자간 문맥 폭(#2509). 9건은 #2509 종속 회귀이며 revert 대상 아님. net 개선 명확(+1축 −29). 상세: output/poc/survey10k_r17_20260720/ANALYSIS.md.

[jangster77]

머지 보류 사유

최신 head의 CI는 모두 통과했고, 작성자 코멘트에서 지적한 복학원서 ㊞ 보정 제거도 반영되어 issue_2020 회귀 핀을 다시 통과한 점은 확인했습니다.

다만 이 PR의 핵심 전제인 “한양·휴먼 원명 유지 + 개별 ASCII 메트릭”이 Studio/Chrome 확장 기본 경로에는 아직 적용되지 않아, 현 상태로는 머지를 보류합니다.

P1: 브라우저 측정·표시가 다시 HY 대체 글꼴로 해소됨

Rust style_resolver는 한양 4종과 휴먼명조의 원명을 유지해 새 메트릭을 선택합니다.

그러나 Studio font-substitution.ts는 동일 face를 다시 HY신명조/HY중고딕 등의 웹 대체 글꼴로 해소합니다. wasm-bridge.ts는 이 체인을 Canvas font setter와 measureText에 설치하며, font-loader.ts의 HY 웹폰트는 Noto 대체 파일입니다.

로컬 호출로도 다섯 face가 모두 HY 체인으로 해소되는 것을 확인했습니다. 따라서 Rust의 새 폭 테이블과 Studio/확장의 실제 측정·표시 글꼴이 달라져 셀 재래핑, 캐럿, 선택 좌표에서 이번에 해결하려는 폭 불일치가 재발할 수 있습니다.

Studio/확장 측 치환 및 CanvasKit 준비 정책을 Rust의 원명 보존 정책과 일치시키고, 다섯 face의 CSS chain과 실제 뷰어 래핑을 검증하는 회귀 테스트를 추가해 주세요.

P2: 커밋된 실측 도구만으로 새 테이블을 재현할 수 없음

hy_ascii_ladder.py는 HY 7종만 측정해 단일 hy_ascii_measured.tsv를 출력합니다. 반면 gen_metrics.py는 한양·휴먼 5종의 개별 ladder_<face>.tsv를 요구합니다. 두 스크립트 모두 개인 Windows 경로를 고정합니다.

측정 대상/산출물 규약과 경로 인자를 정리해, 저장소에서 동일한 입력으로 테이블을 재생성할 수 있게 보완해 주세요.

P2: PR 본문과 최신 10k 회계 수치 불일치

PR 본문은 개선 34 / 회귀 2 / 순 +32를 적고 있으나, 최신 작성자 코멘트는 개선 33 / 회귀 9 / 순 +24를 보고합니다. 비교 기준이 달라진 경우 기준 revision과 최종 수치를 PR 본문에 분리해 명시해 주세요.

위 보완 후 #2430의 대표 재현과 Studio/확장 경로를 다시 확인하겠습니다.

[planet6897]

리뷰 감사합니다. 세 지적 대응 정리.

P2 (실측 도구 재현성) — 반영 완료 (21ef781)

• hy_ascii_ladder.py: --fonts/--out-dir argparse, per-face 개별 PDF·ladder_<face>.tsv 출력(통합 PDF 의 subset 폰트명 T1/Haansoft 병합 회피 = gen_metrics 규약 충족). 리포 루트 기준 상대경로, 개인 Windows 경로 제거.
• gen_metrics.py: --ladder-dir/--src argparse, face 헤더 허용, os.path.join.
• 재생성 파이프라인: hy_ascii_ladder.py --fonts "한양신명조,..." --out-dir output/poc/task2430 → gen_metrics.py --ladder-dir output/poc/task2430.

P2 (수치 기준 불일치) — 본문 명확화 완료

PR 본문에 기준 분리 명시: 표의 개선34/회귀2(+32) 는 #2510 단독(기준 r16=af5902b6) 페이지수 델타 게이트, 코멘트의 일치화33/이탈화9(+24) 는 #2510+#2470 통합(r16→r17) verdict 이동 집계 — exe·기준 revision·집계축이 달라 수치 상이, 둘 다 순개선(회귀 문서군 동일).

P1 (Studio/확장 측정·표시 정합) — 아키텍처 정리 + 분리 제안

지적이 정확합니다. 다만 두 경로가 구조적으로 다른 측정기를 씁니다:

• CLI/SVG/PDF export: EmbeddedTextMeasurer → 본 PR 이 교정한 Rust 임베드 테이블. 10k 한글 오라클(r17 PI 93.49%)이 검증하는 경로가 이것이며, 본 PR 의 폭 교정은 여기서 완결.
• Studio/확장: WasmTextMeasurer → wasm-bridge.ts:64 measureTextWidth → 브라우저 Canvas measureText(치환 웹폰트). 임베드 테이블을 타지 않음.

fontFamilyChainForDisplay 는 로컬 실측 폰트를 1순위로 두므로, 사용자가 실제 한양/휴먼 폰트를 보유하면 Studio 측정=표시가 한컴과 정합(=본 PR 임베드 테이블과 동일 출처). 폰트 부재 시에만 Studio 는 HY 웹대체(Noto)로, CLI 는 임베드 한양 테이블로 갈려 — 이 임베드-vs-Canvas 발산은 본 PR 5종이 아니라 전 폰트에 공통인 기존 아키텍처 조건(HY 계열도 종전부터 동일)입니다. 본 PR 은 CLI 경로 5종을 더 정확히 만들 뿐, Studio 경로를 악화시키지 않습니다(로컬 보유 시 개선, 부재 시 종전과 동일한 HY 대체).

제안: 본 PR(임베드 테이블, 오라클 검증 완료)은 export 경로 정합으로 머지하고, Studio/확장의 font-substitution 원명 보존 + CanvasKit 준비 정책 + 5종 CSS chain·뷰어 래핑 회귀 테스트는 브라우저/CanvasKit 검증이 필요한 별도 트랙으로 분리(신규 이슈)하는 것이 안전합니다 — 이 환경(CLI)에서 뷰어 래핑을 검증 못 한 채 Studio 측정 파이프라인(다수 문서 영향)을 바꾸는 것은 미검증 회귀 위험이 큽니다. 분리에 동의하시면 Studio 트랙 이슈를 열어 CSS chain 단위테스트부터 착수하겠습니다. 본 PR 에 Studio 변경 포함을 원하시면 검증 범위(어떤 Studio 테스트로 뷰어 래핑을 게이트할지) 지정 부탁드립니다.

[postmelee]

@planet6897 상세한 답변과 추가 보정 감사합니다. 마지막 확인 시점의 head 5fdcaa6e 기준으로 재검토했습니다.

해결된 점

기존 리뷰의 다음 두 P2 항목은 해결된 것으로 판단합니다.

1. 실측 도구의 실행 규약

   21ef7819에서 다음 사항이 반영된 것을 확인했습니다.

   • hy_ascii_ladder.py의 --fonts, --out-dir
   • face별 PDF 및 ladder_<face>.tsv 생성
   • 개인 Windows 절대경로 제거
   • gen_metrics.py의 --ladder-dir, --src
   • ladder → metrics 생성 규약 정렬

2. 10k 회계 수치 설명

   PR 본문에 다음 두 집계의 기준이 분리되어 설명됐습니다.

   • fix(#2430): 한양·휴먼 계열 ASCII 메트릭 실측 교정 — 셀 재래핑 오발동 해소, 10k 순 +32 #2510 단독 페이지 수 게이트: 개선 34 / 회귀 2 / 순 +32
   • fix(#2430): 한양·휴먼 계열 ASCII 메트릭 실측 교정 — 셀 재래핑 오발동 해소, 10k 순 +32 #2510+Task #2279: 마스킹 생성기 잔존 2종 정합 — stale-lh 표 + 저장 줄수 과소 재래핑 (+#2454 자산 승계) #2470 통합 verdict 이동: 일치화 33 / 이탈화 9 / 순 +24

   기준 revision, 실행 파일, 집계축이 다르다는 설명은 합리적이므로 수치 차이 자체는 더 이상 blocker로 보지 않습니다.

또한 로컬에서 Rust focused tests, SVG snapshot, frontend font-substitution 단위 테스트와 WASM build가 통과한 점도 확인했습니다.

Studio 트랙 분리 제안에 대한 답변

Studio/확장의 전체 font-substitution 및 CanvasKit 글꼴 준비 정책을 이 PR에서 전면 수정하면 영향 범위가 커질 수 있다는 우려에는 동의합니다. 따라서 범용 글꼴 로딩 정책 개편은 별도 이슈로 분리할 수 있습니다.

다만 이번 PR을 “export 경로에만 영향을 주는 변경”으로 보고 Studio 검증 전체를 후속으로 미루는 제안에는 동의하기 어렵습니다. 현재 WasmTextMeasurer도 등록된 글꼴에 대해서는 Canvas measureText보다 임베디드 메트릭을 우선하므로, 이번에 추가한 한양·휴먼 5종 테이블은 Studio/WASM의 줄바꿈과 편집 좌표에도 즉시 영향을 줍니다. 실제로 native 테스트의 경계는 44→56으로 변경됐지만 기존 Studio focused E2E는 44 기대값에 남아 있어 현재 head에서 실패합니다.

따라서 범위를 다음처럼 나누는 것을 제안합니다.

• 현재 PR에서 처리할 최소 범위

  • issue-2214-page-local-repaint Studio E2E를 새 메트릭 계약에 맞게 갱신
  • HWP/HWPX 양쪽 focused E2E 통과
  • 원본 글꼴 부재 환경에서 5종 메트릭 적용 시 줄바꿈·캐럿·선택 좌표가 native와 일관됨을 확인하는 최소 회귀 테스트
  • HFT 메트릭으로 layout을 계산하면서 HY 대체 글리프로 표시하는 현재 hybrid 동작이 의도된 것인지 PR 본문에 명시

• 별도 Studio 이슈로 분리 가능한 범위

  • font-substitution 전체의 원명 보존 정책 변경
  • CanvasKit/웹폰트 준비 및 실제 로컬 글꼴 감지 구조 개편
  • 5종을 넘어선 전체 글꼴의 CSS chain 정합
  • 실제 표시 glyph까지 원본 HFT와 일치시키는 장기 정책

즉 광범위한 Studio 글꼴 정책 개편까지 이 PR에 요구하지는 않겠습니다. 하지만 이번 PR이 이미 변경하는 WASM layout 계약과 현재 재현되는 E2E 실패는 후속 이슈로 넘길 수 없습니다. 위 최소 범위를 현재 PR에서 처리한 뒤, 나머지를 별도 이슈로 분리하는 방향이라면 동의합니다.

추가 수정 필요사항

1. Studio focused E2E의 기존 44/50 경계를 갱신해 주세요

Rust 회귀 테스트는 새 메트릭에 맞춰 경계를 44→56/62로 변경했지만, 다음 파일에는 기존 계약이 남아 있습니다.

rhwp-studio/e2e/issue-2214-page-local-repaint.test.mjs

• inserted < 44 ? 4 : 5
• inserted !== 44
• 50회 입력
• inserted === 44 flow change
• 43/44 visual checkpoint
• transitionAt: 44

macOS Chrome에서 다음 명령을 실행하면 HWP 입력 44에서 재현 가능하게 실패합니다.

npm run e2e:issue-2214 -- --runs=1

AssertionError: hwp run 1 input 44: line count
actual: 4
expected: 5

단순히 숫자를 일괄 치환하기보다, HWP/HWPX 각각에서 실제 transition을 관측한 뒤 다음 항목을 함께 갱신해 주세요.

• 입력 반복 범위와 최종 기대 상태
• line-count 및 pending 기대값
• flow-change trace
• boundary 전후 checkpoint
• screenshot 이름
• 최종 transitionAt

2. Studio/WASM 측정 경로에 관한 설명을 코드와 일치시켜 주세요

마지막 답변에서는 Studio가 Canvas measureText를 사용하므로 임베디드 테이블을 타지 않는다고 설명했지만, 현재 WasmTextMeasurer는 등록된 글꼴에 대해 임베디드 메트릭을 먼저 반환합니다.

if let Some(w) =
    measure_char_width_embedded(font_family, bold, italic, c, font_size)
{
    return w;
}

따라서 이번에 등록된 한양·휴먼 5종 메트릭은 native뿐 아니라 Studio/WASM 레이아웃에도 적용됩니다. Canvas 측정은 임베디드 메트릭을 찾지 못한 경우의 후순위 경로입니다.

반면 원본 글꼴이 확인되지 않은 Studio 환경에서는 fontFamilyChainForDisplay가 원명을 제외하고 HY 대체 글꼴을 선택할 수 있으며, svg.rs도 한양 원명을 HYSNMJ.TTF, HYGTRE.TTF, HYMJRE.TTF 등의 HY 파일로 연결합니다.

즉 PR 이전의 “HY 메트릭 + HY 표시”에서 PR 이후 “HFT 실측 메트릭 + HY 표시”로 바뀔 수 있으므로, 폰트 부재 시 동작이 종전과 동일하다는 설명은 수정이 필요합니다.

다음 중 어느 정책을 채택할지 명확히 해 주세요.

• 측정 메트릭과 표시 글꼴을 동일 계열로 맞춘다.
• HFT 메트릭으로 한컴식 layout을 계산하고 HY 글리프로 표시하는 hybrid를 의도된 정책으로 유지한다.

후자를 선택한다면 최소한 원본 글꼴 부재 환경에서 줄바꿈, 캐럿, 선택 영역이 native와 일치함을 보장하는 회귀 테스트가 필요합니다.

3. 실측 harness가 미설치 HFT fallback을 검출하도록 보완해 주세요

현재 hy_ascii_ladder.py는 요청 face에 FontType=2를 설정하지만, 해당 HFT가 실제 설치됐는지 또는 한글이 다른 글꼴로 fallback했는지 확인하지 않습니다. TSV의 face 열도 실제 사용 글꼴이 아니라 요청 문자열을 기록합니다.

리뷰어의 Windows 10 + 한글 2024 환경에서는 대상 다섯 글꼴 중 휴먼명조만 확인됐고 나머지 네 한양 원본 HFT는 조회되지 않았습니다. 이 상태에서 전체 ladder를 실행하면 잘못된 fallback 결과를 요청 face의 결과로 기록할 가능성이 있어, 리뷰어 측 실행은 승인 근거로 사용하지 않겠습니다. 보이는 HY... TTF도 원본 HFT의 대체 오라클로 사용할 수 없습니다.

다음 보완을 요청합니다.

• 대상 HFT가 없거나 실제 face를 확인할 수 없으면 non-zero로 중단하는 preflight
• 존재하지 않는 HFT 이름을 지정했을 때 정상 TSV가 생성되지 않는 negative-control
• 생성된 다섯 배열이 원본 TSV와 정확히 일치하는 자동 비교 또는 검증 명령

검증 자료 요청

리뷰어가 동일한 Windows 환경을 직접 확보하는 것을 merge 조건으로 삼지는 않겠습니다. 대신 실측을 수행한 환경에서 다음 증거를 남겨 주세요. 저작권 글꼴 파일 자체는 첨부하지 않아도 됩니다.

• Windows 버전
• 한컴오피스/한글의 정확한 제품 버전과 빌드
• 다섯 대상 face가 HFT로 실제 선택 가능함을 보여주는 화면 또는 로그
• 다섯 ladder_<face>.tsv 원자료
• gen_metrics.py 출력과 커밋된 배열의 exact diff 또는 checksum
• 동일 환경 2회 실행 결과가 결정적이라는 비교 결과
• missing-face negative-control 결과
• 수정된 npm run e2e:issue-2214 -- --runs=1의 HWP/HWPX 통과 로그
• 원본 글꼴 부재 환경에서 native/WASM의 줄바꿈·캐럿·선택 좌표 정합 테스트 결과

#2430의 대표 문서 21868765와 한컴 기준 PDF가 재배포 가능한 자료라면 함께 첨부해 주세요. 재배포가 어렵다면 SHA-256과 출처를 기록하고, 저장소에서 장기 재현 가능한 대체 fixture와 한컴 기준 PDF를 추가해 주세요.

현재 판단

이번 PR이 대표 회귀를 7→4쪽으로 복구하고 10k 모집단에서 순개선을 만든 점은 긍정적으로 평가합니다. 또한 #2430의 나머지 10건을 별도 원인으로 계속 추적하면서 이 PR을 부분 근본 수정으로 수용하는 방향에도 동의할 수 있습니다.

다만 현재는 Studio focused E2E가 실제로 실패하고 있고, WASM 측정 경로에 대한 마지막 설명이 구현과 다르며, 실측 데이터의 실제 HFT identity를 검증할 방법이 부족합니다. 위 수정과 검증 자료가 반영될 때까지 merge는 보류하겠습니다. 이후 최신 head에서 다시 검토하겠습니다.

[planet6897]

리뷰 2차 대응 — E2E 56/62 갱신 + WASM 정책 정정·회귀 테스트 + 실측 identity 증거

세 수정 요청과 검증 자료 요청에 대한 대응을 푸시했습니다.

1. Studio focused E2E 44/50 → 56/62 갱신

e2e/issue-2214-page-local-repaint.test.mjs 의 구 계약을 전면 갱신했습니다 — 입력 반복 62회, line-count <56 ? 4 : 5, pending !==56, flow-change trace(62개 insert, 경계 56 단일), 경계 전후 checkpoint(55/56)·스크린샷명(after-55.png, after-56-*.png, diff-55-vs-56.png), raw boundary(55+1), transitionAt: 56.

전환점은 숫자 치환이 아니라 native 관측과 동기했습니다: tests/issue_2214_page_local_repaint.rs 의 issue_2214_cell_flow_transition_baseline 이 HWP/HWPX 각각 0..62 전 구간을 삽입하며 경계 56 단일 관측(55번째 delta=1920, changed_inputs=[56])을 고정하고 있고, 이 테스트가 본 브랜치에서 GREEN 임을 확인했습니다. 브라우저 실행(npm run e2e:issue-2214 -- --runs=1)은 이 환경(Windows, 브라우저 하니스 부재)에서 수행하지 못했으므로 macOS 재검토 시 확인 부탁드립니다 — 실패 시 native 대비 diverge 지점이 곧 버그 신호입니다.

2. WASM 측정 경로 설명 정정 + hybrid 정책 명시

지적대로 이전 설명이 구현과 달랐습니다. WasmTextMeasurer 는 임베디드 메트릭을 Canvas 보다 우선하므로 본 PR 5종 테이블은 Studio/WASM 레이아웃에도 즉시 적용됩니다. PR 본문에 정정·정책을 명시했습니다:

• 채택: hybrid — 레이아웃 문자폭 = HFT 실측 임베디드 메트릭(한컴·native 정합), 표시 = 로컬 폰트 우선/부재 시 HY 웹대체. 표시 글리프까지 원본 HFT 일치는 글꼴 배포 문제로 별도 트랙.
• 회귀 테스트: issue_2430_hft_faces_ascii_embedded_coverage — 5종 face × ASCII 0x20..=0x7E 전 구간이 임베디드로 해소됨을 고정. 성립하는 한 원본 글꼴 부재 환경에서 Canvas 폴백이 레이아웃에 개입할 수 없어 줄바꿈·캐럿·선택 좌표의 WASM==native 가 구조적으로 보장됩니다(실측 스팟 체크 포함, cargo test 로 어느 OS 에서든 실행 가능).

3. 실측 harness — preflight / negative-control / verify

hy_ascii_ladder.py 에 HFT identity 검증을 추가했습니다:

• preflight: CharShape 왕복 — 실존 HFT 는 FontType=2 가 유지되고, 미설치 face 는 fallback 으로 변질(실측: FontType=6)됩니다. 하나라도 미확인이면 TSV 미생성 + exit 2. 결과는 preflight_report.tsv 로 기록.
• negative-control: --fonts "존재하지않는폰트XYZ" → preflight abort(exit 2), ladder TSV 미생성. PDF 단까지 간 경우도 임베드 폰트의 Haansoft *(시스템 대체) 혼입을 검출해 exit 3.
• verify: gen_metrics.py --ladder-dir tools/task2430/measured --verify — TSV→배열 재생성을 커밋 static 과 정확 비교. 5종 모두 95/95 exact match (exit 0). COM 불필요라 macOS/Linux 에서도 재검증 가능합니다.

4. 검증 자료 (tools/task2430/EVIDENCE.md)

• 환경: Windows 11 (10.0.26200), 한컴오피스 한글 2022 — COM hwp.Version = 12.0.0.4547, pyhwpx 1.7.2 / PyMuPDF 1.27.2.
• 다섯 face HFT 실선택 로그(preflight readback 전건 FontType=2) + PDF 임베드 폰트 이중 확인(한양 4종 Type3, 휴먼명조 INPILL+휴먼명조).
• 결정성: COM 생성부터 2회 독립 실행, 5종 TSV byte-identical.
• 원자료 tools/task2430/measured/ladder_<face>.tsv 5종 커밋 + sha256.
• missing-face negative-control 실행 로그.
• 대표 문서 fixture: samples/21868765_별표2_보건소_분장사무.hwp(자치법규 공표 별표) + 한컴 기준 PDF(Producer=Hancom PDF 1.3.0.550, 4쪽), sha256 기록.

부수 발견: 직선 따옴표(0x22/0x27)는 한/글 자동 치환 탓에 삽입 경로별로 측정 여부가 갈려(원 실측=93자+2보간) EXCLUDE_AUTOCORRECT 로 명시 제외했습니다. 일괄 삽입으로 얻은 실측치는 보간과 차이가 있어(예: ' 신명조 241→395) 10k 게이트가 필요한 별도 교정 후보로 EVIDENCE 에 기록만 했습니다 — 본 PR 범위 밖.

수정 후 게이트: issue_2430_hft_faces_ascii_embedded_coverage GREEN, issue_2214_page_local_repaint(native 56/62 계약) GREEN, fmt/clippy 통과.

[planet6897]

리눅스 로컬 검증 완료

리눅스(x86_64) 환경에서 이 PR head(local/task2430-hy-metrics)를 기준으로 wasm 재빌드 후 e2e·native·golden 전 계열을 검증했습니다. 회귀 없이 전부 통과했습니다.

e2e (rhwp-studio, headless Chrome)

PR 소스로 wasm-pack build --target web --out-dir pkg 재빌드 후 vite dev 서버(127.0.0.1:7700)에 대해 실행.

e2e	결과
issue-2214-page-local-repaint (본 PR이 갱신)	GREEN — HWP/HWPX 각 3런 + IME/iOS smoke 전부 통과
canvaskit-font-coverage	PASS
canvas-render-diff	PASS (KTX 0.011%, biz_plan/tac 0.000%)

핵심 계약 — 셀 줄채움 임계 44→56, 관측 범위 50→62 이동이 리눅스 wasm 레이아웃에서 그대로 재현됨(lineCount = inserted < 56 ? 4 : 5, boundary=56, insert/effect/operation=62, flush=1).

native / golden

게이트	결과
cargo test --profile release-test --tests (전체 통합)	289개 테스트 바이너리 전부 ok, 실패 0
svg_snapshot (golden SVG — 갱신된 issue-617/issue-677 포함)	8/8 pass
issue_2214_page_local_repaint	3/3 pass
issue_2020 (㊞ 정렬, 상한 28)	4/4 pass
issue_2215_selection_page_range (선택 rect 폭 실측)	4/4 pass
cargo fmt --check (변경 rust 파일)	clean
cargo clippy --all-targets -- -D warnings	경고/에러 0

종합

폰트 폭 축소(HY/한양·휴먼 메트릭 교정)에 맞춰 갱신된 테스트 핀(e2e 경계 56, 선택 rect 폭 111.7→105.0 / 10.0→7.9, golden SVG 2건)이 리눅스 런타임 실측과 정확히 일치합니다. 광범위한 메트릭 변경에도 갱신되지 않은 나머지 golden·스냅샷·통합 테스트가 회귀 없이 전부 통과해 다른 문서 계약을 깨지 않음을 확인했습니다.

[planet6897]

macOS E2E 검증 완료 — 리뷰 2차 대응 게이트 확인

이전 대응 코멘트에서 브라우저 하니스 부재로 미수행이라 macOS 재검토를 요청드렸던 Studio focused E2E를 macOS에서 실행해 통과를 확인했습니다.

환경

• macOS 15.7.7 (Darwin 24.6.0), Node v22.19.0, Google Chrome 150.0.7871.129 (headless)
• 대상 head: 497cbf6b
• WASM: 해당 head 소스에서 wasm-pack build --target web --out-dir pkg 재빌드 후 검증(임베디드 메트릭 반영 보장)

1. Studio focused E2E (npm run e2e:issue-2214 -- --runs=1) — exit 0, 전건 GREEN

[HWP]  focused GREEN (1 runs)
  run 1: GREEN, flush=1, boundary=2862.90ms, flushTime=2724.50ms, stableP95=142.90ms
  ime raw stable smoke: GREEN, flush=0
  ios raw stable smoke: GREEN, flush=0
  ime raw smoke: GREEN, flush=1
  ios raw smoke: GREEN, flush=1
[HWPX] focused GREEN (1 runs)
  run 1: GREEN, flush=1, boundary=2372.00ms, flushTime=2258.80ms, stableP95=117.50ms
  ime raw stable smoke: GREEN, flush=0
  ios raw stable smoke: GREEN, flush=0
  ime raw smoke: GREEN, flush=1
  ios raw smoke: GREEN, flush=1

• HWP/HWPX 양쪽 모두 갱신된 56/62 계약(line-count <56 ? 4 : 5, 경계 56 단일 flow-change, pending !==56, 입력 62회, transitionAt: 56)으로 통과.
• boundary flush 1회, 이후 입력(57~62)은 추가 flush 없음 — native 계약과 일치.
• 별도 3-run(기본) 실행도 exit 0으로 통과 확인.

2. native 게이트 (cargo test --release)

test renderer::layout::text_measurement::tests::issue_2430_hft_faces_ascii_embedded_coverage ... ok
test issue_2214_cell_flow_transition_baseline ... ok

• issue_2430_hft_faces_ascii_embedded_coverage: 5종 face × ASCII 0x20..=0x7E 전 구간이 임베디드 메트릭으로 해소됨을 고정 → 원본 글꼴 부재 환경에서도 Canvas 폴백이 레이아웃에 개입 불가(WASM 레이아웃 == native).
• issue_2214_cell_flow_transition_baseline: HWP/HWPX 각 0..62 전 구간에서 경계 56 단일 관측 고정 — 위 E2E 전환점과 동기.

3. 실측 harness verify (크로스플랫폼, COM 불필요)

$ python3 tools/task2430/gen_metrics.py --ladder-dir tools/task2430/measured --verify
한양신명조 → HanyangSinMyeongJo: 95/95 exact match — OK
한양중고딕 → HanyangJungGothic:  95/95 exact match — OK
한양견명조 → HanyangKyunMyeongJo: 95/95 exact match — OK
한양견고딕 → HanyangKyunGothic:  95/95 exact match — OK
휴먼명조   → HumanMyeongJo:       95/95 exact match — OK  (exit 0)

커밋된 TSV → 배열 재생성이 static 배열과 exact match. macOS에서도 재현됨.

참고

첫 --runs=1 시도에서 마지막 smoke 직전 TargetCloseError가 관측됐으나, 이는 병행 중이던 cargo 컴파일과의 CPU 경합 + 실행 타임아웃(SIGTERM)이 브라우저 타깃을 중간 종료시킨 실행 환경 아티팩트였습니다. 경합 없이 재실행 시 위와 같이 exit 0으로 통과했으며 계약 실패는 없었습니다.

[jangster77]

merge 완료했습니다. merge commit은 215a174이며, 검토 기록과 시각 증적은 후속 기록 PR #2672를 통해 devel에 보존했습니다.

임베디드 HFT 메트릭이 Studio/WASM 레이아웃에도 적용되고, HWP/HWPX 55→56 경계 E2E가 모두 GREEN임을 재확인했습니다. 대표 전후 프레임은 검토 기록에서 재현 절차와 함께 확인할 수 있습니다.

비차단 후속 보완도 남깁니다.

1. tools/task2430/EVIDENCE.md의 ladder TSV SHA-256은 현재 LF checkout 바이트가 아닌 CRLF 변환 바이트와 일치합니다. canonical 줄바꿈 규칙을 적거나 LF 기준 checksum으로 정정해 주세요.
2. measured/preflight_report.tsv에는 현재 휴먼명조 한 행만 있으므로, EVIDENCE가 말하는 다섯 face preflight 증적은 aggregate report 또는 face별 report로 보완해 주세요.

이는 이번 런타임 수정의 정합을 뒤집는 사항은 아니므로 merge를 막지 않았습니다. 다만 장기 재현성 자료이므로 이슈 #2430에서 후속 추적합니다. 이 이슈는 나머지 10건이 별도 폰트·재래핑 경로 축으로 남아 있으므로 이번 PR merge로 close하지 않습니다.

[postmelee]

merge 후 재검토 기록 + preflight identity 후속

@jangster77 님 merge 확인했습니다 (215a174). 2차 대응을 head 978620a3 기준으로 재검토했고 아래를 직접 재현했습니다.

• gen_metrics.py --ladder-dir tools/task2430/measured --verify → 5종 95/95 exact match, exit 0 (macOS, COM 불필요)
• native: issue_2430_hft_faces_ascii_embedded_coverage GREEN, issue_2214_page_local_repaint 3/3 GREEN (changed_inputs == vec![56], 0..62 관측)
• Studio E2E (macOS Chrome): npm run e2e:issue-2214 -- --runs=1 → exit 0, HWP/HWPX focused GREEN(flush=1) + IME/iOS smoke GREEN, transitionAt=56

리눅스 GREEN 보고에 더해 macOS Chrome 에서도 재현 확인했습니다. 요청 #1(E2E 56/62)·#2(WASM 경로 정정·hybrid 명시·커버리지 테스트)는 해결로 판단합니다.

후속 — EVIDENCE 증적 표현 정정

메인테이너 검토 기록 pr_2510_review.md 가 명시한 비차단 후속 보완 2건을 다음과 같이 처리했습니다.

• COM 불필요 부분은 #2675 로 정정: (항목 1) EVIDENCE ladder TSV SHA-256 을 LF 체크아웃(Git 저장 바이트) 기준으로 재기록, (항목 2) hy_ascii_ladder.py preflight 를 requested_face 누적 병합으로 바꿔 per-face 실행에서도 5종 identity 행 보존 + EVIDENCE.md §2 라벨을 실제 파일 내용에 맞게 정정.
• 한양 4종의 5행 preflight_report.tsv 실측 재보존은 Windows+한컴 COM 재실행이 필요해 #2677 로 분리(@planet6897 assign). chore(#2510 후속): EVIDENCE 증적 표현 정정 (SHA-256 LF + preflight identity 누적) #2675 의 harness 개선이 재실행 시 5행 보존을 보장합니다.

대표 회귀 복구 + 10k 순개선 + native/WASM 계약 정합은 이미 확인됐습니다.