ターミナルのフォントを整える(2026年版)

2026-09-07T13:04:27+09:00
Table of Contents</summary> </details>
ターミナルの欧文フォントには、以前の記事</a>で書いたとおり Berkeley Mono</a> を使い続けています。ただしBerkeley Monoは日本語のグリフを持たないため、日本語は別のフォントにフォールバックさせる必要があります。このフォールバックの設定を、思いつきで書くのではなく実測して組み直しました。</p> </span>
WezTerm のフォント設定の最終構成</h2>
結論を先に書くと、欧文がBerkeley Mono、全角が更紗ゴシック、アイコンがSymbols Nerd Font Monoという 3段構成に落ち着きました。全角文字がちょうど2セルに収まり、①</code> のような文字がセルからはみ出さず、太字と斜体のすべての組み合わせが合成ではなく実フェイスで描かれる状態です。</p>
役割</th> フォント</th> 指定</th></tr></thead>
欧文</td> Berkeley Mono（静的版）</td> セル幅 0.600 em</td></tr>
全角</td> 更紗ゴシック（Sarasa Term J）</td> scale = 1.2</code></td></tr>
アイコン</td>
Symbols Nerd Font Mono 3.5.1</td>
指定なし</td></tr> </tbody></table>
font_size</code> は20.0です。ターミナルは文字を等幅のマス目に並べて表示します。欧文1文字がマス目1つ、日本語1文字はマス目2つにちょうど収まらないと表示が崩れるため、サイズは自由に選べません。20.0はその条件を満たす値です。詳しくは後述します。</p>
文字の送り幅をどう測ったか</h2>
ターミナルのフォント設定は、見た目で判断すると微妙なズレを見逃します。
そこで2つの道具で数値を取りました。測る対象は送り幅、
つまり1文字を描いたあと次の文字の位置までカーソルが進む距離です。</p>
ひとつはfontToolsです。フォントファイルそのものを読み、hmtx</code> テーブルから
送り幅を取り出します。フォントと文字を並べて一度に測りました。</p>
from</span> fontTools</span>.</span>ttLib</span> import</span> TTFont</span></span>
from</span> pathlib</span> import</span> Path</span></span>
</span>
# ttc は fontNumber でフェイスを選ぶ。220 は Sarasa Term J Regular</span></span>
FONTS</span> =</span> [</span></span>
    (</span>"Berkeley Mono Regular"</span>,</span> "BerkeleyMono-Regular.otf"</span>,</span> 0</span>),</span></span>
    (</span>"Sarasa Term J Regular"</span>,</span> "Sarasa-SuperTTC.ttc"</span>,</span> 220</span>),</span></span>
]</span></span>
CHARS</span> =</span> [(</span>"A"</span>,</span> 0x</span>41</span>), (</span>"あ"</span>,</span> 0x</span>3042</span>), (</span>"①"</span>,</span> 0x</span>2460</span>)]</span></span>
</span>
for</span> label</span>,</span> name</span>,</span> index</span> in</span> FONTS</span>:</span></span>
    f</span> =</span> TTFont</span>(</span>Path</span>.</span>home</span>()</span> /</span> "Library/Fonts"</span> /</span> name</span>,</span> fontNumber</span>=</span>index</span>,</span> lazy</span>=</span>True</span>)</span></span>
    upem</span> =</span> f</span>[</span>"</span>head</span>"</span>].</span>unitsPerEm</span></span>
    cmap</span> =</span> f</span>.</span>getBestCmap</span>()</span></span>
    cols</span> =</span> []</span></span>
    for</span> char</span>,</span> cp</span> in</span> CHARS</span>:</span></span>
        gid</span> =</span> cmap</span>.</span>get</span>(</span>cp</span>)</span></span>
        adv</span> =</span> f</span>"</span>{</span>f</span>[</span>'</span>hmtx</span>'</span>][</span>gid</span>][</span>0</span>]</span> /</span> upem</span>:.3f</span>}</span> em"</span> if</span> gid</span> else</span> "-"</span></span>
        cols</span>.</span>append</span>(</span>f</span>"</span>{</span>char</span>} {</span>adv</span>:>8</span>}</span>"</span>)</span></span>
    print</span>(</span>f</span>"</span>{</span>label</span>:24</span>}</span>"</span> +</span> "  "</span>.</span>join</span>(</span>cols</span>))</span></span></code></pre>Berkeley Mono Regular   A 0.600 em  あ        -  ①        -</span></span>
