小さな画面向けの5x5ピクセルフォント
(maurycyz.com)- すべての文字を 5ピクセル四方 に収め、6x6グリッド内で安全に描画できるよう揃えた超小型固定幅フォントで、小さな画面と限られたメモリ環境向けに設計されている
- 5x5サイズは、4x4では不足していた
E、M、Wの表現上の問題を解決し、ほとんどの小文字を大文字より1ピクセル小さく描くことで 視覚的な識別性 も確保している - フォント全体はわずか 350バイト しかなく、AVR128DA28 のような 8ビットマイクロコントローラに適しており、160x128 や 128x64 OLED のような小型画面で ピクセル効率 が高い
- 近いサイズでレンダリングした ベクターフォント と比べても、アンチエイリアシングやはるかに大きなコード・フォントデータを使ってなお、350バイトの手作りフォントより結果が劣る
- さらに小さい 3x5、3x4、3x3、2x3、3x2、2x2 まで試しており、3x5 はかなり読める一方、3x2 は 2x3 より優れているが、2x2 は実質的に 秘密コード に近い水準まで崩れてしまう
5x5ピクセルフォント
- すべての文字が 5ピクセル四方 に収まり、6x6グリッド内で安全に描画できるよう設計されている
- ベースは lcamtuf の 5x6
font-inline.hで、このフォントは ZX Spectrum の 8x8 フォントの影響を受けている - 5x5 は可読性を損なわない最小サイズとして設定されている
- ベースは lcamtuf の 5x6
- 2x2 は不可能で、3x3 は技術的には可能だが読みにくく、4x4 は
E、M、Wを適切に描くには不足している- 5x5 ではこの問題が解決される
- 5x5 では、ほとんどの 小文字 を大文字より1ピクセル小さく描けるため、視覚的に区別できる
- より狭い 4x5 や 3x5 も可能だが、
M、ドット付きの0、そしてU/V/Yの識別性を犠牲にしなければならない - すべての文字を一定幅に揃えると、プログラミングが簡単になる
- 画面上の文字列長は常に文字数の 6倍 として計算できる
"8978"が"1111"より長くなってレイアウトが崩れる心配をしなくてよい
- フォント全体のサイズはわずか 350バイト で、AVR128DA28 のような 8ビットマイクロコントローラ に適している
- 本文には AVR128DA28 が RAM 16kB を備えると書かれている
- こうしたチップは安価で低消費電力かつ堅牢だが、グラフィック処理の余裕は少ない
- 384x288 ディスプレイでもピクセル数は約 11万個 あり、AVR のメモリに載せるには大きすぎる
- その代わり、160x128 や 128x64 OLED のようなより小さな画面のほうが実用的で安価である
- こうした画面では、手描きの ピクセル効率の高いフォント が有利になる
- 近いサイズでレンダリングした ベクターフォント も比較されている
- そのベクターフォントは実際には高さ6ピクセルだが、文字はより細い
- アンチエイリアシング、数メガバイトのコード、1MB のフォントデータを使っても、350バイトの手作りフォントより結果が劣る
実際の画面とさらに小さいサイズの実験
- 実際のピクセルは完全な正方形ではないため、画面上での見え方は上部のレンダリングと正確には一致しない
- サブピクセルが生む 疑似ドロップシャドウ効果 は好意的に評価されている
- 白黒ディスプレイではこの効果はないが、それでも予想以上になめらかに見える
- ピクセル間の隙間は
eとgをよりそれらしく見せる- 同じ効果をもとに、さらに小さなフォントの可能性も続けて探っている
- 3x5 は妥協なしの最小解像度ではないが、かなり良好に読める
- このサイズではグリフが 32,768個 あり、そのうち 27,904個 が相互に識別できる
M、W、Qは不利になるが、Oと0はなお区別できる- 画面に 50%多くの列 を入れたい場合の選択肢になりうる
- 3x4 でもまだ読めるが、制約は大きくなる
- グリフは 4,096個、そのうち 3,392個 が相互に識別できる
- このサイズでは大文字と小文字を区別できないため、限られた空間で最も合うスタイルを1つ選ぶ
- 数字の表現力も落ちるが、まだ実用になる
- 3x3 では数字の損失が最も大きい
- グリフは 512個、そのうち 400個 が相互に識別できる
- 文字は重複なくある程度見分けられる
- 実際のハードウェアに表示すると、このフォントは大きく改善される
- 2x3 は無理がある水準に近い
- グリフは 64個、そのうち 44個 が相互に識別できる
- ほとんどの文字は見分けにくく、重複も多い
- 最下段は
"Hello World"である
- 縦横比を反転した 3x2 は 2x3 よりはるかに良くなる
- このサイズでもグリフは 64個、そのうち 44個 が相互に識別できる
M、W、N、Q、G、Pのように横方向のディテールが必要な文字が、E、Fのような縦方向のディテールより多いため有利である- 最下段は
"you can probably read this"で、目を細めたり縮小して見れば読める
- 2x2 は完成度を比較するための対象としてのみ残されている
- 可能な 2x2 画像は理論上 16個 だが、1つは空白で、5つは別のグリフをずらしてコピーした形なので、実際には 10個 しか残らない
- 数字全体を表現できる程度ではあるが、元の形に似ておらず、フォントというより 秘密コード に近い
3件のコメント
有益な情報をありがとうございます。急に欲しくなりました。
ここに日本語をどうやってねじ込めばいいんでしょうか（泣） プエク
Hacker Newsのコメント
サブピクセルレンダリングを使えば、1x5でも十分可能だ https://www.msarnoff.org/millitext/
[2x5-HP-Z24n-G2] https://i.imgur.com/yLyrpfg.jpeg
[1x5-HP-Z24n-G2] https://i.imgur.com/Z7kH005.jpeg
[2x5-Innolux-N156HCA-GA3] https://i.imgur.com/F4Ypxwj.jpeg
[1x5-Innolux-N156HCA-GA3] https://i.imgur.com/etkot5o.jpeg
[1] https://jp.ext.hp.com/monitors/business/z_z24n_g2/
[2] https://www.panelook.com/N156HCA-GA3__15.6__overview_33518.html
それと同時に、自分の画面がものすごく汚れていることも分かった
5x5はかなり良く、3x5も悪くないが、どちらもASCII全体は収まりきらない
実際のサイズにも少し錯覚があって、文字間隔まで入れると実質6x6または4x6グリッドが必要になる
なので私は https://github.com/fcambus/spleen のSpleenがかなり好きだ
ここにはASCII全体をサポートする5x8フォントがあり、ほとんどのグリフは実質4x8に横方向の間隔を含めた形になっている
自分のプロジェクトではこれを改変して全グリフを4x8に揃え、その結果、5x9グリッド上で各文字の間に横・縦1ピクセルの間隔を常に確保しつつ、見栄えよくレンダリングできた
ハードウェアで解決するなら80 column cardを買って、きちんとした80カラムテキストを使えばよかったが、モニター側もそれに対応している必要があった
たいていの超小型フォントは、1:1表示でざっと読むには本当にひどい
以前ゲーム用のMODを作っていたとき、非常に小さくて詰め込めるフォントが必要で、3x3、3x5、さらには2x5までいろいろ試したが、どれも読むのがつらすぎた
結局、zephram作のGremlin-3x6を見つけたが、高さが1ピクセル余分にあるとはいえ横方向は依然として非常にコンパクトだった
何より標準ラテン文字の識別性が高く、大きく拡大しなくても十分読めた
残念ながらzephramがFontStructのアカウントを削除したためフォントもすべて消えてしまったが、自分のMODリポジトリにコピーとCC0ライセンスを残してあり、実際のレンダリングはスクリーンショットで確認できる
[0] - https://fontstruct.com/fontstructions/show/1488093
[1] - https://codeberg.org/janAkali/isaac-extended-icons-mod/src/branch/master/assets/fonts
[2] - https://codeberg.org/janAkali/isaac-extended-icons-mod/media/branch/master/assets/screenshots/screenshot.png
CJK文字についても似たような議論があった
https://chinese.stackexchange.com/questions/16669/lowest-pixel-resolution-needed-to-support-chinese
作者がこれを見るなら、小文字のtは横棒の上にピクセルを1つ追加したほうがよさそうだ
今の形だと大文字のTにかなり似て見える
それでも全体としてはとてもよくできていて、共有してくれたことに感謝したい
x
xxx
x
xx
xx
x
x
x
xx
4x4ではE, M, Wをきちんと描くには足りないと言っていたが、実際には5x5でもeをきちんと描くには足りない
小文字を大文字より低くしたいなら、縦ピクセルは最低6個必要で、ディセンダまでちゃんと入れるなら最低7個は必要だ
厳密に言えば、gやyがベースラインにかかりつつ水平ディセンダを区別できるようにするには8個あるほうがよいが、ここでは妥協可能に見える
そして実際には、文字の下や横に目に見える間隔を取るには、結局1文字あたり最低でも8x6ピクセルは必要になる
自分の目には、上部の空白がある程度埋まっていて読みやすく、長い文の中では文脈で十分に把握できそうだ
もちろん完璧ではなく、上の拡大されたきれいなピクセル例では不自然さがより目立つが
ピクセルをon/offの2状態だけでなく多段階グレースケールにすると、さらに小さいサイズでも読めるテキストを作れる
ただしここで重要なのはlettersではなくtextだという点だ
個々の文字はぼやけすぎていても、人間が文脈から推測して読めてしまう
しかもこの方法には、特別に設計されたフォントすら必須ではない
例: https://imgur.com/a/text-80-characters-per-line-240-pixels-wide-AlYrnSS
ここでは文字間隔まで含めても、1文字あたりの平均幅は3ピクセル程度しかない
LINCミニコンピュータのOSであるLAP6には4x5フォントが入っていたが、小文字はなかった
昔C64でソフトウェア的に80カラムを実現しようとしていた試みを思い出す
3x7ピクセルのグリッドを使い、1行と1列を間隔用に空ける方式で、実際に商用製品にもいくつか採用されていた
https://www.pagetable.com/?p=901
4×8文字セットを読みやすく見た目よく作るのは簡単ではなく、文字間に1ピクセルの間隔が必要なので、実質的に文字幅は3ピクセルしかない
そのためMやNのような文字は特に難しい
M、dotted zeroを諦め、U/V/Yの区別も弱くなるなら4x5や3x5も可能だと言っていたが、私は3x5でも十分実用的だと思う
https://robey.lag.net/2010/01/23/tiny-monospace-font.html