基本概念

出版モデル

プレビュー、印刷、書き出しが 1 つの確定済み文書に揃い続ける仕組みを説明します。

ページ分割には時間がかかります。画像や表を含む文書、ページ数の多い文書ではなおさらです。Imposia は次の文書を準備している間も直前に完成した文書を表示し続けるため、読者が未完成のレイアウトを見ることはありません。

読者に表示される文書

Core は 1 つの永続的な canonical iframe を所有します。この iframe には、直近でページ分割に成功した文書が入っています。

React コンポーネントと Viewer はこの iframe を直接表示します。ページを複製したり、2 つ目の表示用文書を作ったりはしません。

ソースが変わったときの処理

  1. Core が新しいソース用に一時的な staging iframe を作成します。
  2. 承認されたアセットを読み込み、文書全体をそこでページ分割します。
  3. ページ分割に成功すると、Core が canonical iframe の内容を一度に置き換えます。
  4. 処理が失敗した場合、中止された場合、より新しい処理に追い越された場合は、Core が staging iframe を削除し、以前の文書を表示し続けます。

staging iframe がプレビュー、表示、印刷に使われることはありません。

各出力の作られ方

日常的な出力はプレビューとネイティブ印刷の 2 つで、どちらも canonical iframe を参照します。確定時には意味構造を保つソースも保持されるため、意味構造の成果物が必要なときは、同じ世代からリフロー型 EPUB も作れます。

出力ソース結果
プレビューcanonical iframeViewer が表示する、ページ分割済みの完成ページ
印刷canonical ページをトップレベル文書の隔離されたスナップショットに写し、Window.print() を呼び出すブラウザー標準の印刷フロー。Imposia は PDF バイトを返しません
EPUB最後に確定した意味構造を保つソースリフロー型 EPUB 3.3 Blob。ページ DOM の固定レイアウトコピーではありません

PageDocument.exportEpub() は拡張機能を再実行せず、固定のページレイアウトを直列化することもありません。つまり EPUB は、リフロー型リーダーのための意味構造の投影であって、プレビューを PDF のように写し取ったスナップショットではありません。

Viewer とネイティブ印刷が一致する理由

Viewer で確定済み世代の 2〜3 ページ目を開き、ブラウザーの印刷プレビューでPDF に保存を選んでください。どちらにも同じ内容が同じページ順で表示されます。

Imposia Viewer に表示された同じ 2 ページ目

Viewer の 2 ページ目には、表の 01〜22 行、繰り返し表ヘッダー、LEFT / 2 のページ装飾が含まれます。

Imposia Viewer に表示された次の表ページとそのページ装飾

Viewer の 3 ページ目には、続きの 23〜36 行と RIGHT / 3 のページ装飾が含まれます。

「PDF に保存」を選んだブラウザー印刷プレビューの同じ文書

「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 を所有し、文書が置き換えられたとき、失敗したとき、破棄されたときに解放します。

サニタイズ済みの入力、リゾルバーの出力、拡張機能には、文書化された制限が適用されます。機能を正確に適用できない場合、Imposia は黙って推測せず、型付きの警告を報告します。

互換性の境界を確認する

  • 安定: ブラウザー ESM API、iframe のライフサイクル、リソースの隔離、対応するページメディア、ネイティブ印刷、リフロー型 EPUB。
  • 制約付き: 文書化されたサブセットとしてのテーブル、flex、grid、段組み、参照、named string。
  • 実験的: 明示的に有効化するページ内脚注とページフロート。これらの機能は警告を報告します。
  • 未対応: Node や CLI でのレンダリング、サーバー書き出し、PDF バイト、固定レイアウト EPUB、任意の CSS フラグメンテーション、ブラウザー間で同一のページ数。

構造的なページ分割の基準は Chromium です。Firefox と WebKit も公開 API とライフサイクルをサポートしますが、計測値と改行は異なることがあります。

次のステップ

On this page