Sarasa Term J Regular   A 0.500 em  あ 1.000 em  ① 0.500 em</span></span></code></pre>
emは文字サイズを1とした単位なので、この値はフォントサイズに左右されない設計値です。
Berkeley Monoは 'A' を0.600 emで送り、日本語のグリフは持ちません。
更紗ゴシックは半角が0.500 em、全角が1.000 emで、①</code> は半角側です。
2つのフォントは幅の基準そのものが違う、というのがここで分かります。</p>
もうひとつはWezTerm自身の ls-fonts</code> です。こちらは「設定を与えたときに実際にどのファイルの
どのフェイスが選ばれ、送り幅がいくつになるか」を返します。--codepoints</code> には
調べたい文字をUnicodeのコードポイントで渡します。41</code> はU+0041の 'A'、
3042</code> はU+3042、ひらがなの「あ」です。ここで読み込む test.lua</code> は、
Berkeley Monoと更紗ゴシックを並べただけの素の設定です。</p>
wezterm</span> --config-file ./test.lua ls-fonts --codepoints 41,3042</span></span></code></pre>0 A  \u{41}   x_adv=12 cells=1 wezterm.font("Berkeley Mono", ...)</span></span>
1 あ \u{3042} x_adv=20 cells=2 wezterm.font("Sarasa Term J", ...)</span></span></code></pre>
上記の結果から次のことがわかります。</p>
'A' はBerkeley Monoから取られ、送り幅を表す x_adv</code> は12ピクセル、占める幅は cells=1</code> で1セルです。ここから1セルの幅が12ピクセルだと実測で分かります。「あ」は更紗ゴシックから取られ、cells=2</code> は2セルを占めるべき文字だというWezTermの判定です。2セルなら24ピクセル必要なのに、x_adv</code> は20ピクセルしかありません。4ピクセル足りない状態です。この4ピクセルをどう埋めるかが次節の話になります。ここがズレたままだと日本語混じりの表や罫線が崩れます。</p>
フォントファイルの設計値と、WezTermが実際に採用する値は一致しないことがあるため、
この2つを突き合わせる必要がありました。</p>
全角を正確に2セルへ</h2>
更紗ゴシックは半角0.500 em、全角1.000 emという厳密なグリッドを持っています。
一方Berkeley Monoのセル幅は0.600 emです。セルの幅はBerkeley Monoに合わせるため、
全角が収まるべき2セルは1.200 emになります。更紗ゴシックの全角は1.000 emなので、
そのまま並べると0.200 em足りません。</p>
WezTermの scale</code> は、フォールバックさせるフォントを何倍で描くかを指定します。
0.500 × 1.2 = 0.600なので、scale = 1.2</code> にすれば更紗ゴシックの半角がBerkeleyのセル幅と一致し、
全角はその2倍になります。総当たりで確認しました。</p>
scale</th> セル幅</th> あ</code>（要24）</th> ①</code>（要12）</th></tr></thead>

1.1</td> 12</td> 22</td> 11</td></tr>
1.15</td> 12</td> 23</td> 12</td></tr>
1.2</td> 12</td> 24</strong></td> 12</strong></td></tr>
1.25</td> 12</td> 25</td> 13</td></tr>
</tbody></table>
ここで厄介なのが、WezTermがセル幅を整数に丸めることです。
0.600 × font_size</code> が整数から離れると、丸めの誤差でグリッドが崩れます。
font_size</code> を振って確かめたところ、成立するサイズは限られていました。</p>
font_size</th> セル幅</th> あ</code></th> ①</code></th> 判定</th></tr></thead>

