プロ仕様の Source Han Code JP

その他
[ プロ仕様の Source Han Code JP ]

Source Han Code JP(源ノ角ゴシック Code JP)の超絶プロ仕様に触れてみたいと思います。

作者による GitHub の README と Adobe サイトでの 記事 も合わせてどうぞ。

先に結論を書くと、一般的なターミナルでの日本語を含むコーディングの用途に適していません。

概要

Source Han Code JP 概要

良く分かる、大きな文字サイズで画像にしてみました。

一見、不自然には見えないかも知れません。

うん、でも、普通じゃないんですよ。

試しに、互い違いに配色してみました。

Source Han Code JP 市松模様

まだ、不自然には見えないかも知れません。

詳しく行きましょう。

プロポーショナルフォント

画像のように 3種類 の文字の幅が含まれています。通常の日本語等幅フォントの 2:1 に対して 1000:667:500 です。

このフォントの独自の幅をデザイン通りに表示できるのは、プロポーショナルフォントを扱えるアプリに限られます。通常の日本語等幅フォントを期待するアプリに強引に適用させても、デザイン通りの表示にはなりません。

プロポーショナルフォントとして扱わなくては、デザイン通りに正常表示されないフォント。それは、プロポーショナルフォントに類するものでしかないでしょう。

正確には不正確な字幅

思い切って 2/3(667 ユニット)字幅を採用することにしました。

1000 の 2/3 は 666.66… で 667 ではありません。

正確に667ユニット固定字幅に設定

全角文字との正確なインデントには向きません

README と記事を合わせて読むと、摩訶不思議で混乱しますね。通常の日本語等幅フォント用のテキストがズレる旨でなく、「ピッタリ 667 の設定」にしたが、その値に誤差があるという旨でしょう。

その誤差 667/1000 - 1000*2/3 = 1/3000 は、12px の半角欧文 80 文字分で 12*80/3000 = 0.32 つまりサブピクセル1つ分にあたります。

画像のように、実際には少ない文字数でもズレが生じます。大きな文字サイズでも、誤差を含めてスケールするので同様です。

Source Han Code JP 誤差

OpenType(PostScript 系)のフォント形式で EM 単位を 1000 とする、その慣習の中では 667 は最も 666.66… に近い整数ですが、1px 未満の文字の座標を精密に計算するアプリでは、その誤差が蓄積されて膨れあがります。

コーディングやターミナルでの利用を想定していながら、画面の大半を占める半角欧文に誤差があるのは、致命的です。

GIF 画像で比較すると、不快さが良く分かると思います。

Source Han Code JP 差分

6:4:3 の比を正確に表現できる EM 単位とすることは、不可能だったのでしょうか。

何か上手く補正しているのでは? という一般人の期待は打ち砕かれました。

変わる長さ

ウェイトを切り替えても文字列の長さは変わりません

文字列の長さ the length of text strings という表現で、横幅 width を意図しているのは、さておき。

1px 未満の文字の座標を丸めるアプリで試してみましょう。

Source Han Code JP 8pt-18pt

左は Windows 10 の ClearType でのメモ帳、右は Ubuntu 18.04 LTS の gedit (テキストエディタ)です。

画像の通り、ほとんどデザイン通りになりません。

ウェイトと違って、文字サイズを切り替えると変わるようです。

Windows 以外の、通常の日本語等幅フォントの 2 で割り切れない文字サイズ(ピクセル数)での現象に似ていますが、このフォントでは 1000:667:500 ≒ 6:4:3 なので、ほぼ 6 で割り切れない文字サイズで乱れます。13.5pt が 18px にあたりますが、文字サイズを整数ポイントで扱うアプリでは設定できず、乱れないのは 9pt の倍数に絞られます。

見方を変えると、こうしたアプリでは 1/3000 の誤差も1文字毎に丸められて蓄積されないので、6px, 12px, 18px, … の文字サイズに限定すれば、期待に応えてくれるのかも知れません。

ターミナルで使えない

README によると、ターミナルでの利用も想定しているそうです。

プロポーショナルフォントを指定したターミナル(端末エミュレータ)から、リモートホストに ssh で繋いで tmuxvim で左右に画面分割したそれぞれで日本語を含んだコーディングを、フォントのデザイン通りに表示・編集できる環境……?

スクリーンエディタや TUI の表示が崩れるのを 使える とは言いません。

文字の間隔が広いて一般的な等幅フォントと同じ配置になった表示も、期待通り (as expected) ではない 模様です。

文字の座標を格子状の文字単位の行と桁で数える VT100termcap の延長で、U+0020 半角空白の整数倍以外の幅を扱えるのか分かりませんが、このフォントが似合う凄腕ハッカーには朝飯前なのかも知れません。

思い

もともと読みやすさの観点から半角欧文はすこしコンデンスすぎると感じていたので思い切って 2/3(667 ユニット)字幅を採用することにしました一般的な半角(500 ユニット字幅)の等幅フォントにくらべ、全角文字との正確なインデントには向きませんが、読みやすさを確保しつつ使い方次第で様々な表現ができると思いました

運用次第でカバー できると、思ったそうです。

おや、過去形ですね。もっと簡素化しましょう。

「せんせー! もともと__だと感じていたので、思い切って__にしました。一般的な__と比べて、__だけど、__しつつ、使い方次第で__できると、思いました!!!!」

あ、はっ、はい?

冗談なのか、本気なのか、詭弁なのか、言葉の綾なのか、良く分かりません。

終わりに

リリースノートで InDesign や Illustrator や MS Office 製品での不具合修正が目立つのは、想定外の、コーディングと縁の薄いアプリだった為なのでしょう。

比較 GIF 画像を再掲します。

Source Han Code JP 差分

重ねて見ないと良く分からない程度なんだから大丈夫! と思える人には、もしかしたら、エンジニアよりビジネスの才能があるのかも知れませんね!

コメント

タイトルとURLをコピーしました