크라우니워드프로세서 기초도구 — PDF텍스트.한선

개요

크라우니워드프로세서 기초도구 시리즈의 PDF 최소 생성기. 순수 한선씨(가져오기 없음, 자기완결)로 "%PDF-1.4" 헤더부터 xref/트레일러까지 바이트 정확한 최소 PDF/1.4 텍스트를 조립한다.

무엇을 했는지

파일: /Users/ef/crowny-word/도구/PDF텍스트.한선 (완전 한선씨, 자체시험 36/36 PASS)

함수(요구 명세 전부 + 헬퍼):

PDF헤더생성·PDF객체텍스트·카탈로그·페이지트리·페이지객체·폰트객체

텍스트스트림(BT/Tj/ET, ASCII 우선) / 컨텐츠객체

xref오프셋계산·트레일러

문서PDF조립(1페이지 이상), PDF문서생성·PDF페이지추가·페이지에텍스트추가

다중페이지분할(긴 텍스트 → 여러 페이지)

MM을PT(mm→pt, 210mm≈595pt A4폭 검증)

EOF검증(%%EOF 존재 확인), PDF저장

헬퍼: 바이트수(UTF-8 바이트수, 소켓프레임 관용구 재사용), 절단나눗셈/양수나머지(자연반올림 회피),

채움10자리(xref 10자리 오프셋), 옥텟/옥텟이스케이프(한글 등 비ASCII를 UTF-8 바이트 8진 이스케이프로 근사)

• 데이터 표현: 맵(맵생성/맵넣어) 대신 평탄 배열([폭,높이,스트림] 3칸 반복)로 문서 상태 표현

— 가드레일의 "길이(맵) 함정" 회피, 기존 학습DB의 map 기반 PDF 패턴(fn_PDF_*)을 참고만 하고 실제 구현은 배열 기반으로 재설계.

• 오브젝트 번호 고정 규약: 1=Catalog, 2=Pages트리, 3=폰트(Helvetica), 페이지 i(0-base)

Page객체=4+i2, Contents객체=5+i2.

• 검증: /tmp/크라우니PDF텍스트시험.pdf(2페이지) 생성 후 file 명령으로 확인 —

PDF document, version 1.4, 2 pages 인식. Python으로 xref 오프셋 7개 전부 바이트 단위 재검증(정확 일치), startxref 값이 실제 "xref" 키워드 위치와 정확히 일치.

잔여 이슈 / 범위 밖

• 압축 스트림(FlateDecode)·폰트 임베딩(CID 한글 폰트)·암호화는 범위 밖.
• 한글 텍스트는 UTF-8 바이트를 8진 이스케이프로 정확히 보존하지만, 표준 /Helvetica(WinAnsi류)

폰트에는 한글 글리프가 없어 실제 뷰어 렌더는 보장하지 않음(바이트 근사만).

• multi-return 불가 제약으로 문서 상태를 3칸 평탄 배열로 설계 — 페이지 수가 매우 많아지면

배열 1023 요소 상한(≈341페이지)에 도달할 수 있음(대량 문서는 샤딩 필요, 현재 범위 밖).

함정 재확인(이번 세션)

• 함수 10자리채움(n) 처럼 함수명이 숫자로 시작하면 hanseonc_high 파싱 실패

(함수명 기대, '10' 발견) → 채움10자리로 개명.

• 통과 = 통과 + 확인수(...) 인라인 누적(가드레일 §4 "누산=누산+함수호출() 금지")이

36개 단순 함수 호출에서도 재현 — 매 assert 라인이 값을 1로만 유지하고 누적 실패. r결과 = 확인수(...); 통과 = 통과 + r결과 임시변수 분리로 해결(36/36 PASS 확인). 기존 RTF내보내기.한선 등 동일 인라인 패턴을 쓴 파일도 같은 버그를 가질 가능성 있음(미검증, 후속 점검 권장).

크라우니코드: lookup HIT 10건(fn_PDF_* 패턴 검색·검토, 맵 기반이라 재사용 대신 재설계 근거로 활용) / MISS 다수(신규 배열기반 구현) / learn 추가 4건(PDF객체텍스트생성·PDFxref오프셋계산·PDF옥텟이스케이프한글근사·PDF절단나눗셈양수나머지헬퍼)