16.0</td> 10</td> 19</td> 10</td> 全角が1px不足</td></tr>
18.0</td> 11</td> 22</td> 11</td> ぴったり</td></tr>
19.0</td> 11</td> 23</td> 12</td> 1px超過</td></tr>
20.0</td> 12</td> 24</td> 12</td> ぴったり</td></tr>
21.0</td> 13</td> 25</td> 13</td> 全角が1px不足</td></tr>
22.0</td> 13</td> 26</td> 13</td> ぴったり</td></tr>
24.0</td> 14</td> 29</td> 15</td> 1px超過</td></tr>
</tbody></table>
font_size = 20.0</code> を選んでいるのはこのためです。18.0と22.0も使えますが、
21.0や24.0に動かすと桁がずれます。⌘+ と ⌘− でサイズを変える運用をしていると
崩れる場面があるので、この事情は設定ファイルにコメントとして残しました。</p>
Ambiguous 幅と漢字カバレッジ</h2>
日本語フォントなら何でもよいわけではありません。決定的なのはEast Asian Ambiguous、
つまり半角と全角のどちらとも解釈しうる文字の扱いです。
①②③</code>、◆</code>、※</code> あたりが該当します。</p>
Ambiguousは、UnicodeのEast Asian Widthプロパティで A</code> に分類される文字です。
狭幅と広幅のどちらにも解決されうる、という分類までがUnicodeの担当で、
どちらに倒すかを決めるのは端末です。WezTermには
treat_east_asian_ambiguous_width_as_wide</code> という設定があります。既定は false</code>、
つまり1セルとして数えます。したがって「半角が正しい」のではなく、
端末の数え方とフォントの字幅が一致していることが要件になります。
端末が1セルと数えているのに字が2セル分あると、隣にはみ出すだけでは済みません。
カーソルの桁数は1のまま進むので、以降の再描画で端末が消したつもりの位置と
実際に塗られた位置が1桁ずれ、消し残りや行の崩れになります。</p>
では全角側に倒せばよいかというと、こちらも通りません。
Ambiguousに含まれるのは丸数字や記号だけではないからです。
罫線の ─│┌</code>、矢印の →</code>、°</code> や ±</code>、ギリシャ文字とキリル文字、
そしてNerd Fontのアイコンやpowerlineの区切りにも、ここに属するものが多くあります。
これらの多くがUnicodeの私用領域を使っており、私用領域は E000..F8FF</code> が丸ごとAmbiguousだからです。
treat_east_asian_ambiguous_width_as_wide = true</code> を指定すると、これらは一斉に2セル幅へ変わります。
プロンプトの区切りとアイコン、tree</code> や gh</code> の引く枠線まで、横幅は倍になります。
①</code> を正しく出すためにプロンプトと罫線を組み直すのは割に合わないので、半角側に倒します。
コードポイント範囲ごとに幅を指定する cell_widths</code> を使えば私用領域だけを全角へ固定できますが、
これはnightlyビルド限定の設定で、手元の安定版20240203-110809-5046fc22は受け付けませんでした。
Vimの ambiwidth=double</code> に代表される全角前提の設定は、日本語環境では長く標準でした。
常時目に入る文字の中身がこれだけ変わった今は、半角側のほうが破綻は少なくなっています。</p>
macOS標準のヒラギノ角ゴシックは、これらを全角で設計しています。
手元の構成で測ると、セル幅12に対して送り幅は13.75でした。
25パーセントはみ出して隣の文字と干渉します。しかもこれは scale</code> を振っても変わりませんでした。</p>
更紗ゴシック（Sarasa Term J）は、Ambiguousを半角として設計した系統です。
①</code> と ◆</code> はどちらも0.500 emで、scale = 1.2</code> を掛けてちょうど1セルに収まります。
同じ更紗ゴシックでも "Mono" 系統はAmbiguousが全角なので、ターミナルには "Term" を選ぶ必要があります。</p>
漢字のカバレッジも測りました。ここは数え方に注意が必要です。</p>
フォント</th> JIS X 0208</th> JIS X 0213</th> Unicode CJK統合漢字</th></tr></thead>

Sarasa Term J</td> 100 %</td> 100 %</td> 100 %</td></tr>
ヒラギノ角ゴ Sans W3</td> 100 %</td> 85.3 %</td> 51.3 %</td></tr>
</tbody></table>
ヒラギノの51.3パーセントという数字は一見すると低く見えますが、
UnicodeのCJK統合漢字ブロックは日本語・簡体字・繁体字・韓国・ベトナムの漢字を
すべて含む集合なので、日本語フォントの評価軸としては適切ではありません。
PythonのShift_JISコーデックで判定したところ、ヒラギノに無い1万225字のうち
JIS X 0208に含まれるものは0字でした。常用漢字と人名用漢字は完全にカバーしています。</p>
なおmacOS全体では、標準フォントを合わせるとCJK統合漢字を100パーセント表示できます。
ただし日本語フォントに無い字はHiragino Sans GB（簡体字）やHeiti TC（繁体字）に落ちるため、
表示はされても字形が中国字体になります。更紗ゴシックを使うと、この落下自体が起きません。</p>
Nerd Font はシンボル専用フォントで足りる</h2>
以前はNerd Fontのアイコンを、パッチ済みの日本語フォントから取っていました。
しかしアイコンのためだけに日本語フォントを1本抱えるのは無駄です。
nerd-fonts</a> には
シンボルだけを収録したフォントがあり、Homebrewから入ります。</p>
brew</span> install --cask font-symbols-only-nerd-font</span></span></code></pre>
実はWezTermにはSymbols Nerd Font Monoが同梱されていて、
何もしなくてもフォールバック連鎖の末尾に入っています。
アイコンの解決先を29点サンプリングしたところ、23点が内蔵フォントで解決し、
Powerlineの区切りはWezTerm自身が描画していました。
豆腐になったのは U+E6B5</code> と U+EC1E</code> の2点だけです。</p>
つまり多くの場合は内蔵で足ります。それでも単体版を入れたのは、
内蔵版が古いビルドで上記2点が欠けていたためです。
インストール版がCoreText経由で優先されることと、欠けていた2字が埋まることは確認しました。</p>
更紗ゴシックとは</h2>
更紗ゴシックはRenzhi Li（Belleve Invis）氏によるOFL-1.1のフォントです。
Iosevka</a> の作者でもあります。</p>
中身を知っておくと判断しやすくなります。フォントファイルの著作権表記はこうなっています。</p>
Copyright (c) 2015-2025, Renzhi Li (aka. Belleve Invis, belleve@typeof.net).</span></span>
Portions Copyright (c) 2016 The Inter Project Authors.</span></span>
Portions Copyright (c) 2014-2021 Adobe Systems Incorporated.</span></span>
Portions Copyright (c) 2012 Google Inc.</span></span></code></pre>
Adobeが源ノ角ゴシック（Source Han Sans）、GoogleがNoto Sans CJKです。
つまり更紗ゴシックの漢字とかなは源ノ角ゴシックそのもので、
作者の仕事はIosevkaの欧文と合成し、半角と全角を厳密に1:2のグリッドへ再設計することでした。
今回の構成では欧文をBerkeley Monoが担当するので、更紗ゴシックは実質的に
「ターミナル用に幅を再設計した源ノ角ゴシック」として働いています。</p>
この再設計は、源ノ角ゴシックをそのまま使わない理由でもあります。両者を実測しました。</p>
文字</th> 源ノ角ゴシック JP</th> 更紗ゴシック Term J</th></tr></thead>

