ピクセルフォントを作る上で漢字に対応するのは大変なので（そして小さい漢字にはあまり個性が出ないので）、「パブリックドメイン」とされている「東雲〔しののめ〕フォント」を下敷きにできたら都合がいいと思って、BDF という形式で頒布されてるファイルを画像に変換してみました。
東雲フォントはこちら :
http://openlab.ring.gr.jp/efont/shinonome/
それぞれ「12 ドット」「14 ドット」「16 ドット」のデータだけど、画像では二画素の間隔（一画素のベアリング）を加えておいたのでタイルの大きさは 14・16・18。この画像もパブリックドメインとする。
字形に特徴があって、少し長体になってるみたい。「12 ドット」の字面は「11 × 12」。「14 ドット」の字面は「13 × 14」。「16 ドット」の字面は「15 × 16」。多分、横組みで表示されて縦方向に行間が加わるのを想定したのかな。（おまけに、横幅が奇数だと太さ一画素の線で「木」のような縦軸のある字を描きやすいよね。）
ピクセルフォントの字形を縮小するスクリプトを書いてみました。大雑把な処理なのでそのまま完成にはならないけど、下描きにはなるんぢゃないかな。
画素の縦列・横列に注目して、隣接する列の組の「削減抵抗」を評価し、抵抗が最も小さい二列を一列に重ね合わせる。抵抗は次のような感じで評価する :
・ 隣接する列の内容が似ていれば抵抗が小さい（各画素をビットとする排他的論理和を取って、白と黒で差のある画素が少ない）。
・ 端付近の列で黒画素がほとんどなければ抵抗が小さい（端っこが空ならそれを削る）。
・ 黒っぽい所より白っぽい所の抵抗が小さい。
・ 評価値が等しいなら左上に近い方を優先する。
結果的にフトコロが大きめの字形になる。図は東雲フォントに適用した例。
東雲フォントには
・ ちょっと長体
・ フトコロをあまり大きくしない
・ 左ハライをグッと伸ばす
・ 右上へのハネも長め
・ 左下の折り返し（「糸」の一画目・二画目のような転折）を大きく突き出す
・ ツクリの下端が水平線なら浮かせる
…といった特徴があって、全体的に「渋い」。それはそれで活躍の場があるけど、電子機器全般の画面表示では、特に趣味の電子工作とかで使われる小さい液晶表示器とかだと若干場違いな感じがする。行間を追加しないと縦横の空きの配分がおかしくなるし。もうちょっとモダン寄りの書体の方が こういう分野では使いやすい気がする。
あと微妙に変な字が所々ある。〈淫〉の形が大きさに依って違う。12‐ドットでは〈魁〉の点の向きが逆になってる。
字形を観察するに、東雲フォントは「k14」の書風を 12 画素と 16 画素にも敷衍〔ふえん〕した物っぽい。
日本語の漢字を収録したピクセルフォントが、字面の大きさとしてはどの辺りを担当できているか表に纏めました。但し、線の太さは一画素で、斜めの線は画素の辺ではなくカドで接するのを条件とする。ライセンスの自由度が高い物は青、そうでない物は茶色。JIS 第二水準まで揃ってない物は括弧で囲んだ。
MS ゴシックの埋め込みビットマップは自分では確認できていない。このブログ記事
https://uakira.hateblo.jp/entry/20051006
に基づいて記載した。
噂の中の人に拠っと、Windows Vistaベータ1のMS明朝/ゴシックには、新たに13ドット角(字面12ドット角)のビットマップフォントが埋め込まれてゐるといふ。 リコーフォントMLの2004年9月6日号に解説があるやうに、Windows標準の96dpi環境では今まで字面11ドット角のビットマップフォントデータ(9ポイント用のデータ)で10ポイントの文字が表示されったんだけっども、これが一回り大きいサイズ(字面12ドット角)になるのだと。 特にWebブラウジングの際に、追加ビットマップフォントの威力が発揮されることになるだらう。 画面上での読みやすさを前面に押し出したメイリオの宣伝の影で行…
日本語で常用する漢字がまともに描ける字面の大きさは、最低で「9 × 9」辺り。恵梨沙や Osaka 9 に見られる「8 × 8」は、厳しいけどまだ何とかなる。以降、小さければ小さいほど無理やり感が強まる（美咲や「Nu もち」がそれ）。
長体や平体が掛かる場合、例えば「8 × 10」や「10 × 8」にはほぼ「9 × 9」と同程度の表現力があるだろう。あまりにも変形してると当然ながら癖が強まるので、「普通な感じ」で読めるのは縦横比 120% ぐらいが限度だと思う（例えば「11 × 9」の字面を持つ「k12x10」はそれに当たる）。
画素数が大きくなると書体が個性を持つようになる。「一画素の線」が字面に占める太さが相対的に細くなるし、それ自体が特徴になる。無個性な書体として振舞えるような字面の上限は「14 × 14」ぐらいかな。「24 × 24」を超えたらアウトラインフォントの領分に近付く。
そんなわけで…字面の縦と横の差が 2 以下で、縦と横の平均が 8 以上 14 以下の漢字字形を公共的な資源として揃えられると嬉しい。
うーん、「要町‐改」（kaname-alter）の BDF‐ファイルが手に入らない。このパッケージ
https://build.opensuse.org/package/show/openSUSE%3AFactory/x11-japanese-bitmap-fonts
の説明に「kaname-alter を含む」と書いてあるけど、実際に開いてみると見当たらない。
This Package contains Japanese fixed-width fonts for X11. It contains the fonts knj10, kaname-alter, shinonome12, shinonome16, k14goth, Kappa20, kanji32, and marumoji. On top of that, it also contains bold, italic, and bold-italic versions of the popular Japanese fonts usually found in the /usr/lib/X11/fonts/misc directory of the standard X11 distribution and bold, italic, and bold-italic versions of iso-8859-1 fonts which fit nicely in style and width to the Japanese fonts.
https://src.fedoraproject.org/repo/pkgs/fonts-japanese/knm_new.tar.gz/065920714d022cfd225feb6d80b03238/
「knm_new」で検索したら、あったわ。あったけど、藪〔やぶ〕を踏み分けてる感じ…。
これが「要町‐改」の BDF から変換した画像。漢字は「12 × 12」の字面をミッチリ埋めるように描かれてる。（図では二画素の間隔を加えてある。）
なるほど、なるほど。東雲 12 を要町に重ねてみると、「要町を縮めました」という由来がよく分かる。これは必ずしも字形の改善ではないから、両方使える状態であるべき。
まだ画像を載せてなかったので…こちらが「M+」の漢字ビットマップ。それぞれ 10 画素と 12 画素（字面はほぼ「9 × 9」と「11 × 11」、但し縦線が上へ突出する）。
これは「出水〔いづみ〕ビットマップフォント」です（JIS X 0213:2004 の第一面の漢字）。なんか BDF の構造上、非漢字と漢字の領域で規則性がずれてて整形が面倒だったので、画像に載せてるのは漢字だけ。字面は「15 × 15」。
なんか「X11 に付属しているフォント」に含まれていた「jiskan16」の BDF は「FONTBOUNDINGBOX」の値が「16 16 0 2」になってるけど、これは「16 16 0 -2」ぢゃないのかしら。このままだと、全ての文字の描画範囲より下にベースラインがある事にならない ? …と思って調べると、安岡さんが配布している版は負の値になってた。うん、それなら分かる。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/ftp/fonts/
印刷標準字体に寄せて描くの、無駄な努力って感じ…。八よりソの方が描きやすいのに。しかも「JIS X 0213:2004 の例示字形」なんか字形の根拠にはならない。試しに従ってみてるけど。
「出水〔いづみ〕ビットマップフォント」を下敷きにして、JIS 第一水準の前半（第 16 区から第 31 区まで）を一巡して字形を作り、ザッと見直して少し整えました。これで一週間ぐらいかしら。
まだ不統一な所がある。部品の共通な文字を抽出して並べるシ組みが要るなあ。
JIS 第一水準を描いていくと、「日本漢字オールスター ! Choose your character」という気分で面白くなってくる（※）。お馴染みの字が勢揃いだ。（稀に「何でお前一軍にいるの」という感じの漢字もいるけど。）
※ ちょうど〈character〉には「文字」という意味があるし。
https://gitlab.chise.org/CHISE/ids/-/blob/master/IDS-JIS-X0208-1990.txt
わあ、「幹」が「⿰𠦝⿱𠆢干」ではなく「⿸⿰𠦝𠆢干」と記述されてる。（つまり「𠦝の右に、𠆢干を上下に重ねた物を置く」ではなく「干を左上から取り囲むように、𠦝𠆢を左右に並べた物を置く」と書いてある。）字源主義というのかな。フォント作りの補助として使うには色々と注意が要りそう。
圧が「⿰厂土」になってるのは多分間違いだな…。ほかのガンダレは「⿸」で表現されてるようだし。
GitHub ならアカウントがあるから直接突っ込めるんだけど。
漢字構成記述文字列を弄って、左側・上側・外側の部品が共通な漢字が集まるように並べ替えた文字列と、右側・下側・内側の部品で並べ替えた文字列を作った。
また、与えた画像を JIS X 0208 の漢字表と解釈し、指定された文字列に対応する字形を抽出するスクリプトと、その逆変換のスクリプト（与えた画像には指定された文字列に対応する字形が並んでいると解釈し、JIS X 0208 の漢字表を生成する）を作った。それぞれ「文字タイル貸出」と「文字タイル返却」と称する。これで部品の共通な漢字を並べて検討できる。
JIS 第二水準の「埒」（52 区 31 点）と「埓」（52 区 32 点）は何が違うんだ…そもそも「爪」と「ノツ」は普通は包摂されるから、何か特殊な事情で分かれてる筈だけど。52 区 32 点は多くのフォントで「ツ」の最後の拂いを不自然に長く作っている。
https://www.asahi-net.or.jp/~ax2s-kmtn/ref/jis_unification.html
https://www.aozora.gr.jp/hosetsu_kijyun/0208-6.6.3.2.-hyou.html
包摂規準 169 番で、この字だけ狙い撃ちで「ノツ」と「月」が包摂されてる。だったら「52‐31 は爪寸またはノツ寸で、52‐32 は月寸」という定義にしてくれたら綺麗だったのに。
「醤 — 醬」と「蒋 — 蔣」の立場も微妙。JIS X 0208 の 1983 年版で不用意に例示字形を変えて非互換変更になった、と 1997 年版の整理によって位置付けられているけど。
字体差として問題になるのは、ヘンの形とノツの形。「状」のヘンは包摂されるけど（包摂規準 162 番）、これは部分字体「状」だけに決め打ちされてて「将」には適用されない。一方、「ノツ」と「月」は JIS X 0208 においては「埓」だけ決め打ちで包摂されてて（169 番）、やはり「将」には適用されない。JIS X 0213 では、追加された包摂規準 192 番によって「ノツ寸」「爪寸」「月寸」が包摂されてる。
という事は、定義上、JIS X 0213 において「醤 — 醬」と「蒋 — 蔣」はヘンの形によって符号位置が区別されてて、ノツの部分は どれでもよい状態…だと思う。
ええと、それで、当初の問題である「埒」と「埓」については…包摂規準 21 番が制限なく「ノツ」と「爪」を包摂してるけど…「6.6.3.1 漢字の字体の包摂規準の適用」の「b」において、複数の区点位置を包摂するような適用はしないと規定されてるから、これによって除外されると考えたらいいかな。
手元のフォントの中では「メイリオ」が、ハライの長くない「ノツ」で「埓」を実装してる。
白湯さゆぬ
