このページはAIの支援を受けて翻訳されました。正文は英語の原文です。
幅は、文字の軸の中で最も静かな存在です。読者が意識的に気づくことはめったにありませんが、判読性が依存する2つの資源 — 文字の内側のカウンターの空間と、1行に収まる文字数 — を支配しています。2005年の知見は、レギュラーからやや狭めの幅が最も判読しやすいというものでした。エクステンデッドの書体は字形を容易な認識の範囲を超えて引き伸ばし、強くコンデンスされた書体は、eとc、oを区別するカウンターを詰まらせます。この知見はよく持ちこたえています。変わったのは機構です。幅はもはやフォントファイルの固定された属性ではなく、連続的でスクリプトから制御できるデザインの軸なのです。
2005年から変わったこと
2005年には、「コンデンス」フォントは、そもそも存在するとしても別のファイルであり、ウェブデザイナーの多くはそれを使うためのフォントも配信手段も持っていませんでした。2つの発展がこれを一変させました。ウェブフォントの配信(2010年頃からの現代的な @font-face の時代)は、本物のコンデンスとエクステンデッドのカットを利用可能にしました。次いでOpenTypeバリアブルフォント(2016年以降)が wdth を標準の軸として登録し、CSSでは font-stretch — 現在は正式に font-width という別名を持ちます — を通じて公開されました。condensed(75%)や semi-condensed(87.5%)といったキーワード値、または対応するフォントでは任意のパーセンテージが使えます。
設計された幅の軸の決定的な特性は、それがスケーリングではないことです。バリアブルフォントが wdth に沿って狭まるとき、デザイナーの補間は縦のストロークの太さを一定に保ち、ジオメトリの許す限りカウンターを開いたまま維持し、字間を組み直します。水平スケーリング — transform: scaleX(0.8) やその祖先たち — は正反対のことをします。縦のストロークを横に対して細らせ、曲線を歪め、字間を比例的に圧縮します。真のコンデンスと疑似コンデンスの違いは、まさに真のイタリックとせん断されたローマン体の違いであり、同じロービジョンの読者にとって重要です。
第二の変化は概念的なものです。レスポンシブデザインは、ユーザーが実際に体験する変数はフォントの選択ではなく行長であることを教えてくれました — そして幅は、いまやそれを管理する道具です。狭いビューポートでぎこちなく折り返される見出しは、読めるサイズを下回るまで縮小する代わりに、幅を数ユニット絞ることができます。これは正真正銘の新しい能力であり、正真正銘の新しい失敗の仕方も伴います。
幅とカウンターの予算
第1版の判読性の力学は、今もこのトレードオフを正しく記述しています。エクステンデッドの幅は、識別のための情報を加えることなく字形を水平方向に拡大します。読書サイズでは認識をわずかに遅らせ、行送りの幅を浪費します。強くコンデンスされた幅はカウンターを閉じさせ、混同しやすいペアの間の空間的な差を減らします — きついコンデンスでは o、e、c が似通い、minimum のような単語の縦線のリズムは杭の柵になります。
連続したテキストにとって、安全な帯域は依然として狭いままです。おおよそ通常幅の90%から100% — ノーマルからセミコンデンスの手前まで。コンデンス以下のカットはディスプレイ用の道具です — 見出し、ラベル、そして設計されたコンデンスが縮小されたレギュラーに本当に勝る、データ密度の高い表。エクステンデッドの幅はブランディングの道具です。どちらも段落には属しません。
ウエイトは幅と相互作用します。太字の書体をコンデンスすることは、カウンターを二重に閉じさせます。どうしてもコンデンスするなら、レギュラー以下のウエイトにとどめてください。サイズも相互作用します。40pxの見出しサイズで機能する幅が何であれ、16pxの本文サイズでは緩める必要があります。バリアブルフォントの中には wdth をオプティカルサイズ軸(opsz)と組み合わせて、これを部分的に管理してくれるものもありますが、大半はあなたに委ねられています。
ズーム、拡大、そしてロービジョン
ゆとりのある幅を最も必要とする人々は、最悪の条件でコンデンスされた文字に出会う可能性が最も高い人々でもあります。画面拡大鏡のユーザーは、拡大されたページの小さな窓を覗いています。拡大されたコンデンス書体は、行全体という補いの文脈なしに、その閉じたカウンターと詰まった字間をさらけ出します。ブラウザーズームを200%で使う読者 — WCAG 2.2のテキストのサイズ変更基準(1.4.4)がコンテンツに耐えることを要求するレベル — は、あなたの狭いビューポート向けレイアウトを発動させます。そしてそこはまさに、デザイナーが収まりをよくするために文字をコンデンスしたくなる場所なのです。
本文についてはその誘惑に抗ってください。レイアウトが字形を圧縮することでしか200%ズームで機能しないなら、問題はレイアウトのほうです。WCAG 1.4.10(リフロー)が正しい方向を指し示しています。コンテンツは圧縮されるのではなく、単一のカラムにリフローすべきです。リフロー下での見出しの幅の調整は正当ですが、段落に適用されたら危険信号です。
テキストスペーシングへの適応もここで重要です。WCAG 1.4.12は、ユーザーが字間と語間を広げてもコンテンツが壊れないことを要求しています。詰まった字間に依存するコンデンス書体は、ロービジョンのユーザーが letter-spacing を加えると視覚的に崩壊しがちです — 連続したテキストを通常幅の近くに保つべきもうひとつの理由です。そこでは字間の追加も穏やかに劣化します。
疑似コンデンスを避ける
疑似コンデンスは、世の中に3つの形で生き残っています。テキストへのCSSトランスフォーム、幅の軸を持たないフォントへのレガシーな font-stretch(ブラウザーは正しく無視しますが、デザイナーがときにトランスフォームで「修正」してしまいます)、そしてSVGやcanvasのテキストの非一様なスケーリングです。3つとも、いかなるタイプデザイナーも承認していない、縦線が細る歪みを生み出します。デザインが本当に狭い文字を必要とするなら、選択肢はこうです。本物の wdth 軸を持つバリアブルフォント、別に設計されたコンデンスのカット、あるいは別のレイアウト。読者を尊重する第四の選択肢は存在しません。
wdth 軸を使うときは、生の font-variation-settings よりも高水準の font-stretch/font-width プロパティを優先してください。ブラウザーが継承とフォールバックを賢く管理できるようになります。そしてフォールバックを検証してください。バリアブルフォントの読み込みに失敗したシステムでは、フォールバックスタックへのコンデンスの要求は、合成された圧縮ではなく通常幅へと退化すべきです。
CSSでは
/* Width belongs to the wdth axis — never to transforms */
body { font-stretch: 100%; }
.compact-table { font-stretch: 92%; } /* slightly condensed floor */
/* Anti-pattern — distorts stroke contrast and spacing:
.squeezed { transform: scaleX(0.8); } */推奨事項
- 連続したテキストはおおよそ通常幅の90%から100%の間に保つこと。2005年の知見は有効です。
- 設計されたコンデンスのカットは、見出し、ラベル、スペースが決定的なディスプレイ用途のために取っておくこと。エクステンデッドのカットはブランディング用に。
- 幅を決して偽造しないこと。scaleX トランスフォームも、SVGやcanvasでのテキストの非一様なスケーリングも禁物です。
- バリアブルの wdth 軸は font-stretch(font-width)経由で使い、フォントの読み込みに失敗したときの穏やかなフォールバックを確認すること。
- 200%ズームや狭いビューポートを乗り切るために本文をコンデンスしないこと — WCAG 1.4.10に従い、代わりにリフローさせること。
- ユーザーが字間と語間を広げたときにテキストが無傷であることを検証すること(WCAG 1.4.12)。詰まったコンデンスの組版は、たいていこれに最初に失敗します。
- コンデンスの幅を太字のウエイトや小さなサイズと組み合わせないこと。カウンターの予算はそこまで伸びません。