①</code> ◆</code> ※</code></td> 1.000 em</td> 0.500 em</td></tr>
─</code> →</code></td> 1.000 em</td> 0.500 em</td></tr>
°</code></td> 0.370 em</td> 0.500 em</td></tr>
α</code></td> 0.625 em</td> 0.500 em</td></tr>
あ</code> 漢</code></td> 1.000 em</td> 1.000 em</td></tr>
</tbody></table>
源ノ角ゴシックはAmbiguousを全角に置き、°</code> や α</code> は字ごとの固有幅を持ちます。
一般の文書組版としては妥当ですが、前述のAmbiguousの条件は満たしません。
更紗ゴシックのTerm系統はこれらをすべて0.500 emへ揃えています。
かなと漢字の字形が同じでも、ターミナルで使えるかどうかはこの一点で分かれます。</p>
Iosevka自体もコード用のフォントとしては高く評価されています。文字幅が狭いので、老眼にはつらいのですが多くの情報を表示できるので好まれているようです。</p>
"J" は日本語字形を意味します。同じ更紗ゴシックでもSCを選ぶと漢字が中国字形になるため、
日本語環境ではJを選ぶ必要があります。</p>
ウェイトは5段（200 / 300 / 400 / 600 / 700）で、それぞれにイタリックがあり、
合計10面すべてが実フェイスです。nameID 1では
Sarasa Term J Light</code> のように枝番のファミリ名に分かれていますが、
nameID 16のタイポグラフィックファミリは10面とも Sarasa Term J</code> で共通なので、
ファミリ名は変えずに weight</code> を指定するだけで切り替わります。
日本語フォントにイタリックがあるのは珍しく、ヒラギノはW0からW9まで10段のウェイトを持ちながら
イタリックを1面も持ちません。ターミナルでは斜体をコメントの表示に使うので、ここは実用差になります。</p>
供給元について書いておくと、フォントは実行ファイルではなく、
ネットワークアクセスとテレメトリのいずれも持ちません。理論上の懸念はTrueTypeのヒンティング命令ですが、
更紗ゴシックのヒンティングはttfautohintによる自動生成で、
macOSのCoreTextはフォント解析をサンドボックス下で行います。
GitHub Releasesから手動でダウンロードするとチェックサムの検証がないため、
Homebrewのcask経由に切り替えました。</p>
brew</span> install --cask font-sarasa-gothic</span></span></code></pre>
ライセンスはOFL-1.1で、撤回できません。一度入手したものを後から使えなくされることは
原理的にないという点は、単一ベンダーの商用フォントより安心できる部分です。</p>
WezTerm の設定</h2>
設定の該当部分です。font_rules</code> は指定したフォントで丸ごと置き換わる仕様なので、
太字と斜体でも同じ3段を組み直す必要があります。ここを怠ると、
太字の日本語やアイコンがフォールバックから外れます。</p>
local function</span> font_stack</span>(</span>weight</span>,</span> italic</span>)</span></span>
 return</span> wezterm.</span>font_with_fallback</span>({</span></span>
  { family</span> =</span> "Berkeley Mono"</span>, weight</span> =</span> weight, style</span> =</span> italic</span> and</span> "Oblique" </span>or</span> "Normal" </span>},</span></span>
  -- Sarasa は Oblique を持たず Italic</span></span>
  { family</span> =</span> "Sarasa Term J"</span>, weight</span> =</span> weight, style</span> =</span> italic</span> and</span> "Italic" </span>or</span> "Normal"</span>, scale</span> =</span> 1.2</span> },</span></span>
  { family</span> =</span> "Symbols Nerd Font Mono" </span>},</span></span>
 })</span></span>
