요약

• samples/exam_math.hwp 페이지 7 의 18번 "수열" 문항 첫 줄이 좌측 단의 우측 끝으로 밀려 렌더되던 버그를 해결 (closes cross-run 탭 감지가 inline_tabs를 무시하여 좌측 탭이 우측 정렬로 오판정 (exam_math.hwp p.7 #18) #290).
• src/renderer/layout/paragraph_layout.rs 의 cross-run 우측/가운데 탭 감지 블록 (est 측 :854-868 + render 측 :1213-1226) 이 마지막 \t 의 종류를 판정할 때 find_next_tab_stop (TabDef 전용) 만 호출하여 본문 tab_extended (inline_tabs) 를 무시했음. LEFT inline 탭이 auto_tab_right 폴스루로 RIGHT 오판되어 다음 run 이 우측 끝으로 역산 배치됨.
• 신규 헬퍼 resolve_last_tab_pending 으로 inline_tabs 우선 참조 + TabDef 폴백 경로 통합. est/render 양쪽 루프에 inline_tab_cursor_* 도입.
• 결과: "수" 글리프 x=290.9 → x=109.8 (PDF 일치). 회귀 4 문서 184 페이지 중 1 페이지만 변경 (의도 100%).

배경과 원인

작업지시자 제보: samples/exam_math.hwp p.7 #18 문항 첫 줄이 PDF 와 다르게 보임.

PDF (정답): 18. 수열 {a_n}이 모든 자연수 n에 대하여
SVG (버그): 18. ··························· 수열 {a_n}이 모든 자연수 n에 대하여

IR 관찰 (paragraph 0.144)

text     : "18.\t\t\t수열 이 모든 자연수 에 대하여"
tab_def  : [12.0mm(L), 13.3mm(L), 18.0mm(L), 18.6mm(L)]  auto_tab_right=true
inline   : [132,_,256,...] [671,_,256,...] [79,_,256,...]  # ext[2]=0x0100 → LEFT

트레이스로 확정한 메커니즘 (임시 RHWP_TRACE290)

1. Run "18.\t\t\t" 의 3 개 \t 는 inline 경로에서 LEFT 로 x=38.24 까지 진행 (정상).
2. 그러나 cross-run 감지는 TabDef 만 봄 → abs_before=37.19 > 모든 stops → auto_tab_right 폴스루 → type=1 (RIGHT) 반환.
3. pending_right_tab_render = Some((420.11, 1)) 설정.
4. 다음 run "수열 이 모든 자연수 " 배치 시 x = col_area.x + 420.11 - next_w(201.00) = 290.91 로 역산 → 우측 끝 근처 배치.

ext[2] 포맷 실증 (Stage 1)

RIGHT 샘플 (samples/hwp-3.0-HWPML.hwp 저작권\t1) 확보 + 트레이스 비교:

→ ext[2] 는 high/low byte 합성 값. high=탭 종류 enum+1 (1=LEFT, 2=RIGHT, 3=CENTER, 4=DECIMAL), low=fill_type.

수정 내용

1. 신규 헬퍼 resolve_last_tab_pending

pub(crate) fn resolve_last_tab_pending(
    run_text: &str,
    last_inline_idx: usize,
    tab_extended: &[[u16; 7]],
    text_style: &TextStyle,
    tab_stops: &[TabStop],
    tab_width: f64,
    auto_tab_right: bool,
    available_width: f64,
) -> Option<(f64, u8)> {
    // 1) inline_tabs 가 마지막 \t 를 커버: ext[2] 고바이트로 종류 판정
    if last_inline_idx < tab_extended.len() {
        let inline_type = ((tab_extended[last_inline_idx][2] >> 8) & 0xFF) as u8;
        match inline_type {
            0 | 1 => return None,  // LEFT → pending 없음 (본 수정의 핵심)
            2 | 3 => {}            // RIGHT/CENTER → TabDef 경로로 폴스루
            _ => return None,      // 미지 값 (4=DECIMAL 등) → 보수적 LEFT
        }
    }
    // 2) inline 이 LEFT 아님 or inline 없음 → 기존 find_next_tab_stop 경로
    /* ... */
}

2. cross-run 블록 2 곳 교체 + inline_tab_cursor_*

• est 측 루프 (:840): inline_tab_cursor_est: usize = 0 도입, 기존 블록을 헬퍼 호출로 교체.
• render 측 루프 (:1198): inline_tab_cursor_render: usize = 0 도입, 동일 교체.
• 루프 말미 + char_overlap continue 직전에 cursor += run.text.chars().filter(|c| *c == '\t').count() 증가.
• composed.tab_extended 는 parser 에서 0x0009 (TAB) 마다 1 개씩 push 되므로 \t 카운트와 정확히 일치.

3. 테스트 신규

• 단위 5 건 (src/renderer/layout/tests.rs): LEFT→None / RIGHT→Some / CENTER→Some / inline 없음 폴백 2 건.
• 통합 1 건 (tests/tab_cross_run.rs): exam_math.hwp p.7 렌더 후 item 18 "수" glyph x < 200 검증.

변경 전/후 (SVG transform)

item 18 첫 줄의 14 글자 모두 일관되게 -181.11 px 좌측 이동:

검증

회귀 검증 (git worktree baseline diff)

시각 비교 (3 면 PNG)

mydocs/working/task_m100_290_stage3/p7_{before,after,pdf}.png — AFTER = PDF 일치.

범위 외 후속 과제

• inline_tabs RIGHT/CENTER 렌더 경로 (text_measurement.rs:217, 320): ext[2] 를 전체 u16 으로 해석 → 실제 HWP 값 (최소 256) 과 매칭 안 됨 → inline RIGHT/CENTER 경로 영원히 도달 불가. 저작권\t1 케이스가 "그럭저럭 보이는" 이유는 RIGHT 탭이 LEFT 처리되어 우연히 우측 정렬과 유사해서. 별도 이슈 후보.
• TabDef /2.0 스케일 (style_resolver.rs:640): 수식 레이아웃 보정: 한컴 기준값 측정 및 상수 조정 #142, 원문자(①~⑤) 폭 추정 오류 및 탭+TAC 위치 계산 불일치 #159 에서 "한컴 격자 비교로 확정" 되었으나 본 수정과 별개 경계 케이스 잠재. 본 타스크에서는 변경하지 않음.

교훈

1. 수식 레이아웃 보정: 한컴 기준값 측정 및 상수 조정 #142 의 "같은 데이터를 다른 경로로 계산하는 코드는 반드시 동기화" 교훈이 이번엔 estimate_text_width/compute_char_positions 가 아니라 run 내부 탭 처리 vs cross-run 탭 감지 의 불일치로 재발. 런
   내부는 inline_tabs 를 봤지만 cross-run 감지는 TabDef 만 봤음. 헬퍼 중앙화 (resolve_last_tab_pending) 로 경계 통일.
2. 트레이스 기반 원인 확정의 위력 — 임시 RHWP_TRACE290 로 양쪽 호출의 입력/출력을 동시 관측 → 추측 없이 pending_right_tab = Some((420.11, 1)) → x_after=290.91 로 이어지는 전 경로를 숫자로 연결.
3. git worktree 활용 baseline diff — fix 전 커밋의 독립 빌드로 184 페이지 byte-level 회귀를 자동 검증. "변경 / 전체 = 1 / 184" 같은 객관적 지표 제공.
4. 범위 의식적 제어 — inline_tabs RIGHT/CENTER 렌더 버그를 발견했지만 본 타스크 범위에 포함하지 않고 후속 이슈로 분리. 범위가 커지면 회귀 위험도 증가.

산출물

코드

• src/renderer/layout/paragraph_layout.rs — 헬퍼 추가 + cross-run 블록 2 곳 교체 + cursor 2 개 도입 (+86 / -24 줄)
• src/renderer/layout/tests.rs — 단위 테스트 5 건 (+83 줄)
• tests/tab_cross_run.rs — 통합 테스트 1 건 (신규)

문서

• mydocs/plans/task_m100_290{,_impl}.md — 수행/구현 계획서
• mydocs/working/task_m100_290_stage{1,2,3,4}.md — 단계별 완료 보고서
• mydocs/working/task_m100_290_stage3/p7_{before,after,pdf}.png — 3 면 시각 비교
• mydocs/report/task_m100_290_report.md — 최종 보고서
• mydocs/troubleshootings/tab_tac_overlap_142_159.md — cross-run 탭 감지가 inline_tabs를 무시하여 좌측 탭이 우측 정렬로 오판정 (exam_math.hwp p.7 #18) #290 섹션 추가 (수식 레이아웃 보정: 한컴 기준값 측정 및 상수 조정 #142 교훈 확장)
• mydocs/orders/20260424.md — 완료 항목 추가

커밋

1e9d42a Task #290 단계4: 최종 보고서 + 오늘할일/트러블슈팅 갱신 (closes #290)
0d2b747 Task #290 단계3: 통합 테스트 + 184페이지 회귀 + before/after/PDF 3면 시각 비교
3c8bc4f Task #290 단계2: resolve_last_tab_pending 헬퍼 + cross-run 블록 교체 + 단위 테스트 5건
7d3bbba Task #290 단계1: 원인 트레이스 + ext[2] 매핑 실증 + 계획서