コンテナ内のVivliostyleのプレビューをWebページ化してコンテナの外から確認する

Vivliostyleの組版処理はクライアントサイドJavaScriptであり、Webブラウザを動作させるOSの影響を受けます。実際に以下のような差が発生すると報告されています。これらは個別にはChromiumのバグやフォントファイルの不具合と言えるものですが、Webブラウザの組版処理にOSごとの分岐が存在し、特に複雑ではない制作でも遭遇しうることが伝われば十分です。

Chromiumブラウザの場合、テキストのレンダリングがOSによって異なり、特にLinux環境では、テキストノードの境界ごとに幅がわずかに増加する現象があります。 — vivliostyle/vivliostyle.js#1590

OS/2.fsSelectionのUSE_TYPO_METRICSビット（bit 7）が立っているフォントは全プラットフォームがsTypo*を使用しますが、立っていない場合のフォールバック先がプラットフォームごとに分かれます。 — Webページで一部フォントの位置がOS依存になる問題に対処する #CSS - Qiita

したがって、共同作業者の環境を統一することが現実的でない場合に全員の手元で同じPDFを出力するには、Vivliostyleやブラウザのバージョン固定では不十分です。また一人で制作する場合にも、将来再度作業する際に元と同じ環境を用意できるとは限りません。同人誌ならともかく、商業出版物のようなシビアな用途で組版の再現性を確保するためには、少なくともビルドにはコンテナを用いる必要があります¹²。

ところで、Vivliostyleにはライブプレビュー機能があります。DevToolsでCSSの効果をインタラクティブに確認しながらスタイルを作成したり、ページに内容を収めるために文章や図版の調整を探ることが可能であり、これはTeX系では弱いVivliostyleの利点のひとつです。

しかしビルドにコンテナを用いる場合、プレビューもコンテナ内のブラウザの出力を確認したいということになります。これは少し面倒です。ホストがLinuxだけならX11転送でよいのですが、MacではXQuartzなどのセットアップが必要です³⁴。そこで、ホスト側からWebページとしてコンテナ内のブラウザを確認できるセットアップを考案し、直近の制作に投入しました。

u1f992/vivliostyle-preview-in-container

Vivliostyle CLI（v10.5.0）にはDockerを用いるモードが用意されていますが、今回は使用しません。このセットアップでは、コンテナ内でnoVNCをサーブし、ホスト側のWebブラウザからはそのページにアクセスします。通常のvivliostyle previewと近い使い勝手で、コンテナ内で行える安定した組版のプレビューが可能です。

scripts/preview.sh

DEBIAN_FRONTEND=noninteractive apt-get install -qq --yes --no-install-recommends \
  matchbox-window-manager=1.2.2+git20200512-2 \
  novnc=1:1.6.0-2 \
  supervisor=4.2.5-3 \
  tigervnc-standalone-server=1.15.0+dfsg-2 \
  >/dev/null

ブラウザ内でブラウザのウィンドウが表示されている珍しい状態になります。内側のブラウザを全画面表示にすればあたかもWebページのように見せることもできます⁵。

コンテナでPDFを出力することで、特別な考慮をせずにCIで信頼できるPDFを出力できる別のメリットもあります。サンプルリポジトリでもセットアップしています。

.github/workflows/release.yaml

- name: Build PDF
  run: docker run --rm --volume .:/workdir --workdir /workdir --user root --entrypoint bash --tty ghcr.io/vivliostyle/cli:10.5.0 scripts/build.sh

1. 素朴に考えれば組版に関わる処理はコンテナで固定できるユーザー空間に収まるはずですが、理論上はカーネルやCPUアーキテクチャによる差異があるかもしれません。厳密な回答としては、すべてのハードウェアをソフトウェアエミュレーションする必要があるのでしょう。ここではそこまでは考えていません。 ↩

2. 「すべてのリソースをリポジトリにコピーして、リモートリソースを参照しない」などは再現性以前の問題です。なおここには再配布が可能なフォント≒オープンソースのフォントだけが使用できるという前提があります。GitHubなどソースコードを公開するためのプラットフォーム上で、オープンソースの組版ソフトを用いて制作するなら、当然リソースもオープンソースに寄せなければ歪みが発生するというのが予てからの筆者の主張です。 ↩

3. 十分新しいWindowsではWSLgがうまくやります。Dockerの導入の前提としてセットアップされているはずなので、VcXsrvなどは不要です。意外にもMacより簡単に済みそうです。 ↩

4. Dockerを導入している時点で十分複雑であり、Xサーバーのインストールが今さら何だという異論はあると思います。 ↩

5. 実制作では自動で全画面になるようにしていたのですが、複雑になるばかりでメリットが限定的、単に手動で行えば事足りることなので勧めません。 ↩