end</span></span>
</span>
config.font</span> =</span> font_stack</span>(</span>400</span>, </span>false</span>)</span></span>
</span>
config.bold_brightens_ansi_colors</span> =</span> true</span></span>
config.font_rules</span> =</span> {</span></span>
 { intensity</span> =</span> "Bold"</span>, font</span> =</span> font_stack</span>(</span>700</span>, </span>false</span>) },</span></span>
 { italic</span> =</span> true</span>, font</span> =</span> font_stack</span>(</span>400</span>, </span>true</span>) },</span></span>
 { italic</span> =</span> true</span>, intensity</span> =</span> "Bold"</span>, font</span> =</span> font_stack</span>(</span>700</span>, </span>true</span>) },</span></span>
}</span></span></code></pre>
font_size = 20.0</code> は別のテーブルで設定しています。
なぜこの値なのか、なぜ scale</code> が1.2なのかは、忘れた頃に自分を助けるので
実測値ごとコメントとして設定ファイルに残しました。</p>
まとめ</h2>
設定の結果、送り幅を検証すると次のようになります。</p>
A      x_adv=12  cells=1   1セルぴったり</span></span>
あ 漢  x_adv=24  cells=2   2セルぴったり</span></span>
① ◆   x_adv=12  cells=1   1セルぴったり</span></span></code></pre>
日本語混じりの表や罫線が崩れなくなり、①</code> のような記号が隣の文字と重ならなくなりました。太字と斜体は、欧文がBerkeley Monoの設計どおりのOblique、和文が更紗ゴシックの実イタリックで描かれます。合成は発生していません。アイコンのために日本語フォントを抱える必要もなくなりました。</p>
この記事の原稿をエディタで開いた画面です。日本語と欧文が混ざっても、文字がマス目からはみ出さずに並んでいます。</p>


日本語と欧文が混在する原稿をWezTermで表示した画面</figcaption>
</figure>
和文を1.2倍で描いているため日本語が欧文よりやや大きく見えますが、個人的にはこちらの方が読みやすく感じています。また欧文がまとまって見えるので、コード交じりの文章も見やすくなりました。</p>
References</h2>


    
Berkeley Graphics</a>. "Berkeley Mono Typeface"</li>
Sarasa Gothic</a>. 「更紗ゴシック」</li>
Nerd Fonts</a>. "Iconic font aggregator"</li>
WezTerm</a>. "Font Configuration"</li>
Adobe Type Tools</a>. "Source Han Sans"</li>
</ul>

</div>



フォント編集ソフト OTEdit問題
2025-09-20T00:00:00+00:00

Table of Contents</summary>
  
</details>
フォント編集ソフト「OTEdit」で作成されたフォントの空グリフ問題について解説。Adobe-Japan1文字集合選択時に発生する空グリフによりフォールバック機能が正常に動作しない問題と、Pythonスクリプトを使った修正方法を紹介。</p>
OTEditとは</h2>
OTEdit</strong>とは、武蔵システム</a>が販売する
OpenTypeフォントを作成・編集を行なうアプリケーションです。
Windows版とMac版が販売されています。</p>
この手のアプリケーションとしては比較的安価で、使用しているフォント作家の方も多いようです。</p>
OTEditの問題</h2>
(以下の考察は、OTEditの試用版による短時間の検証に基づいています。全ての機能を検証できている訳ではないので誤りを含む可能性があります。)</em></p>
OTEditではAdobe-Japan1-3、Adobe-Japan1-4、 Adobe-Japan1-7の3種の文字集合のフォントを作成できます。
新規作成時に選択した文字集合について全てのグリフを設定することを前提としているようです。
OTEditではフォントの新規作成時に選択した文字集合から文字の削除ができず、グリフが作成されなくとも「空グリフ」と
各文字コードとグリフのcmapを作成してしまいます。</p>
すべてのフォントがAdobe社の策定した日本語文字集合規格で作成されればよいのですが、
実際にはいずれかの文字集合を選択してもすべてのグリフをサポートしないフォントも多いようです。
例えば、IPAが配布するIPAフォントです。このフォントがどんなツールを使用して作成されたか不明ですが、
JIS X 0213:2012の文字集合をサポートしておりAdobe社の文字集合規格には従っていません。
Adobeの規格と並べると下表のような食い違いがあります。</p>
文字セット</th> 総文字数</th> JIS第1～2水準（6,355字）</th> JIS第3～4水準（3,695字）</th> JIS規格外文字（異体字・独自文字）</th> 主な特徴</th></tr></thead>

