Glyphs 自動勉強会 Vol. 14

https://scrapbox.io/files/69a010e9f1c53c173217cbb3.jpg

テーマ: ヒンティング・ラスタライザー

2026. 2. 28 20:00–

Glyphsの自動勉強会です。Glyphsのみならず、文字に関することならなんでもOK。勉強会といっても堅苦しいものではなく、気軽に色々話せたらと思います。

自動勉強会について

雑談とセミナーの間みたいな感じ

ネタを集めておいて、参加者が三人以上でやったら開催

隔月1回くらいの頻度でやっていきたい

毎回Youtubeでライブ配信、終わったら自動でアーカイブが生成

参加資格

文字に興味がある方なら誰でもOKです！

むしろ、色々質問してくれると嬉しいです

参加方法、ルール

GlyphsユーザーDiscord “Spur into Glyphs Club” に入ってください

もしくは、直前に@wolphtypeがつぶやくYoutubeライブをご視聴ください

進行は今後他の人にお願いするかもしれません

Youtubeのコメントや、Discordのauto-studyroomチャンネルで話すのもOK

聞き専が良い方はマイクをミュートにしてください。

Scrapboxも好きにいじってください！Discord・Youtubeでのコメントも自由に。

スライドは用意せず、下の項目に従って話しながら進めていきます。適宜Webサイトを参照したりGlyphsを画面共有したり。

目次に加筆した方は、自分のアイコンをつけてもらえると助かります。

目次（自由に追加してください）

最近書体界隈であったこと、近々あること

大曲さんがBubbleKern Revisitedでトーク予定

お知らせ・宣伝

用語や英文中の単語の和訳

TT, TTF: TrueType, TrueTypeフォント。Quadratic（二次）ベジェ曲線

PS: PostScript。Cubic（三次）ベジェ曲線

Instruction: 命令

Interpolate: 補完

PPM, ppem: 全角あたりのピクセル数。たとえば、12PPMならば 1000UPMの場合1000ユニットが12ピクセルで表示されるということ。その場合、1ピクセルあたりのユニット数は1000/12で大体83ユニットとなる。

ヒンティングとは

TrueType、PostScriptフォントをスクリーンで表示する際、可読性を上げるために変形し、最適化すること。

具体的には、デザインされたアウトラインをモニターのピクセルに変換する際に、フォントのラスタライぜーションを微調整する命令をプログラムする。

フォントの大文字および小文字の高さや幅を規定したり、線の太さや文字の周囲のホワイトスペース、大文字のステムが小文字のステムと違う太さになるフォントサイズの閾値、イタリックの角度をどうピクセルグリッドにフィットさせるか…などをPPM単位でコントロールできる。

しばしば、「小サイズでも書体デザインのディティールを保持すること」と勘違いされるが、実際には低解像度でも可読性を高めるために字形を変形すること。

必要なフォント、すなわち標準的なスタイルで小サイズでの可読性を重要視しているフォントのみ行うべきであり、グランジやディスプレイフォント、スクリプトフォントなどでは行うべきではない。

ヒンティングの歴史

ビットマップフォント

アウトラインフォント付属の手打ちビットマップ

ジョン・ワーノック「ビットマップはアウトラインから自動生成できないか？」

ヒンティングの基本的な考え方

同じ太さのものを同じピクセル数で表示したい

同じ高さのものを揃えたい

→ステムなどをマーキング（命令）して、レンダリングエンジン、ラスタライザーにいい感じに表示してもらう

ラスタライザー、時代ごとのヒンティング（ざっくり）

ラスタライザーとは

フォントの数学的なアウトラインデータを、実際のスクリーン上のピクセルに変換するソフトウェアのこと。

どのようにフォントをグリッド（ピクセル）にフィットさせるか、アンチエイリアスをかけるかといった判断をする。

OSなどで異なるラスタライザーを積んでいる。また、同じラスタライザーでも異なるモードを持っていたりする。

Mac (Apple) vs Windows (Microsoft)

Microsoftのラスタライザーは文字をピクセルグリッドに揃えようとする。そのため、Regularは細く、Boldは太く見え、小さいサイズではディティールが失われる。

Appleのラスタライザーは忠実に書体のデザインを保とうとするが、鮮明さが失われることがある。

WindowsのラスタライザーはちゃんとヒンティングされたTrueTypeフォントでは良い描画を行うが、そうでなければ最適とは言えない結果になってしまう。Macはヒンティングを無視するため、すべてのフォントや形式で良い描画をする。

Quartz (Mac)

Macの描画コアエンジン。2Dレンダリングを行うのはQuartz 2DというAPI。

PDFを内部イメージングモデルとしている。

NeXTのDPSの後継。

MacOS X初期から10.13 High Sierraまでサブピクセルレンダリングを使用していたが、10.14 Mojaveから無効化された。

白黒2値ヒンティング、1bit、グリッドフィッティング

ピクセルのオンとオフ、白と黒しか表示できない

表示されるサイズごとにピクセルにどうフィットさせるかをコントロールする。

