imagine YOKOHAMAフォントを実用しよう

imagine YOKOHAMAフォントは横浜市が制作したヨコハマをイメージしたフォントだ。

ダウンロードは簡単だし、使うのも特に問題はない。

このフォントの特色は「漢字は横浜市と18区の分しかない」ということである。横浜市神奈川区は書けるが神奈川県横浜市は書けない闇フォントとも言われている。

なかなか強烈だ。そして困る。 もちろん、イラストレーターなどで好きに組み合わせられる状態であればどうとでもなるので気にならないが、テキストフォントとして選択してしまうとimagine YOKOHAMAが持っている漢字と持っていない漢字の落差が激しい。

よりにもよってごく少数漢字を持っている上に、その漢字がまたちょっと変わったデザインだったりするので組み合わせもなかなか厳しい。 漢字を持たないフォントよりもずっと厳しい。

LinuxならばFontConfigがあるから任意のフォントを組み合わせることができる。 できるはできるのだが、それで解決しないのがこのフォントだ。「明朝体と組み合わせればいいんでしょ」と思うかもしれないが、だいたいどの明朝体と組み合わせても違和感激しい。

Linuxで使えるフリーの明朝体はだいたい

  • さざなみ明朝
  • IPA明朝 / Takao明朝
  • 梅明朝 / 花園明朝
  • Source Han Serif JP
  • さわらび明朝

あたり。あとは、こころ明朝体とかはんなり明朝体とかもあるけれど。

こころ明朝体やはんなり明朝体を指定することはあまり進められない。 確かにある程度の漢字は持っているが、これらのフォントは持っていない字を空グリフにしてしまっているため、これらのフォントに含まれない字は空白として表示されてしまう。

梅明朝に関してはかなりウェイトが細い。組み合わせたときの違和感は強い。

IPA明朝は字形が近いため、違和感が少ない。 ただし、ウェイトが違うため漢字とそれ以外で馴染みが悪いことになる。

Source Han Serif JPはそれなりに違和感がない。

さわらび明朝はややウェイトが太く、その点では違和感があるが、字形は近い。

というわけで私のお勧めは

である。

imagine YOKOHAMA フォントに源ノ角明朝を組み合わせた

Linuxで将棋倶楽部24 (Java Web, jnlp) アプリを動かす

概要

日本将棋連盟が運営する将棋倶楽部24はなかなかレトロなシステムを採用している。

Webでjava Appletという構成だが、まぁ当然ながら現代的な環境では動かない。

で、アプリ版があるのだが、「Windowsだけか…」と思いきや、Javaで書かれているのでLinuxでも動いたりする。 だが、ひと工夫は必要だ。

Java Web Start (jnlp)

Iced Teaという名称でおなじみのJavaのweb技術だが、ウェブブラウザプラグインを介してでなくともJavaが起動することができる。

コマンドはjavawsである。 ではjavawsに引数として渡せば動くのか?

javawsコマンドはIced Teaに含まれているのだが、Iced TeaはデフォルトのJava環境を使用する。 そして、OpenJDKだと7でも8でも9でも10でも動かなかった。

Oracle Javaにもjavawsが含まれている。 こちらなら起動できる。

$ /usr/lib/jvm/java-8-jre/jre/bin/javaws 24TokyoDojo.jnlp

Java Web Startのフォント改善

一見して「うへぇ…」となるフォントが表示される。

Java Web Startの場合オプションが渡せないのでちょっと面倒だが、環境変数にセットしてあげれば大丈夫だ。

先程の起動スクリプトに追加してあげよう。

しかしこれでもロビーのフォントは改善されなかったりするのだが。

openJDKだと結構きれいなフォントで出るんだけどなぁ…

Cinnamonのシステムサウンドはwavが再生できない

だいたいWindowsのシステムヴォイスはwavなので(最近はwav以外も再生できるけど)高確率でハマるトラップ。

FLACは“sound file”の候補に出ないのに対して、wavは選択可能であるにもかかわらず再生できない。

Ogg VorbisならOK。KDE Plasmaもそんな感じだった気がするので、「LinuxのシステムサウンドはOgg Vorbis」で。

Mimir Yokohamaに用語集機能

Mimir Yokohamaに用語集機能が追加された。

用語集機能はACCS(PureBuilderに取り込まれる以前の)やAki PHP Content Collection時代に実装されていた。

シンプルにACCSではJavaScript+Ruby/CGIで、本文エレメント(テキストノード)を探索し、文字列を送信してRubyで置き変えたものを返してもらい、innerHTMLを置き換える方式だった。

APCCでは単純に力技で置換えていた。

PureBuilderではこの機能を実現していなかった。 正確には一時期実装していたこともあるが、十分な質でなかったのだ。

そしてついに復活した用語集機能。

Pre Pluginsで処理することも考えたが、Post PluginsでRubyで処理している。

「辞書をワード長が長い順に並べ替えて|で結合し、正規表現としてコンパイルして置き換える」という手法はかつてのコードで考えたものである。

用語集のページも単純な手法でMarkdownを生成している。

で、今回もライブラリなしのPureJSで処理している。 今回は44行ほどだが、18行は共有化できるものなので、もう少し短くすることも可能だ。 DHTMLのお手本のような初歩的なものである。

Event.stopPropagation()Event.stopPropagationと書いて悩むはめになったけど。

LuaTex-jaでNumber too big.エラーがようやく解消

LuaTexで日本語ドキュメントクラス(ltjsarticle, ltjarticleなど)を処理すると

! Number too big.
ltj@@jfont ->luafunction ltj@@jfont@inner 

l.53 \kanjiencoding{JY3}\selectfont

と言われてしまう、という問題が続いていた。 Manjaro Forumで質問したところ、再現するけどupstreamへ、ということだったのでLuaTeX-jaのほうにご報告させていただいたところ、チケットを切っていただいた

Manjaroではつい先日Texliveが201804にアップデートされたが、この問題はLuaTeX-jaが201806として解決してくださっている。

このため、

$ git clone 'https://scm.osdn.net/gitroot/luatex-ja/luatexja.git'
$ sudo rsync -r luatex-ja/src/ /usr/share/texmf-dist/tex/luatex/luatexja/

とすればとりあえずこの問題は解決する。

だが、今度は

! Undefined control sequence.
\lltjp_um_unmag_fsize: ...@preadjust@extract@font 
                                                  \cs_gset_eq:NN \lltjp_um_f...
l.106 \begin{document}

なんて言われてしまう。 これは、

ltjsarticle + unicode-math で をしていないときに起きるエラーのようです. 別チケットにします.(#38372)

とのことで、チケットを切っていただいた

現在のところkitagawa_testブランチになっているが、恐らく近日中に取り込まれるだろう。 なかなか長い戦いだったが、ようやく論文や教材の清書も捗るというものだ。

ちなみに、この影響でgendoc-pandoc.zshのほうはMathfontに対応した。

DPIと画面サイズとスケーリングとピクセルの話

概念の確認

今やあまり意識されることはないのだが、改めて言うと

  • ディスプレイは多数のドットからできている
  • 1インチ辺あたりいくつのドットがあるかというのがDPIである
  • であるから、DPIというのはXYがある。 ちなみに、ThinkPad X1 Carbon 2017は143x158DPIである。 (ppiといったりもする)
  • このためドットの実寸(正確に言えばドット間隔の実寸)はドット数が多いほうが、そしてディスプレイサイズが小さい方が小さくなる
  • ドット数が一定である場合、ディスプレイが大きくなるほど密度(解像度)は下がる
  • 逆にディスプレイサイズが一定である場合、ドット数が増えるほど密度(解像度)は上がる
  • ピクセル数はディスプレイ表示上の絶対数で、その実寸は変動的
  • cm, inch, mmといった単位は実寸上の絶対値で、実際に何ピクセルで描画するかは変動的
  • ラスターグラフィックス、あるいは固定的ピクセル数で描画されるUIは解像度が向上すると実寸としては小さくなる
  • ベクターグラフィックス、あるいは固定的実数値で描画されるUIは解像度が向上すると描画に使用するピクセル数が増加する

論理上の振る舞い

もともとWindowsは96dpiに固定的に設定されていた。 つまり、実際のディスプレイのDPIがどうであるかということに関係なく 1inch = 96pixels という計算をしていたわけだ。 これにより実数をピクセル数に変換していた。

このことから、また固定的ピクセル数でUIが書かれていたことも相まって、基本的に「解像度が上がるとありとあらゆる部品が小さくなる」という現象が起きていた。 Macも72dpiに固定されていて、同じような事情だった。

Windowsは可変値だが、現在Macは72dpiとして計算しつつ、1ポイントは2pxで表示するように変更された。

正しいのは明らかに正しいDPIを設定できるようにすることである。 というよりも、ディスプレイサイズとピクセル数がわかっていれば正しいDPIが算出できるはずだ。 ディスプレイサイズを論理サイズ(24インチとか)から算出するのは難しいが、そもそもどの製品も同じではないので、メジャーで測れば1分もかからない話だ。

実際、Linux(Unix)においてX Window Systemはそのような方式を取っている。

そしてその上で実寸値で指定するか、あるいは画面に対する相対値で指定すれば画面密度によらないスケーラブルな指定が可能だ。

一般的にウェブUIはピクセル数で指定されている。 文字のような流動的情報はインチで指定するほうが一般的だが、これに従うと高解像度ディスプレイではUIは小さいが文字の大きさは正しくUIに書ける文字が減る、ということになる。

現実のスケール

ところが、現実はそうなっていない。

仕方ない部分もある。 例えばパソコンの場合は、13インチでも15インチでも、21インチでも24インチでも「だいたい100から115dpi」あたりに落ち着く。

これを基準にすると、5インチやそこらで400dpiを越えるスマートフォンが困ってしまう。

これは、パソコンを基準に実寸値で表すと、例えば「幅10インチのウィンドウ」といった場合、5インチのスマートフォンでは2画面分の幅があるすさまじく見づらいUIができあがる。

対してピクセル数で表すのもかなり危険だ。 例えばMimir Yokohamaのウェブサイトは900px幅であり、FullHD液晶の場合半分よりちょっと小さいくらい1なのだが、例えば手元のAxon7の場合WQHDなので幅は1440pxある。だから画面の幅の1/3くらい、実寸では5.18cm = 2.03937inchだが、900pxというと3.2375cmになる。

3.2375cmのウィンドウ、しかもサイドバーつき。視点から近いといってもあまりにも小さい。

スマートフォンをパソコンと同じ基準にするのは、実寸値だろうがピクセル数だろうが、かなり難しいわけだ。

じゃあどうしたか、というと、1px=1ピクセルじゃなくしてしまった。

なにを言っているか意味がわからないだろう。

実はMacも同じで、「1ポイントを2ピクセルで描画する」といったが、実はMacでは「1ピクセル指定しても実際は2ピクセルで表示する」ようになっている。 「密度が高いから従来の倍で表示しちゃおう」というわけだ。実際、Retinaディスプレイは180dpiとかあるので、従来のラスターUIをベクターUIのように扱って144dpi相当で描画されることはそれほど困らない。

技術に明るくないウェブエンジニア諸兄はCSSにこんなことを書いているかと思うが

何も疑問に思わないのだろうか。 1080pxをこえているならスマートフォンでは満たさない可能性が高いが、799pxなら今のスマートフォンは大概満たしているだろう。 だが、実際スマートフォンでこれが適用される可能性はかなり高い。

基本的に現代では96dpiを基準にスケールしている。 つまり、実際には180dpiくらいあるディスプレイなら、1ピクセルを倍で描画する。言い換えると、あたかもピクセル数が半分しかないディスプレイであるかのように扱う。

これは正しいのだろうか?

実際は、結構困る。 というのは、UIでピクセルで指定できない場合というのは普通にあって、この場合画面全体のピクセル数は「本当のピクセル数」を回答する。 これに基づいて割合を決めてピクセル数指定すると実際ははみ出してしまったりするのだ。

また、例えばThinkPad X1 Carbon 2017だと約1.4896倍にスケールする2のだが、900pxは1341px、1080pxは1608pxで表示されることになる。 ディスプレイ全体では1920pxなので、もちろん画面には収まるのだが、タイルした場合は1341pxは画面の半分に収まらないのでサイドバーは表示されなくなる。 「タイルしたときにはギリギリサイドバーが表示されたほうが良い」という私の考えは無碍にされてしまうわけだ。

これは12インチクラスのモバイルラップトップだとさらに厳しい。ThinkPad X280は12.5inchなので計算上は10.9inch->176dpiとなり、 12.1inchのLet’s Note SZに至っては10.5inch->182dpiとなる。 この計算においては、ThinkPad X280の場合幅1047px扱いとなり、1080pxですら満たせない。Let’s Note SZに至ってはギリギリ1000pxを満たす程度だ。

色々難しいのには理解を示したいところだが、現実問題としてこれは望ましくなく、「自分に使いやすい嘘DPIを設定する」以外になくなってしまう。

また、この事情により、以前はスケーリングを想定してフォントサイズはピクセル数からポイント数へと動いてきたのだが、 現在はスクリーンフォントはピクセル数で指定したほうが柔軟にスケールしてくれたりする。

個人的な所感

嘘DPIを設定するようでは、せっかくDPIが設定できることが無意味になってしまうし好ましくないと思う。 そもそも、96dpiを基準に固定したまま何倍にしよう、というのはVGA時代の失敗の繰り返し以外の何者でもないとも思う。

おおよそ正しいアプローチなのだから、DPIとスケール倍率という概念を分離できなかったものか。

実はGNOMEはDPIの設定がなくて、DPIを一切尊重しない。 そのかわり

$ gsettings set org.gnome.desktop.interface scaling-factor 2

のようにしてスケールできるのだが、このスケール、整数しか指定できない。 せめて1.5を指定させてくれとものすごーく言われているのだが(13.3inch, 14inchクラスでFullHDだと140から150程度なので1.5がちょうどよい)、対応の気配はない。

一方、KDE PlasmaはGTK+アプリケーションであっても適切にスケールしてくれるが、あくまでDPIによって自動的にスケールするだけで倍率の指定はできない。

現状で理想的なのは

  • DPIは正確なDPI値を算出する。この状態ではinchやcm指定は厳密に適切な値で表示される。 グラフィッカーには便利な状態
  • これによって自動的にRASTER_SCALEACTUALSIZE_SCALEが表示として倍率として設定される。これによって現在と同じ状態になる
  • RASTER_SCALEはディスプレイの論理ピクセル数に影響する。 つまりRASTER_SCALE=2の状態でFullHDディスプレイなら、水平ピクセル数は960だと回答する
  • RASTER_SCALEを手動設定可能とする。ユーザーは自動設定された値(デフォルト値でもある)を基準に好みに合わせて動かす。これに伴うディスプレイの論理ピクセル数も表示すると親切。
  • グラフィッカーのためにACTUALSIZE_SCALERASTER_SCALEと切り離して設定可能とする。ACTUALSIZE_SCALE=1にすれば1インチは1インチで正しく表示してくれる。

だと思うけれど、きっと誰も聞き入れてくれないだろう…

なお、4kディスプレイにしたWindowser向けにアドバイスとして「このままだと文字が小さいので解像度を1920×1080に設定すると解決するよ」と言っているのをかなり見るのだが、もはやこれは頭痛が痛い…


  1. 「半分よりも小さい」のは、フルHDディスプレイでタイリングしたときにサイドバーを表示させるためだ。

  2. これは、X Window Systemで正確なディスプレイサイズを入力し、精密にスケールできるKDE Plasmaを使った場合の話である。

なにを書くかでフォントも好きに選びたい (エディタの設定使い分け)

フォント関連の話が続くが、個人的に好きな話題なのでご容赦願いたい。

私はエディタの特性によってエディタを使い分けている。

あくまで「多くの場合、基本的には…」という話だが、起動時間は

“Mousepad < Leafpad < medit < GEdit < Kwrite < Kate < Geany < VSCode < Atom”

ハイライトニングは

“Laefpad < Mousepad < medit < Gedit < Geany < Kwrite = Kate < VSCode < Atom”

コーディング関連機能は

“Laefpad < Mousepad < Gedit < medit < Geany < Kwrite = Kate < VSCode = Atom”

という感じである。

コーディングに使うものは、「本格的なコーディング, 簡単な修正, 設定ファイル」の3種類くらいあれば良いものだが、 微妙な特性の違いから使いわけたいケースがある1

特殊な用途によって使い分けたいケースがあるのならエディタで分けられないケースがある。

そこでフォントごと設定を使い分けるのがどうかを述べる。

Leafpad

$XDG_CONFIG_HOMEで使いわけることは可能だが、インターフェイス系の表示も乱れる。使い分けは難しい。

Leafpadは日本語文字コードを自動的に判別する。 常にエンコーディングをUTF-8に変換する、というポリシーを持っている場合は気にしなくても良い部分ではあるが、エンコーディングを維持したまま開きたい人にとっては数少ない選択肢となる。

Mousepad

$XDG_CONFIG_HOMEで設定ディレクトリを間接的に指定できる。

Medit

細かなコントロールがしやすいMeditだが、設定ファイルの指定オプションはない。

$XDG_CONFIG_HOMEも尊重しないので、設定ファイルを指定したい場合は$HOMEを設定する必要があり非常に使いにくい。

Geany

-c オプションで設定ディレクトリが指定できる。

Gedit

$XDG_CONFIG_HOMEで設定ディレクトリを間接的に指定できる。

Geditは標準入力を読むこともできる貴重なエディタ。

Kwrite / Kate

プロファイルにフォントを含められるようになっている。

プロファイルはカラースキームなのだが、カラースキームだけでなくフォントを含んでいるため、簡単に切り替えられる。 カラースキームは分けたくない場合は、元になるカラースキームをエクスポートすると、これをインポートすることでいくらでも増やせる。

ただし、欧文フォントを使って合成する場合、ベースラインや高さによっては文字が切れてしまったり、ガタつく場合もある。

Atom

環境変数$ATOM_HOMEで指定できる。

Visual Studio Code

--usr-data-dirオプションが利用可能。

kwrite/Kateが使い分けやすいが、フォント合成にやや難がある。 最近は私はエディタ自体で分ける方向だ。

なお、私が使っている中で最も特殊なことを要求するのは、小説を書くときである。


  1. といってもそんなケースは相当に減っている。kateが持っているようなミニマップやブロック選択もAtomやVSCodeならできるようになっているし、最近はどちらもKateよりシンタックスハイライトがうまくいかないということが減っており、「Kate/Kwrite/Gedit を選択してうまくいかなかったら時間や速度を諦めてVSCodeにする」という手法が成立しているからだ。

Google Chromeが7月のversion 69でSSLを要求

どうなるのか

Google Chromeが7月にSSL(HTTPS)でないサイトに対して警告するようになる、という話を聞いたので、現在Developer Buildのversion 69をインストールして試してみた。

内容はIT Mediaの記事が正しかった。 つまり、

  • 従来は「HTTPSサイトは表示」だったものを「HTTPサイトは表示」に変更
  • version 70からはHTTPサイトでのフォーム入力時は警告表示

日経BPの記事をみると、まるでSSL署名が正しくないときのような警告がなされるかのように読み取れるがそんなことはない。

話はこういうことだ。

もともとはHTTPが標準だった。HTTPSであることは特別であり、故に「保護されています」と表示していたわけだ。 しかし、今後はHTTPSが標準であるため、いちいちHTTPSであることは強調せず、HTTPであることは逆にリスクがあることを示す、というわけだ。

この変更は正しいと思う。 対応した環境でブラウジングしているのに、HTTPではなくHTTPSであることで困る、ということは考えにくく、HTTPSであることに対してわざわざ注意を引く必要はない。 むしろHTTPであることはリスキーな状態であり、注意を示しておくべき状況だ。 特にフォーム入力を伴うときは警告すべき状況だといっていい。

状況 現在 version 69 version 70
HTTP 表示なし 「保護されていません」(グレー) 「保護されていません」(グレー)
HTTP + フォーム入力 表示なし 「保護されていません」(グレー) 「保護されていません」(赤)
HTTPS 「保護されています」(緑) 鍵マーク(グレー) 鍵マーク(グレー)

極めて正しいように見える。

GoogleがLet’s Encryptを推進したこととも整合性がとれている。

ただ、それなら「スキームなしでアドレスを入力したときにHTTPでアクセスする」ということはやめるべきだし、 むしろ「http://と指定した場合でもHTTPSを試行する」べきではないのか。

どうすべきなのか

これからは明確にHTTPSが標準となっていき、現在HTTPSに対応していないウェブサイトは「リスキーである」という認知が進むだろう。 これは、事情がわからないユーザーがHTTPの「安全でないサイト」を避ける可能性があるということを含んでいる。

  • HTTPSに非対応はもはや論外。早急に対応すること
  • HTTPSトライはしてくれないので、レガシーデバイスを切り捨てるならHTTPアクセスは301を返すべき
  • HTTPS強制にするにしても、HTTPアクセスを許容するにしても、ヴィジターへの説明はしたほうがよさそう

一応、Mimir YokohamaではHTTPS強制で、HTTPはサブドメインで許容する予定。

フォント帳アプリを作る → Linuxフォントの闇に触れる

追記分について

日本ではあまりなじみのない欧文コーディングフォント(プログラミング向けフォント, モノスペースフォント)をなんでこんな苦労してるんだろうとか思うくらいの労力を掛けてカタログ作ったので、気合いれて紹介させていただく

ぜひ見ていただきたい。

はじまりはmonospace

フォント一覧として“monospaceフォントの一覧を作りたい”と考えたのだ。

アプリ自体は全フォント一覧も作れるようにしたが、monospace限定でも出力したい。 どのような方法があるかと考えた。

調べるとspacingの値を見ればわかるということはわかったのだが、spacingMonospaceProportionalのような文字列ではなく、90, 100といった値になっている。

とりあえず90100もおおよそmonospaceだということはわかったが、90を提示するがmonospaceでないフォントもある。

だいたい90100の違いはなんなのか…もしかしてQtのmonospaceフォント一覧に関係があるのか…

と調べていくといろいろわかってきた。

100FC_MONOの定数であり、Monospaceのことであるらしい。 90FC_DUALであり、幅を2種類持っているもののようだ。

確かに等幅和文フォントは “monospace” ではない。 “dualspace” である。

では等幅和文フォントのspacing100にした場合Qtウィジットもmonospaceとして認識してくれるのだろうか?

FontConfigの一覧はいじれない?

で、どうやらfontconfigの設定(fonts.conf)はフォントを “要求されたとき” には反映されるけれど、 “リストするとき” には無視されるようだ。

例えばこんな設定ファイルを作る。

Migu 1Mのspacing100(FC_MONO)になる。

% fc-match "Migu 1M" : spacing family
Migu 1M:spacing=100

けど、リストには入らない。

% fc-list :spacing=100 : family | grep -i migu

Foogothicもちゃんと認識はされているけど

% fc-match -a Foogothic : family | head
Anonymous Pro
Anonymous Pro
Anonymous Pro
Anonymous Pro
Migu 1M
Migu 1M
Bitstream Vera Sans
Bitstream Vera Sans
Bitstream Vera Sans
Bitstream Vera Sans

リストにはない。

% fc-list | grep -i foo

90(FC_DUAL)100(FC_MONO)として認識させると、フォントに設定されている幅を無視するアプリケーションが存在するため、リストに入れてくれるわけでもないのならばデメリットしかない。

欧文フォントを和文で使いたいという場合には和文フォントを加える形にしてあげれば良いのだが

問題はQtである。

QtはMonospaceフォントとしてFC_MONOの値よりもspacingが大きいフォントを提示する。

問題は、FC_MONO100であり、FC_DUAL90であるため、FC_DUALなフォントは提示されない、ということだ。

この問題はバグとして報告されているのだが、今以て解決していない。

現状、monospaceを和文フォントにするか、適当な(使わない)欧文monospaceフォントをインストールして、その名前を利用して置き換えるくらいしかなさそうだ。

和文プロポーショナルフォントの話

実は和文フォントは一般的には「ラテン文字はプロポーショナル、全角文字は等幅」となっており、 日本語部分までプロポーショナルになっている「和文プロポーショナルフォント」というのはかなり珍しい。

このためか、ラテン部分がプロポーショナルであるにもかかわらず、spacing=90にしてしまうフォントが結構あるようだ。例えばDynafontとか。

なので、今回のスクリプトは-s 90とすればdualspaceフォントを含めてリストしてくれるけれども、必ずしも等幅フォントであるとは限らない。

今回のスクリプト

GitHubにアップした。

基本的にはFontConfigから値をひらってeRubyで埋め込んだHTMLを作るプログラムである。

プログラム自体は至ってシンプルなものだ。 どちらかといえばFontConfigに関する知識のほうが求められる。

READMEにある通り、うまく動作しない部分がある。 family名を指定しても正しく表示されないもの、fullnameがBoldなどになっているもの、 spacing=90といいながら等幅フォントではないもの1kanahaniが実態と合っていないもの、 などなど「フォントの情報って結構ガバガバだなぁ」と感じてしまう。 もちろん、フォントの情報から取っているわけで、がフォントにウソ情報を書かれたりするとスクリプト側では処理しがたい。

ウェイトの違うフォントが別ファイルになっているものと同一ファイルのもの、PlainやNormalなどRegularではない標準フォントウェイト名であるためにBoldが標準になってしまうもの、 ビットマップとスケーラブルがスタイルの違いになっているもの(例えばTelegramaはRawがビットマップ、Renderがスケーラブル)と厄介なものは色々ある。

欧文モノスペースフォント紹介

ボリュームがすごーく増えてしまったので独立させました

今回の件で気づいたこと

欧文フォントフェイスはかなり似ている

「読みやすいアルファベット」という条件がついていて、あまり標準的でない形は読みづらさにつながる。

結局、こうした条件のためにだいたいのフォントが似ていて、「ターミナル」「タイプライター」「セリフ」「サンセリフ」の4種類で分類できるような形状しか生まれてこない。

だが、微妙な違いが読みやすさにつながる部分もある。 現在人気のフォントはどれも似たようなサンセリフまたはターミナル体なのだけど、探せばちょっと変わったフォントもあるにはある。 人気のあるフォントの中ではMonacoやUbuntu Monoがちょっと変わったグリフをしている。逆にHackやDroid Sans Monoはものすごく普通。

商用フォントはいいぞ

Dark Mono, Operator, Native, Range Mono, Vivala Codeなど見比べて「おっ、いいな」と思うフォントは軒並み商用フォントになっている。

ただし、プログラマ、コーダーなど「日がな一日プログラムを書いている」人に関しては、これぞと気に入ったフォントがあれば買ってみるのも手ではないだろうか。 一日中向き合っているものだし。

欧文フォントも売られているものは高いものもある

Operatorなんて$199もする。 1書体のお値段としてはモリサワフォント並。 Pragmata Proもデスクトップ用 * レギュラー/ボールド/イタリックで€199

日本語フォントとは制作労力が雲泥の差なので、ちょっとえげつない値段だと言っていい。

Dark Monoも40ポンドとかなりお高め。

Atomはレンダリングが汚い

フォントのウェイトやサイズがばらつきやすく、autohintのようなガタツキも発生する。

うまく表示してくれるフォントを探すのにはずいぶん苦労した。

Atomでキレイに表示してくれるのはCPMonoなのだけど、CPMonoはコーディングフォントとして決して快適ではない。

日本語と混ぜるなら、agave, Fantasque, Fira Code, Luculent, Mesloあたりが快適。 私は結局Fira Code+Migu 1Mにした。

この組み合わせは非常に違和感がないが、後述のようにもう少し違和感があったほうが読みやすい。 その点、LuculentやMesloのほうが有力だった。

フォントの情報はいい加減

「漢字グリフはなくてひらがなだけなんだけど、haniは書いてあってkanaは書いてない」みたいなフォントもある。

商用フォントでも結構ザルである。 プログラムとしてはフォントの情報に基づいて処理するしかないわけで、「なんでここでそのフォントが?」と思うようなフォントが提示されたり、偽薬に提示されなかったりというのはここらへんに理由があるのだろう。

日本では紹介されていないモノスペースフォントはいろいろ

日本人としては日本語Glyphのないフォントは使えない、という感覚があるのだろう。 あまり紹介されることもない。

だが、実際にはプログラム中には日本語なんてほぼ使わないわけで、モノスペースフォントは日本語Glyphがなくてもあまり困らないし、 今はglyphがなければそれなりに処理してくれるのが普通なので別に好きに組み合わせても良いのではないだろうか。

日本で紹介されるものは人気があるというよりも無難なものが多く、実際にはもっと使ってみる価値のあるフォントは色々ある。

フォントレンダリングの微妙な差

KDEアプリケーションは割とにじみ強く太めに描画するため、キレイに見える。

Gnomeアプリケーションはもっとくっきり描画する。

どちらもFontConfigを使っているのだけど、描画ライブラリの微妙な差なのか、見え方が割と違う。 FirefoxとChromiumの描画差は気づきやすい。

そして前述のようにAtomはあまりよくない。

autohinterは諸悪の根源

以前は有効にするのが一般的だったように思うautohinterだけども、有効にするとガタガタになる。

フォントが寄る、ガタつく、崩れるなどのことがあったらautohinterを切るといいかも。

FontConfigはデフォルト設定がだいたいいい感じ

FontConfigの設定はディストリビューションによって作り込まれていることが多く、違いがあるけれども、 Arch設定だと色々いじってみても基本的にはデフォルトが良いようだ。

nobitmapと、サブピクセルレンダリングの配置くいらはいじったほうがいいけども。

日本語とアルファベットは差があるほうが見やすい

コーディング向きのglyphを持つ日本語フォント2の場合、統一感があるように調整されている。 「日本語とアルファベットの統一的デザインってなんだ」と思うかもしれないが、主にはグリフのボックスサイズと、線の太さである。

普通は「半角は全角の半分」となるように設計する。Source Code JPフォントの場合は全角は半角の1.5倍幅になっている。

だが、Linux環境ではこのような和文フォントのスペーシングがうまく適用されないことが多い。 Atomの場合和文フォントを指定すると縦には揃ってくれない。このことから、このようにメリットは少ない。

また、日本語にアルファベットを混ぜ書きするケース(スペースを持たないケース)においては、アルファベットは「検索(eyeboll-search)の対象」であることがあり、 区別しやすいほうが良いと考えられる。

このことを踏まえると、「日本語とアルファベットの統一感はなくても困らないし、むしろないほうが便利」だったりする。

おまけ: 今回のフォント画像に使ったコード

JavaScript組み込みHTMLのPandocテンプレートである。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="$lang$" xml:lang="$lang$"$if(dir)$ dir="$dir$"$endif$>
<head>
  <meta charset="utf-8" />
  <meta name="generator" content="pandoc" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
$for(author-meta)$
  <meta name="author" content="$author-meta$" />
$endfor$
$if(date-meta)$
  <meta name="dcterms.date" content="$date-meta$" />
$endif$
$if(keywords)$
  <meta name="keywords" content="$for(keywords)$$keywords$$sep$, $endfor$" />
$endif$
  <title>$if(title-prefix)$$title-prefix$ – $endif$$pagetitle$</title>
  <style type="text/css">
      code{white-space: pre-wrap;}
      span.smallcaps{font-variant: small-caps;}
      span.underline{text-decoration: underline;}
      div.column{display: inline-block; vertical-align: top; width: 50%;}
      body { padding: 50px; font-size: 25pt; }
$if(quotes)$
      q { quotes: "“" "”" "‘" "’"; }
$endif$
  </style>
$if(highlighting-css)$
  <style type="text/css">
$highlighting-css$
  </style>
$endif$
$for(css)$
  <link rel="stylesheet" href="$css$" />
$endfor$
$if(math)$
  $math$
$endif$
$for(header-includes)$
  $header-includes$
$endfor$
</head>
<body>

$for(include-before)$
$include-before$
$endfor$
$if(title)$
<header>
<h1 class="title">$title$</h1>
$if(subtitle)$
<p class="subtitle">$subtitle$</p>
$endif$
$for(author)$
<p class="author">$author$</p>
$endfor$
$if(date)$
<p class="date">$date$</p>
$endif$
<input type="text" size="20" id="FontForm" /><input type="button" value="Change" id="FS" />
</header>
$endif$
$if(toc)$
<nav id="$idprefix$TOC">
$table-of-contents$
</nav>
$endif$
<input type="text" size="40" id="FontName" style="border: none 0px; font-size: 26pt; background-color: #fff; padding: 5px; border: #39f double 3px; color: #333; margin-top: 2em; margin-bottom: 0.8em" />
$body$
$for(include-after)$
$include-after$
$endfor$
<script type="application/javascript">
  var fm = document.getElementById("FontForm")
  var nameBox = document.getElementById("FontName")
  document.getElementById("FS").addEventListener("click", function(e) {
    for (var code of document.getElementsByTagName("code")) {
      code.style.fontFamily = fm.value
      nameBox.value = fm.value
      nameBox.style.fontFamily = fm.value
    }
  }, false)
</script>
</body>
</html>

  1. Iosevkaはdualspace扱いになっている。

  2. そもそも合成でないフォントでそのようなフォントはかなり少ない。M+(VLゴシックとMiguもこのglyph)くらいではないだろうか。Source Han Code JPとOsaka等幅は専用に調整されてリリースされているものなので含めてもいいかもしれないが。

KDE Plasma5 * Conky

KDE Plasma5の場合、Conkyはwindow_typeによって

  • 表示領域をConkyに奪われる(ウィンドウが置けなくなる)
  • デスクトップをクリックすると裏に行く
  • 通常のウィンドウとして表示される

といった問題が発生する。 これらの問題は他のデスクトップよりシビアだ。

次のようにすることで、正常に表示・動作し、透過も機能する。

own_window = true,
own_window_transparent = true,
own_window_class = conky,
own_window_type = override,
own_window_hints = "undecorated,below,skip_taskbar,skip_pager",
own_window_argv_visual = true,
own_window_argv_value = 0,

新しい設定ファイルではyes, no ではなく、 true, false であることに注意してほしい。

KDE Plasmaとしてはウィンドウとして表示される形式が望ましいもので、own_window_hintsによって表示方法を制御する。