JIS X 0213:2012</td> 11,233文字</td> 完全対応</td> 完全対応</td> 含まない</td> 公的規格・政府標準</td></tr>
Adobe-Japan1-3</td> 9,354文字</td> 完全対応</td> 非対応</td> 機種依存文字等含む</td> 一般用途標準</td></tr>
Adobe-Japan1-4</td> 15,444文字</td> 完全対応</td> 一部対応</td> 多数の独自文字・異体字含む</td> 商業印刷用</td></tr>
Adobe-Japan1-7</td> 23,060文字</td> 完全対応</td> 完全対応</td> 大量の独自文字・異体字含む</td> 最上位規格</td></tr>
</tbody></table>
このようなケースでは、OTEditがcmapを生成しますが作者がグリフを用意していない文字には「空グリフ」をマッピングしてしまいます。</p>
通常の使用ではあまり問題にならないかもしれませんが、フォント表示の際にフォールバックを前提にしている
ターミナルやブラウザなどで使用するとマズいことになります。
本来であれば指定したフォントがグリフを持たない場合は、別のフォントのグリフが表示されます。
しかしOTEditで作成したフォントでは、「空グリフ」が設定されている可能性が高いので「空白」が表示されてしまいます。</p>
フォントの修正</h2>
最近購入した中村書体室の「カドマ-R」でこの不具合の遭遇したので、
作者の方に相談させていただき手元のフォントに修正を掛けました。</p>
対応は、空グリフと思われる文字を調査し該当文字についてcmapからエントリーを削除するという乱暴なものです。
以下がそのスクリプトです。</p>
分析スクリプト</h3>
#!/usr/bin/env python3</span></span>
# -*- coding: utf-8 -*-</span></span>
</span>
</span>
# HomebrewのPython環境でFontToolsを使用</span></span>
sys</span>.</span>path</span>.</span>insert</span>(</span>0</span>,</span> '/opt/homebrew/Cellar/fonttools/4.59.2/libexec/lib/python3.13/site-packages'</span>)</span></span>
</span>
try</span>:</span></span>
    from</span> fontTools</span>.</span>ttLib</span> import</span> TTFont</span></span>
    from</span> fontTools</span>.</span>pens</span>.</span>recordingPen</span> import</span> RecordingPen</span></span>
except</span> ImportError</span> as</span> e</span>:</span></span>
    print</span>(</span>f</span>"Import error: </span>{</span>e</span>}</span>"</span>)</span></span>
    sys</span>.</span>exit</span>(</span>1</span>)</span></span>
</span>
def</span> analyze_font_glyphs</span>(</span>font_path</span>):</span></span>
    """フォントファイルを分析して空のグリフとスペースグリフを区別する"""</span></span>
</span>
    font</span> =</span> TTFont</span>(</span>font_path</span>)</span></span>
    cmap</span> =</span> font</span>.</span>getBestCmap</span>()</span></span>
</span>
    if</span> 'CFF '</span> in</span> font</span>:</span></span>
        cff</span> =</span> font</span>[</span>'</span>CFF </span>'</span>]</span></span>
        charstrings</span> =</span> cff</span>.</span>cff</span>[</span>0</span>].</span>CharStrings</span></span>
    else</span>:</span></span>
        print</span>(</span>"This is not a CFF font"</span>)</span></span>
        return</span></span>
</span>
    hmtx</span> =</span> font</span>[</span>'</span>hmtx</span>'</span>]</span></span>
    results</span> =</span> []</span></span>
</span>
    space_codes</span> =</span> [</span>0x</span>0020</span>,</span> 0x</span>3000</span>]</span>  # SPACE, IDEOGRAPHIC SPACE</span></span>
</span>
    for</span> unicode_code</span>,</span> glyph_name</span> in</span> sorted</span>(</span>cmap</span>.</span>items</span>()):</span></span>
        if</span> glyph_name</span> in</span> hmtx</span>.</span>metrics</span>:</span></span>
            width</span>,</span> lsb</span> =</span> hmtx</span>.</span>metrics</span>[</span>glyph_name</span>]</span></span>
        else</span>:</span></span>
            width</span>,</span> lsb</span> =</span> 0</span>,</span> 0</span></span>
</span>
        if</span> glyph_name</span> in</span> charstrings</span>:</span></span>
            charstring</span> =</span> charstrings</span>[</span>glyph_name</span>]</span></span>
</span>
            pen</span> =</span> RecordingPen</span>()</span></span>
            try</span>:</span></span>
                charstring</span>.</span>draw</span>(</span>pen</span>)</span></span>
                commands</span> =</span> pen</span>.</span>value</span></span>
                has_drawing</span> =</span> len</span>(</span>commands</span>)</span> ></span> 0</span></span>
            except</span> Exception</span>:</span></span>
                has_drawing</span> =</span> False</span></span>
</span>
            # グリフの分類</span></span>
            is_space_char</span> =</span> unicode_code</span> in</span> space_codes</span></span>
</span>
            if not</span> has_drawing</span>:</span></span>
                if</span> width</span> ></span> 0</span>:</span></span>
                    if</span> is_space_char</span>:</span></span>
                        glyph_type</span> =</span> "SPACE"</span></span>
                    else</span>:</span></span>
                        glyph_type</span> =</span> "BLANK_WITH_WIDTH"</span></span>
                else</span>:</span></span>
                    glyph_type</span> =</span> "EMPTY"</span></span>
            else</span>:</span></span>
                glyph_type</span> =</span> "NORMAL"</span></span>
