章 1 · 部 I · 基礎
Postextの紹介
Postextとは何か、なぜ作られたのか、どんな問題を解決するのか
かんたんな説明
Postextは、本や雑誌、報告書のページをWebで組むための無料のソフトウェアです。印刷された本は何百年も前から、段の高さをそろえる、図をそれに触れている文章の近くに置く、といった細かな決まりに従って組まれてきました。Webページにはこうした決まりがなく、Postextがそれを加えます。文章を書けば、行も図も注も、Postextがページの上に置いてくれます。このページでは、このプロジェクトが生まれた理由といきさつを説明します。
Webのための、プログラムで動かせる組版エンジン。
美しく組まれた本を開いてみてください。文字がページにどう収まっているかがわかります。段の高さはきっちりそろい、画像は本文の流れの中に収まり、不自然なすき間も、段の頭に取り残された1行もありません。何でもないことのように見せるために、何百年もの技術が注がれてきました。
次にWebページを開いてみてください。よくできたページでも、感触が違います。文字は画像にぶつかり、段はあふれるか半分空いたままです。脚注は、参照している語句の近くにとどまらず、ページの一番下へ消えてしまいます。Webはレスポンシブなレイアウトをもたらしましたが、編集者の目で組むレイアウトはもたらしませんでした。
Postextはその差を埋めます。Postextは組版エンジンです。Markdownで書いた本文と、参照によって組み込む宣言済みのリソース(ビットマップ画像、SVGの図、表)を受け取り、プロの組版者と同じ規則を適用します。オーファンとウィドウの防止、段末そろえ、障害物を避けて流れる本文、意図をもった空き。出力は、HTMLとPDFの両方に使える、出版品質のレイアウトの幾何情報です。
土台は@chenglou/pretextです。DOMを使わずにテキストを測り、その速さがこれらすべてを可能にしています。
#印刷とWebのあいだの差
何百年ものあいだ、組版者は文章を読みやすくする規則に従ってきました。これは見た目の好みではありません。印刷された本、新聞、雑誌を何世代にもわたって作るなかで磨かれてきた、苦労して得た原則です。
- オーファンを出さない(段落の1行だけが段の頭に取り残されること)。
- ウィドウを出さない(段落の1行だけが段の末尾に残されること)。
- 段の高さをそろえる(見開きの各段の高さをほぼ等しくする)。
- 図、プルクオート、挿入画像を避けて本文を流す。
- 脚注は、参照している段の下部に正しく置く。
- 傍注は、それを引いている段落にそろえる。
- 見出し、引用ブロック、図のまわりの空きを、一貫して意図どおりに取る。
- リバー(語間の白い筋)や行末の極端な不ぞろいを避けるハイフネーション。
こうした規則のほかに、具体的に測れる2つの指標が、Webが印刷からどれだけ離れているかを示します。
- 行長。Bringhurstは、1段組みで1行45〜75字、段組みでは40〜50字を快適な範囲としています。アクセシビリティのガイドラインWCAG 1.4.8は上限を80字としています。多くのWebサイトでは行が100字、120字、あるいはそれ以上に伸びます。目が行を追いきれず、どこを読んでいたかを見失う長さを、はるかに超えています。
- 行送り。伝統的にはフォントサイズの1.3〜1.5倍が推奨され、WCAG 1.4.12は1.5倍以上でもコンテンツが機能し続けることを求めています。ただし適切な値は行長によって変わります。50字で読みやすい行送りも、90字では詰まって感じられます。組版者は両者を互いに合わせて調整しますが、CSSにはそれを自動で行う方法がありません。
そしてCSSはここで行き詰まります。使えるのはcolumn-countくらいで、ほかにはほとんどありません。リソースの配置は制御できず、あふれを把握する仕組みもなく、段をまたぐオーファンやウィドウの防止もなく、任意の障害物を避けて本文を流す標準の方法もありません。Webの段組みの編集的なレイアウトは今も手作りで、画面サイズが変わったとたんに崩れる静的なデザインのままです。
Webには10年以上前からレスポンシブなレイアウトがあります。flexbox、grid、どんな画面にも合わせるコンテナー。けれども、編集者の目で組むレスポンシブなレイアウトは一度もありませんでした。コンテンツが段をまたぎ、画像を避け、脚注を越えて賢く組み直され、文章を読みやすくする規則に従う、そういうレイアウトです。
#欠けていた一片を探した10年
Content Firstプロジェクトは2014年に、編集的なレイアウトの品質をWebにもたらす初期の試みとして始まりました。段組みのレイアウト、本文の流し込みの実験、次々に作られた試作品。そしていつも同じ壁に突き当たりました。 テキストがどれだけの場所を占めるかを正確に知らなければ、よいレイアウトの判断はできないのです。
単純に聞こえますが、これが問題のすべてです。ブラウザーに「この幅でこの段落の高さはいくつか」と尋ねるたびに、レイアウトの再計算(リフロー)がまるごと走ります。複雑な段組みの文書でそれを数百回行えば、ページは固まります。ブラウザーはこうした試行的な測定を想定して作られていません。最適な段幅を見つけるために10通りの幅を試す、段落をどこで分けるかを確かめる、画像がここに収まるか次の段へ移すべきかを調べる、といった測定です。
欠けていたのは、メインスレッドを止めずに、自由に試せるほど速くテキストを測る方法でした。10年のあいだ、そうした道具は存在しませんでした。
#欠けていた一片
2025年、Cheng LouがPretextを公開しました。DOMを使わないテキスト測定ライブラリーで、ブラウザーのリフローより300〜600倍速く、Chrome、Safari、Firefoxのどれでもピクセル単位で正確です。canvasのフォントメトリクスと純粋な算術だけで、DOMに一切触れずにテキストの高さと改行位置を計算します。
Pretextがあれば、この仕事を10年間阻んできたボトルネックは消えます。何千ものテキストブロックを数ミリ秒で測り、10通りの段の構成を試して最良のものを残し、ウィンドウのサイズが変わるたびに、メインスレッドを止めずにレイアウトのアルゴリズム全体を実行できます。
Postextは、その次に来るものです。
#Pretext + Postext
この名前は意図したものです。同じ作業の2つの半分を表しています。両者を分けておくことには意味があります。一方は測り、もう一方は決めるという別々の責任であり、測定を切り離しておけば、どのバックエンドも編集上の規則に縛られずにそれを使えます。
Pretextは、テキストを置く前に行うことです。どれだけの場所が必要かを測ります。DOMを使わず、canvasを使い、純粋な数値だけを扱います。
Postextは、測った後に行うことです。編集上の判断です。どの幅でも各テキストブロックの正確な寸法がわかれば、エンジンは各要素をどこに置くかを決めます。どの段の、どの位置に置き、どのリソースを避けて流し、どの組版規則に従うかです。
import { prepare, layout } from '@chenglou/pretext';
import { buildDocument, renderToCanvas, renderToHtml } from 'postext';
import { renderToPdf } from 'postext-pdf';
// pretext: measure (the "pre" work)
const prepared = prepare(paragraphText, '16px/1.5 Inter');
const { height } = layout(prepared, columnWidth, 24);
// => "This paragraph is 144px tall at this column width."
// postext: decide (the "post" work)
const vdt = buildDocument(content, config);
// => A complete Virtual Document Tree with every paragraph,
// heading, and resource placed at exact coordinates.
// One VDT, three output modes:
const canvases = renderToCanvas(vdt); // pixel-accurate bitmap per page
const html = renderToHtml(vdt); // selectable DOM for the web
const pdfBytes = await renderToPdf(vdt, { fontProvider }); // print-ready PDFPretextは寸法を与え、Postextはレイアウトを与えます。
PretextはCheng Louが作りました。Postextはその上に築かれています。
#しくみ
処理は3つの段階に分かれます。
-
コンテンツを用意する。Markdownで書いた本文と、宣言済みのリソース(ビットマップ画像、SVGの図、表)です。本文中の
:ref{id="..."}は、リソースに番号を振り、最初に参照された位置の近くで上端または下端の帯へフロートとして配置します。印刷の組版者が図を置くのと同じやり方です。コンテンツは純粋に意味だけを表し、何を示すかを書き、どう示すかは書きません。レイアウトの判断がソースに直接書き込まれることはありません。構文の全体は文書形式のリソースの節で説明しています。 -
エンジンが判断する。Postextはコンテンツを解析し、Pretextを呼んでDOMに触れずにピクセル単位で正確にテキストを測り、そのうえで複数パスのレイアウト処理を実行します。段末そろえ、リソースの番号付けとフロート配置、ウィドウとオーファンの防止、ベースラインの整列、空きの調整です。すべての判断は設定によって決まります。ページとレイアウトの幾何、本文と見出し、さらに表のセルの文字組みを決める
tableStyle、図のキャプションを決めるcaptionStyle、そしてdiagramStyleのsingleInkです。これは特色1色の印刷に向けて、SVGの図を輝度に応じた1色のインクの濃淡に塗り替えます。規則を決めるのはあなたで、エンジンはそれを適用します。 -
完成したレイアウトを受け取る。すべてのページのすべての要素について、正確な座標と寸法が得られます。レンダラーはこの幾何情報を目的の形式に変換します。ピクセル単位で正確なビットマップのプレビューにはcanvas(
renderToCanvas、renderPage)、Webで選択でき、サイズ変更に追従する文字組みにはHTML(renderToHtml、renderToHtmlIndexed)、フォントを埋め込んだ印刷用の出力にはPDF(postext-pdfパッケージのrenderToPdf)を使います。同じコンテンツ、同じ規則から、入れ替え可能な3つの出力が得られます。
エンジンの内部、つまり仮想文書ツリー(Virtual Document Tree)、複数パスの処理、収束ループについて詳しくはアーキテクチャーを参照してください。ページの幾何から表、キャプション、図のスタイルまで、すべての設定項目のリファレンスは設定のページにあります。すべてをその場で試すにはSandbox(ブラウザーで動く編集環境)を開いてください。章のテキストエディター、表エディターと画像/SVGのアップロードを備えた リソースパネル、すべての設定を編集の言葉で見て回れるデザインパネル、そしてcanvas、HTML、PDFのライブプレビューがあります。
#謝辞
Pretext(Cheng Lou)。Postextを可能にした、テキスト測定の基盤となるライブラリーです。DOMを使わず、ピクセル単位で正確な測定を1ミリ秒未満で行えなければ、このどれも実用にはなりませんでした。
Content First(2014年ごろ)。Webで質の高い編集的なレイアウトを実現しようとした最初の探究です。10年にわたって壁にぶつかり、何がうまくいかないかを学び、この問題には本当の解決策が必要だという確信を育てました。
Postextは何百年もの組版の伝統の上に立っています。Postextが実装する規則は新しく考え出したものではありません。画面が生まれるはるか前に、文章を読みやすくする技を磨いてきた組版者、タイポグラファー、デザイナーの仕事から受け継いだものです。Gutenbergの活版印刷からTschicholdの非対称タイポグラフィ、Bringhurstの『Elements of Typographic Style』まで、ページに文字を配置する技術は500年以上にわたって発展してきました。Postextは、その積み重ねてきた知恵を、これまで目立って欠けていたWebへと届けます。