こう言った種類のヒンティングはグリッドフィッティングと呼ばれる。

Typothequeの記事曰く、もっとも時間のかかるヒンティングの手法で、経験者のヒンターでも256文字の1フォントに最低80時間かかっていた。（もちろんキャラクターセットが大きかったりスタイルが多ければその分時間がかかる）

可読性を高めるために文字間に白ピクセルを挿入することも多く、印刷されたテキストとスクリーン上のテキストで長さが変わることも。

MicrosoftのVerdana, Georgiaなどが例

参考画像（Typothequeより）

200%拡大、15ppem、ヒンティングなし

https://scrapbox.io/files/6970a5266855752e1e29c86f.webp

200%拡大、15ppem、ヒンティングあり

https://scrapbox.io/files/6970a56a32ade87c5bc2c5d0.webp

グレースケールレンダリングのヒンティング、4bit（16階調）もしくは8bit（256階調）、縦横のアンチエイリアス

アンチエイリアスはWindows98ごろに取り入れられ、文字のギザギザになっている部分をグレーの濃淡でスムーズにする。

ラスタライザーはアンチエイリアスを行うか、グリッドフィッティングどちらにするかを選ぶことができる。

文字は縦方向と横方向どちらにもアンチエイリアスがかかるが、命令の数はグリッドフィッティングより少ない。

白黒2値と同様の手間がかかり、256文字の1フォントに大体72時間ほどかかった。

90年代のブラウン管モニターには最適。

1ピクセルを縦横両方で4倍にオーバーサンプリングする。すなわちピクセルを16分割する。

それらのピクセルの中心がどれだけアウトラインの内側に重なっているかによって、ピクセルの濃度が決定される。

参考画像（Typothequeより）

200%拡大、10ppem、ヒンティングなし

200%拡大、10ppem、ヒンティングあり

https://scrapbox.io/files/697736f47c91700633c12ea6.webp

ClearType（水平方向のみ）

Windows XPから使われるようになった方式、サブピクセルレンダリングを行う。

モニターにおけるテキストを、ピクセルを構成するRGBの3色を別々にコントロールし、その濃淡でより高解像度に見えるようになっている。

実質的には文字の解像度は3倍高くなるとされる。ただし水平方向限定。

水平方向のステム、横棒は常にピクセル単位で表示され、場合によっては非常に細い横ストロークが太く見えてしまう。

また、水平からやや傾いたストロークや曲線が非常にカクカクして見えてしまう問題がある。

スマートフォンやタブレットといった回転するデバイスにも対応ができない。

横軸のみの調整になるため、作業時間は半分になった。256文字の1フォントに40時間ほど。

8x1でオーパーサンプリングを行い、横方向は8分割するが、縦方向は分割されない。

参考画像（Typothequeより）

200%拡大、15ppem、ヒンティングなし

https://scrapbox.io/files/6989a9014994d753be2784d6.webp

200%拡大、15ppem、ヒンティングあり

https://scrapbox.io/files/6989a90ab1fe698e0943cdcf.webp

DirectWrite（水平垂直）

Windows 7から使われるようになった方式。

ClearType同様のサブピクセルレンダリングだが、縦にもアンチエイリアスがかかるようになった。

ヒンティングの手法はClearType同様。

5x5でオーバーサンプリングを行う。

カーブの見え方はClearTypeより改善されており、PostScriptのOpenTypeフォントのレンダリングも改善された。

参考画像

200%、15ppem、ヒンティングなし

https://scrapbox.io/files/6989aa7c4cae4c2d707c7c98.webp

200%、15ppem、ヒンティングあり

https://scrapbox.io/files/6989aa7f50a2d0c7d568055c.webp

31ピクセルのヒンティングされているClearTypeとDirectWriteの比較。カーブが滑らかになっているのがわかる

https://scrapbox.io/files/6989aa8bd869c603900e39ec.webp

https://scrapbox.io/files/6989aa8c9813a7aa48a14f35.webp

CoolType (Adobe)

Adobe独自のフォントレンダリング技術で、OSに依存しないドキュメント表示を目指す。

Acrobat, Photoshop, InDesign, Illustratorなどに内蔵。

オープンソースのフォントラスタライザー。

オートヒンターを持っており、フォントにヒントがなくても実行時にフォントを解析し自動でヒンティングを行う。

Linux, Android, iOS, ChromeOSなどが使っている。

テキストのシェービング（文字列のOT機能などを用いたレイアウト）はHarfBuzzなどがやる（はず）

ヒンティングのやり方

PostScript vs TrueType

PostScriptでは重要なステムとゾーンを指定し、レンダリングの大部分をラスタライザーに任せる。そのため、ヒンティングがない状態やシンプルなヒンティングでもよく見えやすい。

TrueTypeではフォントに含まれた大量のヒンティング、命令によってラスタライザーがコントロールされる。そのため、ヒンティング情報なしには綺麗に表示されない。

そのため、PostScriptは製作者への負担が少なめ、TrueTypeは細かく指定できる分大変