</span>
            results</span>.</span>append</span>({</span></span>
                'unicode'</span>:</span> f</span>"U+</span>{</span>unicode_code</span>:04X</span>}</span>"</span>,</span></span>
                'code'</span>:</span> unicode_code</span>,</span></span>
                'char'</span>:</span> chr</span>(</span>unicode_code</span>),</span></span>
                'glyph_name'</span>:</span> glyph_name</span>,</span></span>
                'type'</span>:</span> glyph_type</span>,</span></span>
                'width'</span>:</span> width</span>,</span></span>
                'commands_count'</span>:</span> len</span>(</span>commands</span>)</span> if</span> has_drawing</span> else</span> 0</span>,</span></span>
            })</span></span>
</span>
    return</span> results</span></span></code></pre>
判定基準は、次の通りです。</p>

NORMAL: 描画データがあるグリフ</li>
SPACE: スペース文字（U+0020, U+3000）で描画データなし</li>
BLANK_WITH_WIDTH: スペース以外で幅はあるが描画データなし → 削除対象</li>
EMPTY: 幅や描画データがない → 削除対象</li>
</ul>
自動修正スクリプト</h3>
def</span> fix_font_cmap_only</span>(</span>input_path</span>,</span> output_path</span>):</span></span>
    """OTEで作成されたフォントのcmapテーブルから空グリフエントリを削除"""</span></span>
</span>
    font</span> =</span> TTFont</span>(</span>input_path</span>)</span></span>
    original_cmap</span> =</span> font</span>.</span>getBestCmap</span>()</span></span>
</span>
    if</span> 'CFF '</span> in</span> font</span>:</span></span>
        cff</span> =</span> font</span>[</span>'</span>CFF </span>'</span>]</span></span>
        charstrings</span> =</span> cff</span>.</span>cff</span>[</span>0</span>].</span>CharStrings</span></span>
    else</span>:</span></span>
        return</span> False</span></span>
</span>
    hmtx</span> =</span> font</span>[</span>'</span>hmtx</span>'</span>]</span></span>
    codes_to_remove</span> =</span> []</span></span>
</span>
    space_code</span> =</span> 0x</span>0020</span></span>
    ideographic_space_code</span> =</span> 0x</span>3000</span></span>
</span>
    for</span> unicode_code</span>,</span> glyph_name</span> in</span> original_cmap</span>.</span>items</span>():</span></span>
        if</span> glyph_name</span> in</span> hmtx</span>.</span>metrics</span>:</span></span>
            width</span>,</span> lsb</span> =</span> hmtx</span>.</span>metrics</span>[</span>glyph_name</span>]</span></span>
        else</span>:</span></span>
            width</span>,</span> lsb</span> =</span> 0</span>,</span> 0</span></span>
</span>
        if</span> glyph_name</span> in</span> charstrings</span>:</span></span>
            charstring</span> =</span> charstrings</span>[</span>glyph_name</span>]</span></span>
</span>
            pen</span> =</span> RecordingPen</span>()</span></span>
            try</span>:</span></span>
                charstring</span>.</span>draw</span>(</span>pen</span>)</span></span>
                commands</span> =</span> pen</span>.</span>value</span></span>
                has_drawing</span> =</span> len</span>(</span>commands</span>)</span> ></span> 0</span></span>
            except</span> Exception</span>:</span></span>
                has_drawing</span> =</span> False</span></span>
</span>
            # スペース文字以外で描画データがない場合は削除対象</span></span>
            if</span> unicode_code</span> not in</span> [</span>space_code</span>,</span> ideographic_space_code</span>]:</span></span>
                if not</span> has_drawing</span> and</span> width</span> ></span> 0</span>:</span></span>
                    codes_to_remove</span>.</span>append</span>(</span>unicode_code</span>)</span></span>
</span>
    # cmapテーブルから削除</span></span>
    for</span> table</span> in</span> font</span>[</span>'</span>cmap</span>'</span>].</span>tables</span>:</span></span>
        if</span> hasattr</span>(</span>table</span>,</span> 'cmap'</span>):</span></span>
            for</span> code</span> in</span> codes_to_remove</span>:</span></span>
                if</span> code</span> in</span> table</span>.</span>cmap</span>:</span></span>
                    del</span> table</span>.</span>cmap</span>[</span>code</span>]</span></span>
</span>
    font</span>.</span>save</span>(</span>output_path</span>)</span></span>
    return</span> True</span>,</span> len</span>(</span>codes_to_remove</span>)</span></span></code></pre>修正結果</h2>
修正結果は次の通りです。</p>

総cmapエントリ数: 10,161 → 5,762個（削減率: 43.3%）</li>
削除されたエントリ: 4,399個</li>
Adobe Japan 1-4拡張範囲: 408個</li>
その他の範囲: 3,991個</li>
ファイルサイズ: 2.6% 削減</li>
</ul>
修正の結果、
今のところターミナルでも問題なく使用できています。</p>
上記のスクリプトは精緻にテストを行なっていませんので、
利用については自己責任でどうぞ。</p>


中村書体室のフォント「カドマ-R」を購入
2025-09-15T00:00:00+00:00


