微小画面向けの 5 ピクセル×5 ピクセルのフォント。

Japanese Translation:

最も重要な示唆は、AVR128DA28 などのリソース制約の厳しい 8 ビットマイクロコントローラ向けに最適化された、非常に効率的で手作業によるフォント設計にあります。lcamtuf の

5x6 font-inline.h

に基づき、ZX Spectrum のスタイルに触発されたこのアプローチは、ベクトルフォント（メガバイト規模のデータを必要とするため）が失敗したり、限られた RAM を備えたデバイス上で文字列長の計算時に整数溢れ問題を引き起こしたりする記憶制約を解決します。このフォントは合計 350 バイトで完結しており、標準的な 128x64 OLED などコンパクトなディスプレイに適合します。主要な設計判断はグリッド寸法に集中しており、5x5 グリッドが "E" や"M"や"W"のような個別の文字を損なうことなく完全な可読性を維持するための最小サイズであることが特定されました。一方、より小さなグリッドではフォント数の大幅な減少と可読性の低下を引き起こし（例：3x5 に落とすと特定の形状が失われ、3x3 未満では文字セットが単純なコードに縮小されます）。この定幅形式はプログラミングを簡素化し、画面内の文字列長が予測可能（文字数の 6 倍）になります。これにより、厳格にストレージ制限を受けたハードウェア上でもファームウェアは軽量かつ信頼性が保たれます。プロジェクトのソースには、2026 年 4 月に開発された

mcufont.h

および

test.c

と関連するピクセルアートフォントリポジトリが含まれています。

2026 年 4 月 18 日〜20 日（プログラミング）

フォントデータ（C ヘッダー）

すべての文字は縦 5 ピクセルの正方形内に収まり、6×6 のグリッド上で安全に描画できます。デザインは lcamtuf 氏の「font-inline.h」をベースにしており、それ自体は ZX Spectrum の 8×8 フォントに触発されています。

可读性の妥協を許さない最小サイズは 5×5 です：

2×2：不可能。
3×3：技術的には可能ですが、読めないレベルです。
4×4："E"、「M」、または"W"などを適切に描画するには不十分です。
5×5：本フォントの採用サイズです。

実は 5×5 は、小文字を 1 ピクセル小さくして大文字と視覚的に区別する十分な幅があります。さらに狭い 4×5 や 3×5 も実装は可能ですが、「M」や点付き「0」を使い難くし、「U」「V」「Y」の識別性を損なうことになってしまいます。すべての文字を同じ横幅（5 ピクセル）に揃える芸術的な理由はありませんが、プログラミング上では「一定幅を使う方が遥かに楽」という実用的なメリットがあります：画面上の文字列の長さは、常に文字数×6 です。また、緊密なレイアウトにおいて、"8978"の方が"1111"より長くなるという心配もなくなります。

全体としてこのフォントはメモリ占用がわずか 350 バイトです。これは AVR128DA28（RAM 16 kB）といった 8 ビットマイクロコントローラーへの理想的なサイズです。これらのマイコンは安価で低消費電力かつ堅牢ですが、グラフィックス性能では不足しています：解像度が低い 384×288 のディスプレイでも 11 万画素必要となり、AVR のメモリ容量からは遥かに超えてしまいます……しかし、多くのプロジェクトではそんな大量の画素は実際には不要です。実用的で安価なのは 160×128 や 128×64 の OLED でありますが、これらを活かすには手作業で作られた画素効率が優れたフォントが求められます。

参考として、同程度の縮尺でレンダリングされたベクターフォントを以下に示します：

実際には高さ 6 ピクセルですが、文字幅の方が狭いため、ここは例外として許容します。

アンチエイリアリング、数 MB のコード、1 MB のフォントデータを用いたものでも、自作の 350 バイトのものに比べれば劣ります。現実のピクセルは完璧な正方形ではないため、このフォントは記事冒頭のレンダリング画像とは実際に異なる見た目になります：これが実画面での表示です：

個人的には、サブピクセルによって生じる擬似的なドロップシャドウ効果は大変気に入っています。モノクロディスプレイではこうした現象は起きませんが、それでも驚くほど滑らかな印象を与えるでしょう。ピクセル間のギャップが"e"や"g"の文字表現を特に強調し、同様の効果が……

さらに小さいフォントにも挑戦しました：

5×5 は妥協を許さず最小な解像度ですが、3×5 も悪くありません：このサイズでは 32,768 のグリフが定義可能（そのうち 27,904 が一意）。"M"、"W"、"Q"の品質は低下しますが、"O"と点付き"0"の違いはまだ保たれています。ディスプレイに列数を 50% 増やす必要がある場合は、これのような解像度が現実的な選択肢になり得ます。それでも読み取れますし、3×4 ではどうでしょうか：

このサイズではグリフ数が 4,096（そのうち 3,392 が一意）です。この規模では大文字と小文字を明確に区別することは不可能なので、限られた空間の中で最も馴染みのあるスタイルを採用しました。数字も影響を受けましたが、それでも使い物になります。

3×3 ではどうでしょうか：

このサイズではグリフ数は 512（そのうち 400 が一意）です。主な損失は数字部分ですが、文字自体は重複せず、ある程度認識可能です。

このフォントは実機ハードウェアで表示されることで劇的に改善されます：つまり、まだサイズが大きすぎます。では 2×3 はどうでしょうか：

このサイズではグリフ数が 64（そのうち 44 が一意）になります。もうこれはやりすぎでしょう。ほとんどの文字が認識できず、重複も多いです。以下の一行は"Hello World"と読めます：

縦横比を逆転させた 3×2 にするとかなり改善します：このサイズでもグリフ数は 64（そのうち 44 が一意）です。

シミュレーションされたピクセルグリッドでは、より多くの文字（M, W, N, Q, G, P など）が水平方向の詳細を持ち、「E」「F」のように垂直方向の詳細を持つ文字に比べて特徴的です。一行目は"you can probably read this"と読めますが、少し目を細めたりズームアウトしたりする必要があるかもしれません。そして完全性を保つためにも、2×2 のケースも確認します：

このサイズではグリフ数が 16（そのうち 10 が一意）です。紙面上で可能な 2×2 のパターンは 16 通りありますが、その内一つは空白であり、5 パターンは他のパターンのシフトコピーに過ぎません。残りの 10 パターンだけでは数字の全ての桁を表せる程度ですが、元の数字と全く似ていないため、これはフォントというより暗号に近いものです。

微小画面向けの 5 ピクセル×5 ピクセルのフォント。

Japanese Translation:

同じ日のほかのニュース