Release v0.7.3 (라이브러리) / v0.2.0 (확장)

mydocs/feedback/task139-eq-01.md

@@ -0,0 +1,31 @@
+공유해주신 `rhwp` 프로젝트의 수식 처리 고도화 설계 문서를 매우 흥미롭게 읽어보았습니다. 
+
+한컴의 기존 생태계(HWP 문서 호환성)를 완벽히 유지하면서도, 웹 플랫폼의 특성과 글로벌 학술 표준(LaTeX)을 동시에 수용하려는 깊이 있는 고민이 돋보이는 훌륭한 아키텍처입니다. 작성해주신 두 문서의 핵심 결정을 요약하고, 설계 단계에서 추가로 고려해 볼 만한 엔지니어링 포인트를 몇 가지 덧붙여 보았습니다.
+
+### 💡 주요 설계 결정 요약 및 평가
+
+**1. 수식 폰트 체계 설계**
+* **최적의 폰트 선정:** 기존 한컴 수식 폰트(HyHwpEQ)의 뿌리인 Computer Modern과의 시각적 일관성을 위해 **Latin Modern Math**를 1순위로 채택한 것은 기존 사용자들의 이질감을 없애는 탁월한 선택입니다.
+* **안정적인 폴백 체계:** 영문/기호는 `Latin Modern Math`와 `STIX Two Math`로 커버하고, 폰트 내 글리프가 없는 한글은 이미 번들링된 `Pretendard`로 자연스럽게 폴백되도록 `font-family` 체인을 구성한 것은 추가 리소스 로딩을 최소화하는 효율적인 웹 최적화 방식입니다.
+
+**2. 입력 파서 아키텍처**
+* **안전한 확장 (전략 A):** 토크나이저와 파서만 한컴용/LaTeX용으로 분리하고, 이미 문법에 독립적으로 설계된 공통 AST(`EqNode`)와 그 하위 렌더링/레이아웃 파이프라인을 그대로 재사용하는 아키텍처는 회귀 버그(Regression) 위험을 최소화합니다. 
+* **듀얼 모드 지원:** MS Word의 선형 모드(Linear)처럼 기존 한컴 문법 사용자와 신규 LaTeX 사용자를 모두 만족시킬 수 있는 방향성입니다. 향후 AI(LLM)가 출력하는 LaTeX 수식을 즉시 붙여넣을 수 있게 되면 활용도가 극대화될 것입니다.
+
+---
+
+### 🛠️ 추가 고려사항 (엔지니어링 & UX 관점)
+
+설계하신 내용을 바탕으로 실제 구현 시 마주할 수 있는 몇 가지 엣지 케이스를 제안해 드립니다.
+
+**1. 폰트 로딩 시점과 수식 레이아웃(Bounding Box) 틀어짐 방지**
+* 문서에서 제안하신 `font-display: swap` 방식은 텍스트가 빠르게 표시된다는 장점이 있습니다. 
+* 하지만 수식 렌더러는 분수(Fraction)의 선 위치나 첨자(Sub/Superscript)의 위치를 픽셀 단위로 정밀하게 계산해야 합니다. 웹 폰트(woff2)가 로드되기 전에 브라우저 기본 폰트로 먼저 `LayoutBox`가 계산되면, 이후 폰트가 교체되었을 때 수식 기호가 겹치거나 여백이 틀어질 위험이 있습니다. 
+* **제안:** 수식 렌더링을 시작하기 전, Web Font Loader API(`document.fonts.load()`)를 활용해 `Latin Modern Math` 폰트가 완전히 로드된 것을 보장한 후 AST에서 레이아웃 계산을 트리거하는 동기화 로직을 고려해 보시면 좋습니다.
+
+**2. LaTeX 자동 감지 로직의 엣지 케이스**
+* 입력 문자열 첫 비공백 문자가 `\`일 때 LaTeX 모드로 전환하는 로직은 가볍고 빠릅니다.
+* 다만, 사용자가 변수명(예: `x = ...`)부터 입력하기 시작하다가 수식 중간에 `\frac`을 타이핑하는 상황이 발생할 수 있습니다. 이 경우 첫 글자가 `\`가 아니므로 한컴 모드로 파싱되어 에러가 발생할 수 있습니다.
+* **제안:** UI 상단에 현재 파싱 모드(한컴 ↔ LaTeX)를 명시적으로 보여주는 토글 버튼을 배치하고, 한컴 모드 파싱 중 에러가 발생하거나 `\` 기호가 발견되면 "LaTeX 모드로 전환하시겠습니까?"라는 힌트를 제공하는 UX가 필요할 수 있습니다.
+
+---

mydocs/manual/MEMORY.md

@@ -0,0 +1,15 @@
+- [작업 시간 제한 금지](feedback_no_time_limits.md) — 클로드가 임의로 작업 종료 제안 금지, 작업지시자가 결정
+- [한컴 LINE_SEG 자동 재계산](project_hancom_lineseg_behavior.md) — LINE_SEG가 비어있어도 한컴이 자체 재계산. 역공학 샘플 전략의 기반
+- [타스크 번호는 GitHub Issues로 채번](feedback_task_numbering.md) — gh issue create로 자동 채번, 수동 번호 할당 금지
+- [마일스톤 표기 규칙](feedback_milestone_notation.md) — v1.0.0→M100, v0.5.x→M05x. 오늘할일에서 M100 #1 형식 사용
+- [안드로이드 IME 미구현](project_android_ime_pending.md) — 기기 미보유로 미테스트. iOS는 contentEditable+디바운스로 해결. 기기 확보 시 구현 필요
+- [Discord 커뮤니티](reference_discord.md) — Rust Discord에 프로젝트 소개 (2026-04-04)
+- [타스크 프로세스 반드시 준수](feedback_process_must_follow.md) — 이슈→브랜치→할일→계획서→구현 순서 절대 생략 금지. #61에서 위반 발생
+- [이슈 클로즈는 작업지시자 승인 필수](feedback_no_close_without_approval.md) — 미해결 상태 임의 클로즈 금지. #62에서 위반 발생
+- [로컬 폰트 경로](reference_font_path.md) — TTF 폰트는 /home/edward/mygithub/ttfs에 프로젝트 외부 분리
+- [작업 문서 네이밍 규칙](feedback_working_doc_naming.md) — task_m100_{번호}_stage{단계}.md 패턴 필수
+- [최종 보고서 위치 규칙](feedback_report_location.md) — 최종 보고서는 mydocs/report/, 단계별 보고서는 mydocs/working/
+- [보고서는 타스크 브랜치에서 커밋](feedback_commit_reports_in_branch.md) — 보고서·오늘할일 갱신은 타스크 브랜치에서 소스와 함께 커밋. merge 전 git status 필수
+- [오늘할일 문서 작업일지 갱신 필수](feedback_update_daily_orders.md) — 작업한 내용은 반드시 mydocs/orders/yyyymmdd.md에 기록. 세션 종료 전 커밋
+- [알한글 iOS 프로젝트](project_alhangeul_ios.md) — iPad HWP 학습 도구, 맥북 전용(ios/devel), 리눅스에서 빌드 불가. 현재 환경에서 작업 불가
+- [output 폴더 서브폴더 구조](project_output_folder_structure.md) — output/re/(재현검증), output/svg/(SVG), output/debug/(디버그) 용도별 분리. 새 출력 코드는 반드시 서브폴더에 저장

mydocs/orders/20260414.md

@@ -10,3 +10,4 @@
 | [#137](https://github.com/edwardkim/rhwp/issues/137) | samples/ 잔재 자동생성 파일 6개 삭제 (dotum-times 계열) | 완료 | |
 | [#138](https://github.com/edwardkim/rhwp/issues/138) | output/ 서브폴더 구조 설계 및 문서화 | 완료 | CLAUDE.md, MEMORY.md 갱신 |
 | [#138](https://github.com/edwardkim/rhwp/issues/138) | 역공학 → 재현검증 용어 변경 (CLAUDE.md, re_sample_gen.rs) | 완료 | |
+| [#139](https://github.com/edwardkim/rhwp/issues/139) | 수식 렌더링 고도화: 분석/방향 수립 (플랜 모드) | 완료 | LaTeX 비교, 폰트 선정, 레이아웃 설계 |

mydocs/plans/task_m100_139.md

@@ -0,0 +1,104 @@
+# 수행계획서: 수식 렌더링 고도화
+
+- **타스크**: [#139](https://github.com/edwardkim/rhwp/issues/139)
+- **마일스톤**: M100
+- **브랜치**: `local/task139`
+- **작성일**: 2026-04-14
+
+## 1. 배경
+
+Task #181에서 수식 파서/레이아웃/렌더러 기본 구현이 완료되었다(85~90%). 수식 편집 UI도 한컴 방식으로 구현되어 있다(equation-editor-dialog.ts, 48개 템플릿 버튼, 실시간 SVG 미리보기).
+
+### 전략적 배경
+
+한컴의 수식 입력 방식은 초창기부터 자체 문법(OVER, SQRT 등)을 사용해왔으며, 최신 LaTeX와 비교하면 진부하다는 평가가 많다. 한컴 디벨로퍼 포럼([LaTeX 수식 쓰레드](https://forum.developer.hancom.com/t/latex/1810))에서도 사용자들이 LaTeX 표준 지원을 강력히 요청하고 있으며, 한컴 측도 내부적으로 준비 중이라 답변했으나 구체적 일정은 미공개 상태이다.
+
+rhwp는 기존 한컴 수식 호환을 유지하면서, 편집 부분에서 최신 발전된 수식 입력기를 구현하여 수학/과학 분야 사용자들에게 차별화된 가치를 제공하는 것을 전략 목표로 한다.
+
+### 기술적 개선 필요 사항
+
+1. **수식 입력 방식 단일**: 현재 한컴 방식 스크립트만 지원. LaTeX 문법과의 비교 분석을 통해 향후 입력 방식 개선 방향을 수립해야 한다.
+2. **수식 폰트 부재**: SVG/Canvas 렌더링 시 `font-family`가 지정되지 않아 브라우저 기본 폰트로 렌더링됨. 수식 기호(∫, Σ, ∏ 등)와 그리스 문자의 표현 품질이 낮음.
+3. **수식 레이아웃 부정확**: 매트릭스의 열 간격(MATRIX_COL_GAP=0.8)과 행 간격(MATRIX_ROW_GAP=0.3)이 임의 상수로 설정됨. 수식 컨트롤의 문단 내 배치(높이, 너비)가 한컴 편집기와 불일치.
+
+## 2. 목표
+
+- LaTeX vs 한컴 수식 입력 방식 비교 분석 및 개선 방향 수립
+- 수식에 최적화된 오픈 라이선스 폰트를 검토하고 적용하여 렌더링 품질 향상
+- 수식 컨트롤의 문단 배치, 매트릭스(높이/너비)를 한컴 편집기와 동일한 방식으로 구현
+
+## 3. 현황 분석
+
+### 3.1 수식 입력/편집 현황
+
+- **렌더링**: Rust 수식 엔진 (tokenizer → parser → layout → svg_render/canvas_render)
+- **편집 UI**: `equation-editor-dialog.ts` — 한컴 방식 스크립트 직접 편집, 48개 템플릿 버튼, 실시간 SVG 미리보기(300ms 디바운스)
+- **WASM API**: `renderEquationPreview()`, `getEquationProperties()`, `setEquationProperties()`
+- **입력 방식**: 한컴 수식 스크립트만 지원 (OVER, SQRT, INT 등). LaTeX 문법 미지원
+
+### 3.2 수식 폰트 현황
+
+- `svg_render.rs`: `<text>` 요소에 `font-family` 속성 없음 → 브라우저 기본 serif/sans-serif로 렌더링
+- `canvas_render.rs`: Canvas `ctx.font`에도 수식 전용 폰트 미지정
+- `font_fallback_strategy.md`: CJK 폰트 폴백 전략은 수립되었으나 수식 폰트는 미포함
+
+### 3.3 수식 레이아웃 현황
+
+- `layout.rs` 상수: `MATRIX_COL_GAP=0.8`, `MATRIX_ROW_GAP=0.3` (font_size 비율)
+- 문단 배치: `shape_layout.rs`에서 `eq.common.width/height`(HWPUNIT)를 그대로 사용
+- 한컴 편집기와의 치수 비교 미수행 상태
+
+## 4. 구현 단계
+
+### 4.1 단계 구성 (4단계)
+
+#### 1단계: LaTeX vs 한컴 수식 입력 방식 비교 분석
+
+- **문법 비교**: 한컴 방식(OVER, SQRT, INT)과 LaTeX 방식(\frac, \sqrt, \int) 명령어 대응표 작성
+- **장단점 분석**:
+  - 한컴 방식: 한국 사용자 친숙도, 기존 HWP 문서 호환성
+  - LaTeX 방식: 국제 표준, 학술/과학 커뮤니티 보편성, 풍부한 생태계
+- **사용자 요구 분석**: 한컴 포럼 피드백, 학술/과학 분야 사용 패턴 정리
+- **현재 파서 확장성 평가**: 기존 tokenizer/parser 구조에서 LaTeX 문법 지원 가능 여부 분석
+- **개선 방향 제안**: 듀얼 입력 모드, 자동 변환, LaTeX 입력 레이어 추가 등 전략 비교
+- 분석 결과를 `mydocs/tech/equation_latex_comparison.md` 기술 문서로 작성
+
+#### 2단계: 수식 폰트 조사 및 선정
+
+- 오픈 라이선스 수식 폰트 후보 조사
+  - STIX Two Math (OFL), Latin Modern Math (GUST), XITS Math (OFL), Libertinus Math (OFL), Fira Math (OFL) 등
+- 한컴 수식 편집기 기본 폰트(수식용)와의 글리프 대응도 비교
+- 그리스 문자, 적분/합 기호, 분수, 첨자 등 핵심 수식 요소의 렌더링 품질 평가
+- 최적 폰트 선정 및 근거 문서화
+
+#### 3단계: 수식 폰트 적용
+
+- 선정된 폰트의 font-family 체인 설계
+- `svg_render.rs`: 모든 `<text>` 요소에 수식 전용 font-family 적용
+- `canvas_render.rs`: Canvas `ctx.font`에 수식 전용 폰트 적용
+- 웹 환경 폰트 로딩 방식 결정 (woff2 번들링 vs local() 참조 vs CDN)
+- 테스트: 주요 수식 샘플 SVG 출력 비교
+
+#### 4단계: 수식 레이아웃 정밀화
+
+- 한컴 편집기에서 매트릭스 샘플 문서 생성 → rhwp 렌더링 결과와 비교
+- `layout.rs` 상수 조정: MATRIX_COL_GAP, MATRIX_ROW_GAP 등을 한컴 기준에 맞춤
+- 수식 컨트롤의 문단 내 배치(높이, 너비, 베이스라인) 정밀 조정
+- 분수, 첨자, 큰 연산자 등 주요 레이아웃 요소 치수 검증
+- 테스트: exam_math.hwp 등 실제 문서 렌더링 비교
+
+## 5. 위험 요소
+
+| 위험 | 대응 |
+|------|------|
+| LaTeX 문법 지원 시 파서 복잡도 증가 | 1단계는 분석 및 방향 수립까지만 수행, 구현은 별도 타스크 |
+| 오픈 라이선스 폰트의 한컴 수식 글리프 대응 부족 | 복수 폰트 후보 비교, 필요 시 폴백 체인 구성 |
+| 한컴 수식 레이아웃 내부 로직 비공개 | 실제 문서 렌더링 결과 비교를 통한 역추적 |
+| woff2 번들 시 용량 증가 | 서브셋 추출 또는 local() 우선 참조 전략 |
+
+## 6. 검증 방법
+
+- LaTeX vs 한컴 비교 분석 보고서 검토
+- `cargo test` 전체 통과
+- exam_math.hwp SVG 출력과 한컴 편집기 렌더링 시각 비교
+- 매트릭스/분수/첨자 등 주요 수식 요소 치수 측정 비교

mydocs/plans/task_m100_139_impl.md

@@ -0,0 +1,139 @@
+# 구현 계획서: 수식 렌더링 고도화 (분석/방향 수립)
+
+- **타스크**: [#139](https://github.com/edwardkim/rhwp/issues/139)
+- **마일스톤**: M100
+- **브랜치**: `local/task139`
+- **작성일**: 2026-04-14
+- **수행계획서**: `mydocs/plans/task_m100_139.md`
+- **모드**: 플랜 모드 — 분석/방향 수립만 수행, 실제 구현은 별도 타스크로 분리
+
+## 단계 구성 (4단계)
+
+모든 단계가 분석·조사·방향 수립이며, 소스 코드 수정은 포함하지 않는다.
+
+---
+
+### 1단계: LaTeX vs 한컴 수식 입력 방식 비교 분석
+
+**목표**: 한컴 방식과 LaTeX 방식의 체계적 비교를 통해 수식 입력 개선 방향을 수립한다.
+
+**산출물**: `mydocs/tech/equation_latex_comparison.md`
+
+**작업 내용**:
+
+1. **명령어 대응표 작성**
+   - 현재 구현된 한컴 명령어(symbols.rs, parser.rs 기반)와 LaTeX 대응 명령어 매핑
+   - 분류별 정리: 구조, 큰 연산자, 행렬, 그리스 문자, 장식, 기호
+
+2. **GUI 수식 입력 방식 비교**
+   - 한컴, MS Word, MathType, LyX, rhwp 현재 구현의 GUI 입력 방식 비교
+   - 편집 위치(인라인 vs 대화상자), 렌더링 방식(WYSIWYG vs 스크립트+미리보기), 구조 삽입 방식 분류
+
+3. **현재 파서 확장성 분석 및 확장 전략 비교**
+   - (A) 듀얼 토크나이저, (B) 전처리 변환기, (C) 통합 파서
+
+4. **개선 방향 제안서**
+   - 권장 전략 선정 및 근거, GUI 개선 방향, 향후 타스크 분리 계획
+
+---
+
+### 2단계: 수식 폰트 조사 및 선정
+
+**목표**: 오픈 라이선스 수식 폰트를 비교 평가하여 최적 폰트를 선정한다.
+
+**산출물**: `mydocs/tech/equation_font_selection.md`
+
+**작업 내용**:
+
+1. **후보 폰트 조사**
+
+   | 폰트 | 라이선스 | 특징 |
+   |------|---------|------|
+   | STIX Two Math | OFL 1.1 | STI Pub 컨소시엄, 광범위 글리프 |
+   | Latin Modern Math | GUST Font License | TeX 전통 스타일, 학술 표준 |
+   | XITS Math | OFL 1.1 | STIX 기반 확장 |
+   | Libertinus Math | OFL 1.1 | Linux Libertine 기반 |
+   | Fira Math | OFL 1.1 | Fira Sans 기반, 모던 |
+
+2. **글리프 대응도 평가**
+   - 한컴 수식에서 사용하는 핵심 글리프 커버리지 확인
+   - 그리스 문자(48종), 수학 기호(200+종), 큰 연산자, 화살표
+
+3. **렌더링 품질 비교**
+   - 실제 수식 샘플을 각 폰트로 SVG 렌더링하여 품질 평가
+
+4. **최적 폰트 선정 및 font-family 체인 설계**
+   - 1순위 수식 폰트 + 폴백 체인 구성
+   - 웹 폰트 배포 방식 결정 (woff2 용량, 서브셋 여부)
+
+---
+
+### 3단계: 수식 폰트 적용 방안 설계
+
+**목표**: 선정된 폰트를 SVG/Canvas 렌더러에 적용하기 위한 구체적 설계를 수립한다.
+
+**산출물**: `mydocs/tech/equation_font_selection.md` 내 적용 방안 섹션 추가
+
+**작업 내용**:
+
+1. **SVG 렌더러 적용 설계**
+   - `svg_render.rs`의 `<text>` 요소별 font-family 적용 방식 설계
+   - LayoutKind별(Text, Number, Symbol, MathSymbol, Function) 폰트 매핑 규칙
+
+2. **Canvas 렌더러 적용 설계**
+   - `canvas_render.rs`의 `ctx.font` 적용 방식 설계
+
+3. **웹 폰트 로딩 설계**
+   - woff2 번들링 vs local() 참조 vs CDN 방식 비교
+   - `@font-face` 선언 위치 및 로딩 타이밍 설계
+
+4. **구현 타스크 분리 계획**
+   - 수정 대상 파일 목록, 변경 범위, 테스트 계획
+
+---
+
+### 4단계: 수식 레이아웃 정밀화 방안 설계
+
+**목표**: 매트릭스/분수/첨자 등 수식 요소의 치수를 한컴 편집기와 동일하게 맞추기 위한 기준값을 조사하고 설계를 수립한다.
+
+**산출물**: `mydocs/tech/equation_layout_spec.md`
+
+**작업 내용**:
+
+1. **한컴 기준값 측정**
+   - 한컴 편집기에서 매트릭스, 분수, 적분 등 표준 수식 렌더링 → 치수 측정
+   - 열 간격, 행 간격, 여백, 기호 크기 비율 등 수집
+
+2. **현재 값 vs 한컴 기준값 비교표**
+   - `MATRIX_COL_GAP` (현재 0.8), `MATRIX_ROW_GAP` (현재 0.3) 등
+   - `FRAC_LINE_PAD` (현재 0.15), `SCRIPT_SCALE` (현재 0.7), `BIG_OP_SCALE` (현재 1.5)
+   - 각 상수의 보정 방향과 목표값 제시
+
+3. **문단 배치 분석**
+   - 수식 컨트롤의 높이/너비 계산 방식 검증
+   - 베이스라인 정렬, 인라인 수식(treat_as_char=true) 배치 분석
+
+4. **구현 타스크 분리 계획**
+   - 수정 대상 파일, 변경 범위, 비교 검증 방법
+
+---
+
+## 검증 기준
+
+| 단계 | 검증 항목 |
+|------|----------|
+| 1단계 | 비교 분석 보고서 품질, 개선 방향 타당성 |
+| 2단계 | 폰트 선정 근거 충분성, 글리프 커버리지 |
+| 3단계 | 적용 설계의 구체성, 구현 타스크 분리 명확성 |
+| 4단계 | 한컴 기준값 측정 정확성, 보정 방향 타당성 |
+
+## 후속 구현 타스크 (별도 분리)
+
+이번 타스크에서 수립한 방향을 기반으로 다음 구현 타스크를 생성한다:
+
+| 후속 타스크 | 내용 | 근거 |
+|------------|------|------|
+| LaTeX 파서 구현 | 듀얼 토크나이저 방식으로 LaTeX 입력 지원 | 1단계 분석 결과 |
+| 수식 폰트 적용 | 선정된 폰트를 SVG/Canvas 렌더러에 적용 | 2~3단계 설계 결과 |
+| 수식 레이아웃 보정 | 한컴 기준값으로 레이아웃 상수 조정 | 4단계 측정 결과 |
+| 수식 편집 UI 개선 | 듀얼 모드, 자동완성, 템플릿 확장 | 1단계 GUI 분석 결과 |