퍼블리싱 모델
Imposia가 미리보기, 인쇄, 내보내기를 하나의 확정된 문서에 맞추는 방식을 설명합니다.
이미지, 표, 많은 페이지가 있는 문서는 페이지네이션에 시간이 걸립니다. Imposia는 다음 문서를 준비하는 동안 마지막으로 완성된 문서를 계속 보여주므로, 사용자는 완성되지 않은 레이아웃을 보지 않습니다.
사용자가 보는 문서
Core는 화면 표시와 인쇄의 기준이 되는 canonical iframe 하나를 계속 유지합니다. 이 iframe에는 마지막으로 페이지네이션에 성공한 문서가 들어 있습니다.
React 컴포넌트와 Viewer는 이 iframe을 그대로 표시합니다. 페이지를 복제하거나 표시용 문서를 따로 만들지 않습니다.
원본이 바뀔 때 일어나는 일
- Core가 새 원본을 위한 임시 iframe(staging iframe)을 만듭니다.
- 거기에서 승인된 에셋을 불러오고 문서 전체를 페이지로 나눕니다.
- 페이지네이션이 성공하면 canonical iframe의 내용을 한 번에 교체합니다.
- 작업이 실패하거나 취소되거나 더 새로운 요청으로 대체되면 임시 iframe을 제거하고 이전 문서를 그대로 보여줍니다.
임시 iframe은 미리보기, 화면 표시, 인쇄에 사용되지 않습니다.
출력마다 만들어지는 방식
미리보기와 네이티브 인쇄가 일상적인 두 출력이며, 둘 다 canonical iframe을 바라봅니다. 확정 시점에는 의미 구조를 가진 원본도 함께 보존되므로, 의미 구조 산출물이 필요하면 같은 세대에서 리플로우형 EPUB을 추가로 만들 수 있습니다.
| 출력 | 원본 | 결과 |
|---|---|---|
| 미리보기 | canonical iframe | Viewer가 보여주는 완성된 페이지입니다. |
| 인쇄 | canonical 페이지를 최상위 문서의 격리된 스냅샷으로 복사한 뒤 Window.print()를 호출합니다. | 브라우저의 기본 인쇄 절차입니다. Imposia는 PDF 바이트를 반환하지 않습니다. |
| EPUB | 마지막으로 확정된 원본 | 페이지 DOM의 고정 레이아웃 복사본이 아닌 리플로우형 EPUB 3.3 Blob입니다. |
PageDocument.exportEpub()은 확장 기능을 다시 실행하지 않고, 고정된 페이지 레이아웃을 직렬화하지도 않습니다. 이 구분이 중요합니다. EPUB은 리플로우형 리더를 위한 의미 구조 산출물이지, 미리보기를 PDF처럼 찍어낸 스냅샷이 아닙니다.
Viewer와 네이티브 인쇄가 일치하는 이유
Viewer에서 확정된 문서의 2·3페이지를 연 다음, 브라우저 인쇄 미리보기에서 PDF로 저장을 선택해 보세요. 두 곳 모두 같은 내용과 페이지 순서가 나타납니다.
Viewer의 2페이지에는 표의 01–22행, 반복 표 머리글, LEFT / 2 머리말이 표시됩니다.
Viewer의 3페이지에는 이어지는 23–36행과 RIGHT / 3 머리말이 표시됩니다.
PDF로 저장 미리보기에도 위와 같은 2·3페이지의 표 내용, 페이지 순서, 반복 표 머리글, 머리말이 그대로 나타납니다.
Imposia는 인쇄를 위해 레이아웃을 다시 계산하거나 PDF 렌더러를 만들지 않습니다. print()는 승인된 canonical 페이지와 세대 스타일을 최상위 문서의 일시적이고 격리된 Shadow Root로 복제한 뒤, 최상위 Window.print()를 호출합니다. Chromium의 불안정한 iframe 인쇄 스냅샷을 피하면서 확정된 페이지 순서를 보존하는 방식입니다. 문서화된 지원 범위 안에서는 용지 방향, margin box, 반복 표 머리글, 페이지 번호, 본문 순서가 Viewer와 브라우저 인쇄·PDF 저장 결과에서 그대로 유지됩니다.
인쇄 중에는 경쟁하는 최상위 @page 규칙을 두지 마세요
인쇄 호스트는 페이지 콘텐츠와 세대 스타일을 격리하지만, CSS @page 규칙은 문서 전체에 적용됩니다. 호스트 앱의 이름 없는 최상위 @page 규칙은 Imposia가 자기 페이지를 위해 끌어올린 인쇄 규칙과 상호작용할 수 있으므로, print()를 호출하기 전에 그런 규칙을 제거하거나 범위를 한정하세요.
Viewer와 PDF로 저장 미리보기가 일치하는 이유는 두 경로가 같은 확정된 문서를 바라보기 때문입니다. Imposia가 PDF 바이트를 반환한다는 뜻은 아닙니다. 프린터 드라이버의 여백, 배율, 색 보정과 브라우저별 글꼴 측정은 여전히 최종 결과에 영향을 줄 수 있습니다.
외부 리소스를 제어하세요
외부 리소스는 호스트 앱의 assetResolver로만 들어옵니다. Core는 이 경로에서 만들어진 Blob URL을 소유하며, 문서가 교체되거나 실패하거나 제거될 때 URL을 폐기합니다.
정제된 입력, 리졸버 결과, 확장 기능에는 문서화된 제한이 적용됩니다. 기능을 정확히 적용할 수 없으면 Imposia는 임의로 추측하지 않고 코드가 있는 경고를 보고합니다.
호환성 경계를 확인하세요
- 안정(Stable): 브라우저 ESM API, iframe 수명 주기, 리소스 격리, 지원되는 페이지 미디어, 네이티브 인쇄, 리플로우형 EPUB.
- 제한(Constrained): 문서화된 범위의 표, flex, grid, 다단 레이아웃, 참조, named string.
- 실험(Experimental): 직접 켜야 하는 페이지 내부 각주와 페이지 float. 이 기능들은 경고를 보고합니다.
- 미지원: Node·CLI 렌더링, 서버 내보내기, PDF 바이트, 고정 레이아웃 EPUB, 임의의 CSS 분할, 브라우저 간 동일한 페이지 수.
페이지 구조의 기준으로는 Chromium을 사용하세요. Firefox와 WebKit은 공개 API와 수명 주기를 지원하지만, 측정값과 줄바꿈은 다를 수 있습니다.