この本文は日本語版の組版見本です。構成は Markit リポジトリにある簡体中文の原版と一対一で対応し、配色と組版ルールはアプリと同じ出どころです。

組版とは引き算である

このページは Markit の組版見本です。ここには二つの役割が同居しています。ふつうに読み通せる一篇の文章であること、そしてエディタが対応する Markdown 記法をすべて並べた検査表であること。どちらか一方では意味がありません——記法を積み上げただけの見本は目を欺けず、行間のゆるみや約物の詰まり、和欧混植の継ぎ目のぎこちなさは、本物の長文の中でしか露呈しないからです。

組版の判断基準は「きれいかどうか」ではなく、「千字を読み終えたあと目が疲れていないか」。当たり前に聞こえますが、この基準は見栄えのよい案の大半を退けます。

紙面の第一原則：まず引くこと

エディタの画面で本当に内容に属するものは、文字そのものだけです。残りのすべて——ツールバー、サイドバー、ボタン、状態表示——は内容と注意を奪い合っています。だから最初の規則はこうなります：既定の状態では、界面の要素は見えないか、視線の端に退くかのどちらかであること。

数字にすると：

要素	値	理由
版面の幅	720 px	全角およそ 40 字，紙の本の一行に近い
本文の行送り	1.55	漢字と仮名は字面が密で，1.5 では窮屈
見出しの階層	三段	それ以上増やすと階層は当てずっぽうになる
強調色の面積	≤ 5%	この割合を超えた強調は，もう強調ではない

表の数字は等幅数字で揃えています。小さなことですが、桁が左右に揺れる列は、読者を「理解」ではなく「見比べ」に追いやります。

罫線よりも余白が組を作る

内容を罫線で区切るのは初学者のやり方で、余白で区切るのが成熟したやり方です。罫線は紙面に硬い縁を残しますが、余白は姿を見せません：

段落のあいだは 16 px。文がまとまりを作る
小見出しの上に 24 px、下に 8 px——上を締め、下を緩めることで見出しが受け持つ本文に密着する
大見出しの上は 40 px。視線が自然にひと呼吸置く

この段階づけられた余白がひとたび均されると——たとえば一律の margin 規則に上書きされると——紙面はたちまち等間隔の段落の列に退化し、階層は文字サイズだけが支えることになります。この故障は静かです。宣言はコードに残ったままで、一見なにも壊れていません。

フォント：和文と欧文は別の仕事

CSS のフォント代替は一文字ずつ行われます。つまりスタックの順序が、欧文を誰が描くかを決めます。和文フォントを先頭に置けば、camelCase も、バージョン番号 v1.522 も、あらゆるラテン文字も、和文フォントに同梱のおまけの欧文字形に落ちます。

正しい書き方は欧文が先、和文が後です：

font-family: Charter, 'LXGW WenKai', -apple-system, 'Hiragino Mincho ProN', sans-serif;

どちらの順序でも「動く」のがこの規則の厄介なところです。差は字形にしか現れず、コードレビューでは捕まらない——だからテストが見張るしかありません。

反例をひとつ

下のコードは踏みやすい穴を二つ同時に踏んでいます——和文フォントを先頭に置き、そのうえ合成イタリックを使う：

// ⚠️ 二箇所とも誤り
const stack = "'Hiragino Sans', Charter, sans-serif"  // 和文が先頭：欧文の字形が制御不能
const emphasis = { fontStyle: 'italic' }              // 和文にイタリックの伝統はない

和文の強調の伝統は圏点（文字の傍らに打つ点）であって、方塊の字を斜めに倒すことではありません。合成斜体は画の交差部を潰し、サイズが小さいほど目立ちます。

合成ボールドも同じ系統の問題です。真のボールド字面を持たないフォントでは、ブラウザが輪郭を太らせるため、縦画と横画の太さの関係が壊れます。

記法の検査表

残りの記法をひととおり通し、このスタイルの下で互いに喧嘩しないことを確かめます。

行内の要素

本文には太字、強調、~~取り消し線~~、行内コード、そして外部リンクが現れます。自動認識される URL も同様です：https://example.com 。これらが同じ段落に混ざるとき、最初に壊れるのは行送りです——余分な padding を持つ行内要素がひとつあるだけで、その行はこじ開けられます。

タグはメタ情報であって本文の主役ではないので、彩度を落とした錠剤形にしています。色つきタグの壁にはしません：#組版 #フォント #工芸

引用とコールアウト

よい文章は、よい紙面に値する。

組版の目的は文字を美しくすることではなく、読者に紙面の存在を忘れさせることにある。

五種のコールアウトにはそれぞれの声があります。作者が選ぶ意味であって、界面が足す飾りではありません：

長文の読書には明朝体かゴシック体が目にやさしく、楷書体は随筆や短文に向きます。

ディスク上の .md ファイルだけが真実です。いかなる組版効果も、生きられるのは描画層の中だけです。

入力の最中にユーザーの本文へ手を入れてはいけません。自動挿入された空白は、次の自動保存でディスクに書かれてしまいます。

コードブロック

コードブロックは版面を突き破らず横にスクロールすべきで、配色も抑えます——キーワードは強調色、コメントは灰色に退き、残りは本文色。虹色のハイライトは、あたたかい紙の上では騒がしすぎます：

/// 現在の書類を Finder で表示する
@objc private func revealInFinder(_ sender: Any?) {
    guard let url = session.url else { return }
    NSWorkspace.shared.activateFileViewerSelecting([url])
}

長い一行は折り返さず、スクロールさせます：

curl -sSL "https://raw.githubusercontent.com/example/repo/main/very/long/path/to/some/file.txt" -o output.txt

画像

組版の見取り図

画像の直後に説明文が続くときは、両者の間隔をふつうの段落間より詰めます。そうして初めて、読者はそれらをひと組として見ます。

むすび

上の罫線は、罫線の正当な使い所です。段落のあいだの呼吸ではなく、「本文が終わり、結びが始まる」という本当の断絶を印している。使う回数が少ないほど、その一度に力が宿ります。

組版の案が成立しているかどうかの判定は、結局ひとつしかありません。このページを頭から終わりまで読んで、紙面そのものに気づいて立ち止まった箇所があったか。あったなら、そこがまだ直すべき場所です。