構成のサンプル

examples/ 以下に、実際に動く小さな Go サーバーが 4 つあります。はじめの 3 つは同じトレードオフの上に立っていて、選ぶ点が違うだけです——サーバーがあらかじめどこまで変換しておくか、文書を実際に開いたときにブラウザがどこまでするか。3 つとも examples/sample-files/ の同じ 6 ファイルを配信し、小さな埋め込みビューア examples/miniviewer（ブラウザ側で説明）を共有しています。

4 つ目の secure-reader は、だれが読めるかの話です。読者はログインし、本は保護モードで、10 ページずつ、その要求のために作った鍵で封印して送ります。

どれが「正解」というものではありません。なぜ BDF かを読み、実際に作るものに合わせて選んでください: ある文書がどれくらいの頻度で開かれ、どれくらいの頻度で変わるか、サーバーに変換の余力があるか、検索できる必要があるか、といった観点です。

light-server

サーバーは何も変換しません。文書ごとに 1 度だけサムネイルを描き（そのためだけにメモリ上で変換し、結果は捨てます）、元のファイルをそのまま配信します。開くとブラウザの中で BDF に変換します。使うのはデモサイト自身が配っているのと同じ wasm の変換モジュールです。これはサーバーの負担が一番小さい構成です（リクエストのたびに変換コードが動くことはありません）。代わりに、ブラウザは wasm モジュールを一度取得し、開くたびに手元で変換する時間がかかります。監査のための記録のように、大量に作られるが開かれるのはまれな文書に向いています。→ 詳しく読む

preview-server

逆のトレードオフです。サーバーがすべての文書をあらかじめ 1 度 BDF に変換し、キャッシュします。文書を開くのはキャッシュ済みの BDF を取得するだけです（net/http の ServeContent が Range リクエストに自分で応えるので、表示中のページに要る部分だけしか転送しません）。ブラウザ側のフロントは変換器を持たず、レンダラだけです。文書はより速く、より一定した時間で開きますが、サーバーに変換の余力と結果を置く場所が要ります。→ 詳しく読む

search

preview-server のサーバー側変換の上に、検索インデックスを足したものです。各ページのテキスト（Document.SearchText）をページごとに 1 件として Meilisearch に入れ、/search がクエリを Meilisearch に取り次ぎます。検索結果をクリックすると、見つかったページをそのまま開きます。→ 詳しく読む

secure-reader

読者がログインして、自分の持っている PDF の本を読みます。本はファイルとしては送りません。サーバーは本を 1 度だけ変換し、保護モードで 10 ページずつ渡します（segment パッケージ）。区間はどれも、ブラウザがその要求のためだけに作った鍵ペアに封印するので、後で鍵やセッションが漏れても、記録された通信は開けません。持っていない本は先頭 10 ページを立ち読みでき、人が読むより速くはだれも読めません。→ 詳しく読む