The Weekly Herald

　
　―――さあ、スタート。

　このLCDモジュール――F-51553GNBJ-LW-AB―――は、表示データRAM（いわゆるVRAM）と液晶の表示が以下のように対応している。↓
　※セグメントドライバ方向反転時

　ページアドレスとカラムアドレスを指定することで、任意のドットデータ(D0〜D7）にアクセスできるわけだ。D7が最上位ビットである。
　ひとつのバイトデータ（8ドット分）がカラムに―――つまり縦方向に―――配置されるのがポイントである。

　カラムアドレスは、LCDモジュールに表示データを書き込む度にインクリメントされる。よって、マイコンからは連続してデータを書き込むことができる。例えば、ページアドレス0・カラムアドレス0の状態で、0x00から0x09までの10個のデータを連続して書き込むと、LCDには以下のように表示される。
↓
　（ページアドレス0の）カラムアドレス0〜9まで順番にデータが書き込まれるのだ。
　ひとつの表示データは縦方向に描画される。それが横方向へ順に並ぶことになる。
　ちなみに、秋月電子で販売しているLCDモジュールも似たような構造である。あれはVRAMが2つあるので制御が少し複雑になるが、基本的には同じ表示構成をしている。
　カラムアドレスは、131（最大値）になるとそれ以上データを書き込んでもインクリメントされない。また、ページアドレスが自動的にインクリメントされることもない。よって、適宜ページアドレスとカラムアドレスを指定しながら描画することになる。
　そもそも、このLCDモジュールの制御ICにはカラムアドレスが132個あるのだが、実際LCDに接続されているのは128個である。残り4つは未接続なのだ。そんな未使用のカラムアドレスにアクセスしても無意味なので、注意すべきである。

　以上、今回使用するグラフィックLCDの表示データRAMと液晶表示の関係である。

　―――で、こいつでフォントを扱おうということなのだが、フォントのファイル形式には基本的に2種類あって、ひとつはビットマップフォント、もうひとつはアウトラインフォントである。ここではビットマップフォントを扱う。

　ビットマップフォントのファイル構造としては、BDF（Bitmap Distribution Format）、PCF（Portable Compiled Format）、そしてFONTX形式の3つが代表的なビットマップフォント形式のようである。フリーのビットマップフォントとして公開されているフォントの大体が、これらの形式で配布されていた。

　単純に「FONTX」と言ったらドライバのことを指すっぽいが、そのFONTXドライバで使用するフォントファイルのことを「FONTX形式の――」とか「FONTXファイル」って呼ぶみたいだ。
　FONTXについては、Lepton's Home PageさんのFONTXページにおいて、ドライバ（DOS/V用）とともに具体的なファイルフォーマットの情報などが公開されている。

　そして、既にウェブ上にはFONTX形式のフォントファイルをマイコンで利用するための解説ページがありました。
　Project C³（プロジェクト・シーキューブ）さんのテクニカルワークショップカテゴリ内にあるFONTX2形式のファイルをマイコンから利用するためのスタディページや、組み込みでFONTX2形式を使用するドライバを作成するページで、FONTX形式のファイル構造から、文字コードよりビットマップデータへアクセスする手順まで解説されているので、とても参考になると思います。
　よって、本記事ではFONTX形式のフォントファイルに関して、実際のビットマップデータがどのように格納されているのか、ということだけに触れることにします。

　ビットマップファイルなんて大体はそのハードウェアで描画しやすいようにデータが格納されている。FONTX形式も例外ではないのです。

　例えば、8×8ドットの美咲フォントの「海」という文字。この文字のビットマップデータが、FONTX形式ではどのように格納されているかというと。データの先頭から順に、
となっている。参考画像。↓
　ひとつの文字のデータサイズは8バイトだ。
　左の画像を見てわかる通り、ひとつのバイトデータが上から順に横一列の8ドットを構成している。

　なんだかこの時点で嫌な予感がするよね。

　いや、この字が海には見えない、とかではありませんよ。文脈効果で見える見える。

　もうひとつ、例として16×11ドットの赤城フォントを見ておく。同じく「海」の文字。この文字のドットデータの並びは、先頭から順に、
となっている。
　横に2バイト。それが縦に11行あるから、ひとつの文字を表現するのに22バイト使用している。参考画像。↓
　フォントデータは、左側から右側へ。そして上から下へという順番で表現されているのがわかる。
　ちなみに、横のドット数が8の倍数ではない場合、FONTX形式では余ったビットにはダミーデータとして0が入る。例えば横幅が15ドットのフォントでも、横方向に2バイト使用することになる。

　以上のように、もう一度言うがビットデータは左から右へ、上から下へという順番で表現されている。こうなっているのは、やっぱりその方がハードウェアに対して都合が良いから、なのだ。左上から右下へ描画していくというこの流れ。昔も今も、パソコンのディスプレイって大体そうだよね？

　しかし、それがここでは問題なのです。
　上で述べたように、このグラフィックLCDの場合、ひとつのバイトデータが縦8ドットに対して有効なため、このままでは上手く表示できない。
　表示できないというか、すごく都合が悪い。正しく表示しようとすれば、実際にデータを書き込む前に、ドットデータを並べ替えてやる必要があるからだ。
　並べ替える処理にしても、8×8ドットや16×16ドットといった縦横のドットサイズが8の倍数のフォントデータならともかく、それ以外のものを利用しようとした際は、処理がより複雑になってしまう。

　その解決策として、hamayan様のウェブサイトDeveloper's Placeのビットマップフォントを組み込みで使おう！ページが非常に参考になります。
　hamayan様は、FONTX形式のフォントファイルを、一旦パソコン上でC言語のソースに都合良く変換することで、より簡単にマイコンでビットマップフォントを扱っていらっしゃいます。なるほど。既に並び替えたデータを用意すれば、マイコン上ではもう並び替える処理は必要はありませんものね。
　さあ、このアイデアを見逃すわけにはいきません。

　―――ということで、私もこのアイデアを拝借させていただき、FONTX形式のフォントファイルのデータを（今回のグラフィックLCDで使いやすいよう）変換するプログラムを作成しました。縦横何ドットのフォントでも変換することが可能である。
　※プログラムの公開については未定です。自分で作成したプログラムですが、原案者は私ではありませんから。
　hamayan様よりプログラム公開のお許しをいただきましたので、近々公開予定です。（※とかいいながらずーっと公開していないことをお許しください）ソースコードと実行ファイルを公開します（実行ファイルはコンソールアプリです。また、参考に美咲フォントを変換した結果も添えています）。

　先ほどの8×8ドットの美咲フォントの「海」という文字のデータを、（今回使用するタイプの）グラフィックLCD用に使いやすく並べ替えると、データの先頭から順に、
となる。参考画像。↓
　それぞれのバイトデータが、横一列8ドットに対して有効だったものを、縦一列8ドットに対して有効になるよう変更したのだ。これによりマイコンでのフォント描画がグッと楽になる。
　データを先頭から順に書き込んでいけばいいだけだからね。
　変換前と同じく、一文字分のデータサイズは8バイトである。
　ただし、次に紹介する赤城フォントの場合、一文字分のデータサイズが、データの変換前に比べて変換後では増加する。
　これは、FONTX形式のフォントファイルの場合、フォントの横幅が8の倍数以外のときに余分なデータが発生してしまうのに対して、今回のような変換処理を行った場合、縦のサイズが8の倍数以外のときに余分なデータが発生してしまうからである。（余った部分にはダミーデータとして0を入れた。）

　例えば、赤城フォントの「海」の字を変換すると、データの先頭から順に、
となる。参考画像。↓
　16×11ドットの赤城フォントのビットデータにおいて、FONTX形式の場合は無駄なデータが一切存在しないが、変換処理を行うと、フォント下段のデータ上位5ビットがダミーデータとなる。
　その結果、一文字分のデータサイズは、変換前が22バイトだったのに対し、変換後は32バイト必要になるのだ。
　一文字につき10バイトって結構デカイですよ。赤城フォント（の全角文字 Ver 3.8）は全部で6877文字登録されているので、全文字を組み込むとすれば単純に約67kバイトのデータ量増加になる。ROMが少ないマイコンにはきつそうだ。まあ、外部にROMを増設すればいいんだけど。SDカードとかね。
　逆に、データを変換することによってデータ量が減るケースもある。6×8ドットのk6x8フォントなんかは、FOTX形式のままだと一文字につき8バイト必要だが、変換することで一文字につき6バイトでオーケーだ。この場合、全文字で約13kバイトの無駄が省かれる。
　そもそもデータを並び替えるのが主目的であるが、こんな面もあるよねという話。

　ドットデータの変換処理に関しては以上である。

　いよいよ実際にビットマップフォントをマイコンに組み込んで、グラフィックLCDに表示させてみよう。
　LCDに表示させる文字列はこれだ。↓
手元にあった国語辞典から引用したペンギンについての記述である。

　さあ。それでは実際の表示を見ていただこう。
　……。
　…。

　まず初めは、k6x8フォント。名前の通り6×8ドットのフォントである。↓
　6×8ドットという超小型サイズにも関わらず、読めますね……。
　おそらく私が事前に表示する文字列を明示していなければ、素読するにはちょっと厳しいでしょう。
　特に漢字はほとんど原型をとどめていません。
　しかし、それでもちゃんと読めてしまう不思議！！文脈効果ってすばらしい。


　次は、8×8ドットの美咲フォントだ。↓
　2ドット分の余裕からか、先ほどのk6x8フォントよりも読みやすく、文字のバランスも良いように感じる。
　ひらがなや片仮名は普通に読めますね。
　ただやっぱり、漢字は少し厳しいか……。

　以上2点、縦横のドットサイズが一桁のビットマップフォントである。漢字を表示するには少し無理があるが、このサイズ（128×64ドット）のLCDには丁度良いサイズかもしれない。
　しかしやはり読みにくい。たぶん文字同士を隣接させて表示しているからだろう。今度は文字同士の感覚を1ドットずつ空けて表示させてみる。
　こういう小さなフォントは元々読みにくい特性を持つが、文字同士の間隔を少しでも空けてやれば、もう少し読みやすくなるはずだ。

　まずはk6x8フォントを試す。
　文字同士の感覚を1ドットずつ空けて表示してみた。↓
　うん。フォント自体は変わっていないのに、なんだか読みやすくなったぞ。
　元の画像と比べると全然違う印象を受ける。
　やっぱり距離感って大切だ。

　続いて美咲フォントも同じく、文字同士の感覚を1ドットずつ空けて表示してみる。↓
　元々の表示と比べると、やはり間隔を空けたほうが読みやすい。
　写真ではあんまり効果がないように感じるかもしれませんが、実際に目で見ると全然違いますよ。
　小型のフォントでも、こうして文字同士の間隔を空けて表示してやることで、ある程度読みやすくすることが可能だ。描画処理がちょっと複雑になるけど。


　さて、続いて表示するフォントは、変換処理の項でも出てきた赤城フォントである。サイズは16×11ドットだ。↓
　一本一本の線がとても太く描かれていて非常に見やすい。
　縦11ドットという制限のためか、詰め詰めで表示させると一部上下の文字同士が接触したように見えてしまう。これは1ドットのマージンを空けてやれば問題ないだろう。

　ちなみに、ここで動作させているプログラムは、コンソールから入力した文字列をLCDに表示させるという単純なものなのだが、次々に文字を入力して、文字表示がLCDの一画面に収まらなくなると、画面が下にスクロールされるようになっている。↓
　スクロールしたことで、上段の文字が削れている。
8×8ドットや16×16ドットのフォントなら、このように中途半端に削れてしまうことはないのだが―――ただしマージン0表示―――、まあこれはこれで全く問題ない。
　しかしこのフォントの大きさは、このLCDの身の丈に合ってないよね。まあでもそれはLCDの使い方次第だろうが―――やはり8ドットから10ドットくらいのフォントが丁度いいのではないだろうか。
　もっと大きなドット数―――24ドットとか32ドットとか―――のフォントも、もちろん表示できますが、いくら見やすくなるからってあんまり大きくしても、ねぇ。
　あとやっぱり日本語が表示できるっていうのは単純に嬉しいですね。こんな小さなデバイスでも普通のディスプレイとして使用できそうな気がしますから。

　以上でLCDへの表示テストは終わりです。今回、この記事を書くにあたって使用させていただいたビットマップフォントは、フリーでの利用がフォント作者様より許可されているものを厳選いたしました。以下にリンクを記しておきます。

　美咲フォントおよびk6x8フォントは、Little LimitのFontページにて公開されております。
　赤城フォントは、小林 洋行様による赤城フォントページにて公開されております。


　以上で、グラフィックLCDシリーズ日本語フォント編終わり。

　関連記事。↓
　"グラフィックLCDモジュール 初編"
　"グラフィックLCDモジュール ハードウェア編"
　"グラフィックLCDモジュール ソフトウェア編"