PostScriptはオートヒントとマニュアルヒントが共存できるが、TrueTypeでは共存できず、どちらか一方しか選べない

ヒンティングの確認方法

ウォーターフォール（同じ文字列が異なるサイズで表示されるレイアウト）で確認すると良い。

WindowsのブラウザとWordなどで確認する（それぞれでレンダリング方法が違う）。FontDropなどはウォーターフォールを表示できる。

Macの場合Virtual BoxやParallelsを使うなど。

Macではアクセシビリティの設定よりCtrl+スクロールで画面全体の拡大縮小ができ、それで確認可能。

PostScriptヒンティング

グリフにおける重要なステム（縦だけでなく横も）をヒントとして命令することで、ラスタライザーがそれらを優先的にピクセルに表示するようになる。

ステムの見え方と、バーティカルメトリクス（ゾーン）の見え方を一貫させることを狙っている。

字幅を考慮しないため、同じ文字でも異なる幅になることもある。

https://glyphsapp.com/media/pages/learn/hinting-postscript-autohinting/8a5b696f25-1624987024/n-width-1280x-q80.webp

オートヒントとマニュアルヒントが共存可能。

基本はオートヒントに任せ、テストの段階でうまくいかないものはマニュアルでヒントするのが良い。

いくつか下準備が必要。

パスの方向が正しいこと。パス方向を修正（Cmd+Shift+R）で修正可能。

極点が必ず必要。極点を追加を使うか、ペンツールでShift+クリック

アウトラインが複雑でなく、バーティカルメトリクスやオーバーシュート、ステム幅が一貫している

オートヒントのやり方

フォント情報>マスターで、各マスターの縦と横のステムの太さを入力する。

近似の値は統合し、縦と横それぞれ2つ程度に絞ると良い。可能なら1つに。振れ幅が多い場合は3つも許容

最初に入力されたものが優先されるため、小文字のステムなどが良い

アラインメントゾーンを入力する。

低解像度でオーバーシュートのある/ない文字を同じ高さに揃えるため。

位置とサイズを入力していく。位置は平坦な部分（例: x）、サイズはオーバーシュートの最大値（例: o）。

サイズは最大でも25ユニットあたりがよく、小さく絞れるなら絞る。

アラインメントゾーンが重ならないようにする。1ユニットの隙間が最低でも必要。

小数点を扱う場合は1ずつ広げる。

書き出しの際に「オートヒント」にチェックを入れて書き出せばOK。

マニュアルヒントのやり方

オートヒントをチェックし、マニュアルヒントが必要そうなものを見つけたら場合に行う。

水平ステムの場合は上下の極点、垂直ステムの場合は左右の極点を選択し、コンテキストメニューから「水平ヒントを追加/垂直ヒントを追加」

グリフによっては、アラインメントゾーンに接触するものの水平方向の要素がない文字も存在する（I, Lの上端など）。そういった文字には「ゴーストヒント」を追加する。

上下端のポイントを選択し、「水平ヒントを追加」を行う。

マルチプルマスターの場合は基本のマスターのみで良い。

Family Alignment Zone

ウェイト間でxハイトが異なる場合、低解像度ではxハイトを揃える設定。フォント全体に対してのカスタムパラメータとして追加できる。

TrueTypeヒンティング

blueScale

blueShift

blueFuzz

Q&A

ヒンティングが必要な場面は？

小さいサイズ、低解像度 (–24px)

古いパソコンでは当たり前だったが、今は…？

ヒンティングはなくなると言われ続けているが、そろそろ本当にいらないかも

バスの電光掲示板とか（やすいので）使われることはあるが、大体専用のドットフォント

和文にヒンティングは必要？

メイリオくらい？

Osakaとかはピクセルだがそもそもビットマップ

新製品に必要かと言われると、あまりなさそう クライアントに言われない限り

ヒンティングは無いよりマシ？

無いよりはマシだが、下手なヒントだとヒンティングなしより汚くなることも…

わからないならオートヒントでも無い方が良いかも

フォントの複雑さによる（グランジ、スクリプト、ディスプレイ）

オートヒントはどのくらい使える？

構造がシンプルならばちゃんと機能する、そういった書体こそ可読性が求められるので良い

セリフ書体でも挙動が怪しくなることも サンセリフなら良い

Adobeのアプリなどでチェック可能、可能ならWindowsでも

手動ヒンティングはフルタイムの仕事？

ヒンターさんはすごい少ない Monotypeにはかつていて、フリーランスのヒンターもいた

大曲さんでも知ってる人は5人くらい

ヒンティングはデザイナーがやるべき？

可能ならデザイナーがやる方が良い

アウトラインを作った自分がドットも面倒を見る（理想としては）

ヒンティング実際やる？

特殊な低解像度のシステムの時のみ

基本的にはやらなくても良い時代になってきている

TTのヒンティングを実務で行うことはある？

等幅フォントなどで行うこともあるかも、プログラム用など

コーディング用フォントだと小さいサイズになりやすいので、そこを気にする人はいる

参考