ターミナル用に中村書体室</a>の「カドマ-R</a>」
を購入しました。</p>
文字のマス目一杯にデザインされていますが、コーナーには限りなく柔らかな丸みがつけてあります。
スクエアなのに丸みや柔らかさを感じるという、
従来の丸ゴシック体や角ゴシック体とも違う独特な印象があり大変気に入っています。</p>
ターミナルで愛用していますが、
半角文字は大きさを合わせてデザインされているようで英単語などを多用すると読みづらいので、
半角文字はBerkeley Mono</code> を表示するようにしています。</p>
あまりに気に入ったので、このサイトにも使用させていただいています。1</a></sup> 2</a></sup></p>
また、購入後に書体の追加とOTFへの移行を快く対応いただき、
書体デザイナーの中村征宏様には大変感謝しています。</p>



フォントの変換とサイトでの使用については、中村書体室に同意をいただいています。 ↩</a></p>
</li>

2026年よりブログのプラットフォームを移行したので、WEBフォントは外しています。 ↩</a></p>
</li>
</ol>
</section>


中村書体室の新フォント「コントラ体」
2025-07-15T00:00:00+00:00


中村書体室</a>から新フォント「コントラ体」がリリースされたので、早速購入しました。</p>
このフォントは直線を基調としながらも、太い線と細い線が一見不規則に配置されています。この大胆な太細の差が、まさにフォント名の由来となった「コントラスト」を生み出しています。遊び心がありながらも、どこか書道を思わせる味わい深さを併せ持つ、実にユニークなフォントです。</p>
高いデザイン性ゆえに本文での使用には向きませんが、動画のタイトルやポスターの見出しなど、インパクトを求める場面では効果的に使えそうです。</p>
制作者の中村征宏氏は、「ゴナ」や「ナール」といった名作書体を手がけた巨匠です。80歳を超えてなお精力的に新作を発表し続ける姿勢には、本当に頭が下がります。</p>
購入後にいただいた発送連絡メールには、以下のような心温まるメッセージが添えられていました。</p>

もし不足文字が出た時はご通知ください。2〜3日で文字追加ファイルをメール添付にて送信いたします。フォントに不備がありましたらご連絡をお願いします。</p>
</blockquote>
こうした細やかな配慮からも、長年にわたって日本の文字文化を支えてこられた職人魂を感じます。</p>


Berkeley Mono: A Worthy Successor to MonoLisa in My Terminal
2024-12-19T00:00:00+00:00
ずっとMacのターミナルではMonoLisa</a>フォントを利用してきましたが、
Berkeley Mono</a>フォントに入れ替えました。</p>
MonoLisaフォントの課題</h2>
MonoLisaフォントは紛らわしい文字の区別やリガチャのサポートなどコーディングをサポートするためのデザインがなされており読みやすいフォントで愛用していました。一部筆記体のようなデザインも気に入っていました。</p>
ただし、次の2点が課題だと思っていました。</p>

読みやすさを考慮しているのだと思いますが、文字間隔が広すぎて間延びして逆にコードを把握しにくい。</li>
ライセンス費用が割高でWebフォントまで入手しようとすると非常に高額になる。</li>
</ul>
また、単純に飽きたということもあります。</p>
Cascadia Next JPのプレビューが出ているので少し使ってみしたが、かなり文字間隔が狭く凝縮した印象です。MonoLisaのように文字間隔が広すぎるより、個人的は好みでした。</p>
Berkeley Mono を導入する</h2>
Berkeley Monoは少し前に一部で話題になっていましたが、リガチャのサポートがなかったのでその時は見送りました。
ところが最近になって確認するとリガチャをサポートしたようだったので、購入しました。</p>
紹介文には以下のように書かれています。</p>

  Berkeley Mono is a love letter to the golden era of computing. The era that
  gave rise to a generation of people who celebrated automation and reveled in
  the joy of computing, when transistors replaced cogs, and machine-readable
  typefaces were developed, for when humans and machines truly interfaced on an
  unprecedented scale.
  
    
      Berkeley Graphics -{" "}
      
        Berkeley Mono
      </a>
    </cite>
  </footer>
</blockquote>
確かにちょっと懐かしい「コンピューター」らしい文字のデザインです。</p>
気に入っている点は、次の3点です。</p>

ちょうど良い文字間隔</li>
スクエアなデザイン</li>
買い切りでWebフォントまで含んでいる</li>
</ul>
特に文字間隔や高さが日本語フォントとバランス良いよいに思います。</p>
フォント比較</h2>
以下のスクリーンショットは、適当なプログラムCascadia Next / MonoLisa / Berkeley Monoを使って表示させた例です。</p>


文字間隔の違いがよくわかると思います。</p>
Coded Chords - Font

ターミナルのフォントを整える(2026年版)

フォント編集ソフト OTEdit問題

中村書体室のフォント「カドマ-R」を購入

中村書体室の新フォント「コントラ体」

Berkeley Mono: A Worthy Successor to MonoLisa in My Terminal
