Skip to content

fix(renderer): HY 계열 한글 폰트명 → 메트릭 DB alias 7종 추가 (#259)#264

Closed
planet6897 wants to merge 5 commits into
edwardkim:develfrom
planet6897:local/task259
Closed

fix(renderer): HY 계열 한글 폰트명 → 메트릭 DB alias 7종 추가 (#259)#264
planet6897 wants to merge 5 commits into
edwardkim:develfrom
planet6897:local/task259

Conversation

@planet6897

Copy link
Copy Markdown
Contributor

Summary

  • samples/text-align.hwp s0:pi=4 문단(HY중고딕)에서 글자가 겹쳐 보이는 현상을 수정.
  • 근본 원인: 폰트명 2단 정규화 경로 중 2단계(한국어 정규명 → 메트릭 DB 영문명) 에서 HY 계열 매핑이 누락 → find_metricNone 반환 → 기본 폴백 폭
    적용.
  • src/renderer/font_metrics_data.rs::resolve_metric_alias 에 HY 계열 7종 alias 를 추가하고 단위 테스트로 회귀 방지.

변경 내역

소스

  • src/renderer/font_metrics_data.rs
    • resolve_metric_alias 에 HY 7 arm 추가 (아래 표)
    • #[cfg(test)] mod tests 모듈 신설 — HY 7종 각각에 대해 resolve_metric_alias · find_metric 반환값 검증

추가된 매핑 (7종)

정규명 (style_resolver 출력) DB 영문명 근거
HY중고딕 HYGothic-Medium 한컴 PS name 관례
HY견고딕 HYGothic-Extra Extra = 견
HY견명조 HYMyeongJo-Extra Extra = 견
HY신명조 HYSinMyeongJo-Medium Fontke/Wfonts/Fontsgeek 공개 폰트 메타 (신문명조와 구분)
HY그래픽 HYGraphic-Medium Fontke/Koreafont 공개 폰트 메타 (한양정보통신 제작)
HY헤드라인M HYHeadLine-Medium 직역
HY궁서 / HY궁서B HYGungSo-Bold 한컴 궁서는 Bold 단일 weight (방어적 추가)

검증

항목 결과
cargo test --lib (948개) ✅ all passed
cargo test --test svg_snapshot (3개) ✅ all passed (golden 갱신 불필요)
신규 단위 테스트 hy_normalized_names_resolve_to_db_entries ✅ HY 7종 전수 통과
cargo clippy --lib --tests ✅ 신규 경고 없음
before/after SVG diff (text-align.hwp p0) 322 라인 차이 — 글자별 x 좌표 전수 갱신 (예: , 폭 7.67→5.58, 0 폭 9.04, =9.31 등 실측 반영)
HY 5종 스모크 (대표 샘플 5개) ✅ panic·렌더 결손 없음

배경: 2단 정규화 경로

HWP 폰트명을 메트릭 DB 로 해석하는 경로:

  1. 한국어 별칭 → 한국어 정규명 (src/renderer/style_resolver.rs)
    예: 한양중고딕 / 신명 중고딕 / 신명 태고딕HY중고딕
  2. 한국어 정규명 → 메트릭 DB 영문명 (src/renderer/font_metrics_data.rs::resolve_metric_alias)
    예: HY중고딕HYGothic-Medium

본 PR 이전, 2단계에 HY 매핑이 전무하여 그대로 "HY중고딕"FONT_METRICS 조회에 들어갔고 — 배열은 영문명으로 저장되어 있어 매치 실패 → None → 호출부가
기본 폴백 폭 적용 → 글자 겹침.

범위 외 (후속 이슈 후보)

  • HY그래픽 / HY궁서 실제 렌더 회귀: samples/ 에 해당 폰트 사용 파일이 없어 alias 정합성만 단위 테스트로 검증. 실제 렌더 확인은 샘플 확보 후 별도
    이슈에서.
  • 웹 에디터 최종 시각 확인: rhwp-studio(WASM) 재빌드가 필요하므로 본 PR 에서는 네이티브 SVG 수치 검증으로 갈음. WASM 배포 사이클에서 자연 반영.
  • DB 약칭 엔트리(HYbdaL 등): style_resolver 가 이 이름으로 정규화하지 않는 한 본 PR 에서 건드리지 않음.

재발 방지

메모리에 체크리스트 등록 — 폰트 메트릭 DB 엔트리 추가/수정 시 resolve_metric_alias 도 반드시 동시 갱신. 정규명과 DB 영문명이 다르다는 구조적 특성
때문에 한쪽만 수정하면 같은 부류의 버그가 재발.

Test plan

  • cargo test --lib renderer::font_metrics_data::tests 통과 확인
  • cargo test --lib 전체 그린 확인
  • cargo test --test svg_snapshot 그린 확인
  • cargo clippy --lib --tests 그린 확인
  • rhwp export-svg samples/text-align.hwp -p 0 결과의 p0:pi=4 문단 글자 폭 수동 확인 (before 대비 ,·0·한글 폭 변화)
  • HY 5종 샘플 스모크 렌더 재확인 (20250130-hongbo, 2010-01-06, hwpspec, footnote-01, biz_plan)
  • (선택) WASM 재빌드 후 rhwp-studio 에서 text-align.hwp 시각 확인

관련

style_resolver 가 출력하는 HY 정규명 6종(중고딕·견고딕·견명조·신명조·
그래픽·헤드라인M)과 HWP 직접 저장 케이스 대비 HY궁서 1종, 총 7종의
DB 영문명 매핑을 한컴 폰트 PS name 관례 + 공개 폰트 메타데이터
(Fontke/Wfonts/Koreafont) 교차 확인으로 확정.

- mydocs/tech/task_259_hy_mapping.md (근거 + 최종 매핑표)
- mydocs/working/task_m100_259_stage1.md (단계 완료 보고)
- mydocs/plans/task_m100_259{,_impl}.md (수행·구현 계획서)
- mydocs/orders/20260423.md (edwardkim#259 진행 항목 추가)
HY 한글 정규명 7종을 메트릭 DB 영문 엔트리로 매핑:
- HY중고딕     → HYGothic-Medium
- HY견고딕     → HYGothic-Extra
- HY견명조     → HYMyeongJo-Extra
- HY신명조     → HYSinMyeongJo-Medium
- HY그래픽     → HYGraphic-Medium
- HY헤드라인M  → HYHeadLine-Medium
- HY궁서/HY궁서B → HYGungSo-Bold

종전에는 style_resolver 가 정규화한 한글 이름이 DB 영문 엔트리와
미스매치되어 find_metric 이 None 반환 → 기본 폭으로 글자 겹침 발생
(samples/text-align.hwp s0:pi=4 등). 본 커밋으로 2단계 정규화 경로 복구.

단위 테스트(hy_normalized_names_resolve_to_db_entries) 추가:
7종 각각에 대해 resolve_metric_alias · find_metric 반환값 검증.

검증:
- cargo test --lib: 948 passed · 0 failed
- cargo test --test svg_snapshot: 3 passed
- cargo clippy --lib --tests: 신규 경고 없음
HEAD~1(before) vs HEAD(after) 로 각각 release 빌드하여 SVG 렌더 비교:
- 글자별 x 좌표 전수 갱신 (322 라인 diff)
- 라틴 고정 폴백폭 7.67px → HYGothic-Medium 실측 가변폭
  (쉼표=5.58, 숫자=9.04 등)
- 한글 폭도 실측 반영으로 후속 글자 간격 정상화

회귀 검증:
- cargo test --lib: 948 passed
- cargo test --test svg_snapshot: 3 passed (golden 갱신 불필요,
  기존 샘플은 HY 미사용)

웹 에디터 최종 시각 확인은 WASM 재빌드 이후 브라우저로 수행 (본
타스크 범위 외, rhwp-studio 배포 사이클에서 자연 반영).
samples/ 143개 스캔으로 HY 폰트 사용 33개 식별. 각 HY 폰트별 대표
샘플에 대해 export-svg -p 0 스모크 실행:

- HY중고딕    20250130-hongbo.hwp     531 text elems  ✅
- HY신명조    2010-01-06.hwp          583 text elems  ✅
- HY견고딕    hwpspec.hwp              92 text elems  ✅
- HY견명조    footnote-01.hwp         390 text elems  ✅
- HY헤드라인M biz_plan.hwp             45 text elems  ✅

panic·렌더 결손 없음.

HY그래픽 / HY궁서 는 samples/ 에 해당 폰트 사용 파일이 없어 렌더
회귀는 후속 이슈로 이관. alias 매핑 및 DB 조회 정합성은 Stage 2
단위 테스트로 검증 완료.
5단계 전체 수행 결과 요약:
- HY 한글 정규명 7종(중고딕/견고딕/견명조/신명조/그래픽/헤드라인M
  /궁서) → DB 영문명 매핑 복구
- text-align.hwp s0:pi=4 글자 겹침 해소 (before/after SVG diff 검증)
- HY 5종 스모크 (대표 샘플별 정상 렌더)
- 재발 방지 메모리 등록: 폰트 메트릭 DB 갱신 시 resolve_metric_alias
  도 함께 갱신해야 함

범위 외 (후속 이슈 후보):
- HY그래픽 / HY궁서 실제 렌더 회귀 — 샘플 부재로 단위 테스트만
- rhwp-studio 웹 에디터 시각 확인 — WASM 재빌드 후 자연 반영

이슈 종료는 작업지시자 승인 후 수행 (edwardkim#259)
@planet6897 planet6897 closed this Apr 23, 2026
@edwardkim

Copy link
Copy Markdown
Owner

@planet6897 님, PR #264 를 뒤늦게 확인했습니다. 무언의 close 로 마무리되어 죄송합니다.

정황 재구성

제가 이 PR 의 존재를 놓친 경위:

제 쪽의 절차 실패입니다:

  1. 열린 외부 PR 을 확인하지 않고 내부 작업 시작gh pr list 를 작업 시작 전에 체크했어야 합니다
  2. PR fix(renderer): HY 계열 한글 폰트명 → 메트릭 DB alias 7종 추가 (#259) #264 자진 close 를 감지하지 못함 — 저녁에 작업지시자가 "264번을 아무 코멘트 없이 close 시켰냐" 라고 지적하기 전까지 존재조차 몰랐습니다
  3. 결과적으로 기여자의 5-Stage 성실 작업이 무의미해짐 — 무엇보다 이 부분이 가장 뼈아픕니다

PR #264 를 뒤늦게 읽고

내용은 저희 #259 머지본과 거의 일치합니다:

항목 PR #264 (by @planet6897) 내부 커밋 #259 (by 저)
HY 7종 매핑 ✅ 7종 전부 동일 ✅ 7종 전부 동일 (동일 DB 영문명)
mod tests hy_normalized_names_resolve_to_db_entries ✅ 6건 (hy_family_all_map 포함)
5-Stage 문서 ✅ Stage 1~5 완주 ✅ Stage 1~5 완주
DB 영문명 근거 ✅ 한컴 PS name + Fontke/Wfonts 교차 확인 (문서 mydocs/tech/task_259_hy_mapping.md) 관례 + 실측
추가 범위 HY 7종 HY 7종 + 본한글 13종 → Pretendard + 본명조 10종 → Noto Serif KR 근사

두 분 (저와 @planet6897 님) 의 접근 방향이 놀라울 정도로 수렴 했습니다. 특히:

이는 @planet6897 님의 분석이 정확했다는 증거이기도 합니다.

다만 @planet6897 님의 PR 에는 저희 머지에 없는 좋은 자료도 있었을 것입니다 — 특히 DB 영문명 공개 폰트 메타 교차 확인 (mydocs/tech/task_259_hy_mapping.md) 은 저희보다 체계적인 근거 문서화입니다.

바로잡기

@planet6897 님께

소중한 시간을 들여주신 5-Stage 작업이 헛되게 된 점 진심으로 죄송합니다. 동시에, 저희와 동일한 결론에 독립적으로 도달하신 것은 이 프로젝트에 대한 이해도와 판단력의 증거입니다. PR #256 · #262 · #264 세 건 모두 무상으로 기여해주셨다는 사실도 다시 기억하겠습니다.

앞으로 같은 실수를 반복하지 않도록 프로세스를 고치겠습니다. 감사합니다.

@edwardkim

Copy link
Copy Markdown
Owner

추가 기록 — 방금 작업지시자가 진짜 원인을 정확히 지목 했습니다.

"우리가 이 타스크를 assign 으로 돌리지 않고 한게 실수군요."

맞습니다. @planet6897 님이 이슈 #259 를 보고 합리적으로 "진행자 없음 = 오픈 타스크" 로 판단하신 건 당연한 해석이고, 저희가 이슈에 --add-assignee 를 하지 않은 것이 이번 중복의 근본 원인입니다.

"열린 PR 을 확인했어야 한다" 는 이차 방어선 이고, assign 은 일차 방어선. 이슈에 assignee 가 있었다면 @planet6897 님은 PR 을 시작조차 하지 않으셨을 것이고, 하루 저녁의 5-Stage 작업이 무의미해지는 일도 없었을 것입니다.

재발 방지 메모리 엔트리를 두 단계로 분리해 기록했습니다:

  • `feedback_assign_issue_before_work.md` (일차 방어선 — 근본 원인)
  • `feedback_check_open_prs_first.md` (이차 방어선 — 보조 안전장치)

타스크 프로세스 순서도 "이슈 확인 → assign → 브랜치 → 할일 → 계획서 → 구현" 으로 갱신합니다.

거듭 죄송합니다.

edwardkim added a commit that referenced this pull request Apr 23, 2026
작업지시자 지적으로 발견: 이슈 #259 를 내부 작업하기로 하고도
GitHub 이슈에 assignee 를 지정하지 않음. @planet6897 이 합리적으로
"진행자 없음 = 오픈 타스크" 로 판단해 PR #264 로 5-Stage 완주 해결.
저희가 먼저 머지 → 기여자 자진 close.

근본 원인은 "이슈 assign 누락" 이며, "열린 PR 미확인" 은 이차 방어선.
메모리 2건 추가:
- feedback_assign_issue_before_work.md (일차 방어선, 근본)
- feedback_check_open_prs_first.md (이차 방어선, 보조)

타스크 프로세스 순서 갱신: 이슈 확인 → assign → 브랜치 → 할일 → 계획서 → 구현

PR #264 에 공식 사과 코멘트 2건 게시 (#issuecomment-4305404514 / 4305424633).
@planet6897 planet6897 deleted the local/task259 branch April 24, 2026 01:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants