アプリケーションに固有のfonts.confを使用させる

意図

私はどうしても、どうしても!!! ウェブサイトが無意味にフォントを固定してくるのが気に入らない。

いくらでもいいフォントはあるのに、よりによってなぜMS PゴシックだのArialだのHerveticaだの気に食わないフォントを強制されなくてはいけないのか。

「MS Pゴシックはないんだからいいじゃん」と思うかもしれないが、それでは済まない。 「完全にMS Pゴシックに決め打ちしているもの」というのも世の中には存在するので(一番はMSWord文書)どうしてもMS Pゴシックはメトリック互換フォントを設定せざるをえないのだ。

Arialに関してはUI部品に本当に使っていて、はみだすケースが少なくないので、変更はより難しい。

そうでなくても指定されるのは気に入らない。 必要ないのではないか。 私としては読みやすいフォントを使いたいのだ。

最も望ましいのはユーザースタイルシートで上書きすることである。 だが、ご丁寧にどのサイトもbodypではなくスコアの高いところにフォント指定してくれやがるのでそうはいかない。滅びてしまえ。

幸いにも私の場合プロファイル切り替えプログラムを使っているのでそのブラウザで見るサイトというのは決まっている。 だから手っ取り早いのはサイトで指定されているフォントをoverrideすることである。

実際、

とかやっているのだが、やはり弊害が大きく、条件は限定したい。

意外とイケてないFontConfigの仕様

FontConfigって結構イケてるソフトウェアだと思っていたのだけれど、そうでもない。

設定にXMLを使っている時点で微妙だし、その文法はさらに微妙だが、 環境変数のような動的要素は全然使えない。

XDG_CONFIG_HOMEだけは理解するのだけど、そのロジックはinclude内のprefix="xdg"である。 このprefixdefault (/)かxdg ($XDG_CONFIG_HOME | ~/.config)のどちらかだけ。 かろうじて~は使えるのだが…

条件式も書けないし、アプリケーションごとの設定もできない。 とにかく自由度が低い。というか、設計がイケてない。

方法はいくつかある。

例えば、~/.application.font.conf.d/をincludeするようにしておいて、 これをシンボリックリンクとして切り替える、というような方法だ。 だが、これは優先度が高いところでincludeするほど影響が大きく、制約される。

ただし、この方法ではアプリケーションがFreeTypeをロードしたあとであればこのリンクを切ってもリンク先のディレクトリをホールドし続ける。FontConfigが再度シンボリックリンクを解決することはない。

だが、よりよいのは環境変数$FONTCONFIG_FILEを使う方法だ。 これによりカスタムのfonts.confを使わせることができる。

だが、これも罠が多い。

まず、ファイル向けの$FONTCONFIG_FILEとディレクトリ向けの$FONTCONFIG_PATHがあるのだが、$FONTCONFIG_PATHにしてもNN-XXXX.confをロードするわけではなく、単にそのディレクトリのfonts.confをロードするだけである。 しかも、どちらも複数指定はできない。

このふたつがある意味がないし、柔軟性が全くない。 やっぱりFontConfigがいまいちだ。

固有のfonts.confを使わせる

だいたいこんな感じである。

この設定ファイルにはしたいことだけ書けばいいわけではなく、/etc/fonts以下でやっているようなことが全て必要になる。 手っ取り早い方法としては

のように書いておくことだ (いや、多分/etc/fonts/conf.dをここで指定する必要はない)。 これで通常の設定ファイルがロードされる。

この設定ファイル内で書いた内容はincludeの前でも後でも優先され、overrideできる。 だから、この内容を基本として固有の内容を書き足せば良い。

ただし、効力は通常されるどの設定ファイルよりも強いので注意が必要。

この方法は汎用性があり、エディタでフォントを使い分けたいときにも有効に働く。 例えばsans-serifmonospaceのような抽象フォントを指定しておき、それをoverrideすれば良い。 arialhelvetica, MS Pゴシックなどをグローバルに置き換えることも避けられる。

Web browser profile chooser version 2.0

My browser profile chooserが従来はこのような余計なコマンドの実行に適していなかったので、特殊なことをしなくても実現できるように変更した。 これは、既に廃止されたブラウザの削除、設定ファイル指定オプションがなくなったMidoriの削除など懸案だった変更を多数含み、 従来とは互換性がない

従来の強引な手法が訂正されたため、設計も改善された。 これで例えば次のようにして任意のフォントプロファイルで起動できる。

Arial/Helveticaを置換え 読みやすい欧文をウェブに

本当にArialが見やすいと思うのかい?

さて、突然だがあなたに質問だ。

次の画像を見てあなたが読みやすいと思うのはどれだろう。 「見やすい」ではない。ちゃんと英文を読んで、読むのが楽だ、このあと延々百何十ページとこの英文を読むのも苦にならないと思うのはどれか、ということである。

比較1

比較2

比較3

比較4

あなたの心は決まっただろうか?

webでなぜArialを指定したがるのか

Arialが指定されている現実の確認

まずはTwitterのフォント指定を見てみよう。

次にGoogle

Yahoo! Japan。Arialは指定するがHelveticaは指定しない。 MS PGothicが先に指定されているので、かなりArialを指定している意味は恐らく全くない。ヒラギノより先にしている理由もわからず、 これはさすがに技術力が疑わしい。

さらにいえば、フォントファミリーにクォートなしでスペースが入るのも無効なはずなので、技術力完全に駄目なやつでは…?

Mozilla。Zilla Slabはウェブフォントになっている。

Facebook。Helvetica優先でヒラギノ優先なあたり、Facebookはりんご党らしい。

Microsoftコミュニティは日本版でも欧文フォントのみの指定。 それもWindowsデフォルトフォント優先だが、MacデフォルトのHelvetica Neueを優先的に指定する謎のこだわり。

震源地となったMSNは現在は指定なし。私が指摘してから変えた…?

理由と経緯

ArialというフォントそのものはHelveticaの代替フォントである。

Helveticaは1950年代からあるフォントで、すごく使われてきた。PanasonicのコーポレートロゴもHelveticaだ。

Helveticaは現在はライノタイプのフォントで、Macに入っている。 MacはHelveticaを改変したGenevaもあって、割と重用しているようだ。しかもArialもある。

Arialのほうは1982年にRobin Nicholas, Particia Saundersがモノタイプに依頼して制作したもので、Hervetica互換フォントで形は少し異なるものの文字幅は同じ。

ArialはAlternativeを含めればWindowsに古くから収録されていて、Helvetiva互換フォントとして使われてきた。 WindowsのArialはフォント名にHelveticaを含んでいるので、Helveticaと指定してもArialが使われる。

そして代替フォントであったはずが、Arialのほうが美しいとか、WinとMac両方にインストールされているとか1いう理由でArialが主流になっていく。 Arialもポストスクリプトフォントとしてはかなり初期に誕生しているし、当時はあまりポストスクリプトフォントはなかった(し、高額だった)。 指定しなければビットマップフォントが使用される可能性が高く、すごく雑なビットマップフォントが多かったから、Arialの指定は高品位フォントの指定だったといっていい。今の日本の感覚で言うと、モリサワのフォントを指定するような感じだ。特にヒラギノ。

Arialが使える前提に立っていると、UIに使いやすかった。 ボタンはピクセル数を指定しなければならないけれど、その上に載せるフォントに合わせていい感じに調整する機能はなかったから、 「ボタンの上にこの文字を載せるか指定するためにはこの文字がどれだけの幅を取るか特定できなければならない」だったのだ。 当時はDPIも固定だったから、これは表示してしまえば確実に制御できたし、そこでArialが使える前提に立てば簡単に作ることができた。

あと、ワープロ文書でも文字数と改ページの関係でボックスサイズが変わると困ることがある。 ここでもArial前提にしとけばワープロ文書のままで受け渡しができる、というわけだ。 これは今MS Pゴシックの状態でワード文書を送りつける愚か者2と同じような心理である。

ところがだ。HelveticaにせよArialにせよフリーなフォントではない。 そこでサイズが同じ「メトリック互換フォント」がArial以外にも作られることとなる。 これはもう、Helvetica互換というよりはArial互換である。

  • Nimbus Sans (URW)
  • TeX Gyre Heros (Ghostscript)
  • FreeSans (GNU)
  • MS Sans Serif (Windows)
  • Arial (Microsoft)
  • Liberation Sans (Liberation Font Project)
  • Arimo (Chrome OS)
  • Albany (StarOffice)

これでArialに対する互換性をクリアしたわけだ。

和文フォントでも若干そういうものはある。 AAフォントと呼ばれるもの(IPAモナーフォントやMonapoなど)は5ちゃんねる(当時の2ちゃんねる)上でアスキーアートを表示するためのものだが、 梅フォントファミリーがMSフォントメトリック互換であるのは恐らくワープロ文書やメールにおけるレイアウトの都合だろう。

webでの指定の話

CSS登場以前はUI部品のサイズを柔軟かつ明瞭に指定する方法がそもそもなかった。

そのためUI部品にテキストを載せる場合(画像にすると当時は重かった)、レイアウト上「横にいくつボタンを並べる」という都合があり、 これをぴったりに載せる方法がWindowsでもMacでも使えるArialを使う、という方法だった。

これが「WindowsとMacにインストールされているフォントを考慮する」という誤った理解となり、思考停止したままWindowsとMacのフォントをそのまま指定するようになったのが「システムデフォルトの日本語フォントを指定する」問題だ。

挙げ句、MS Pゴシックはまだしもヒラギノとは全くデザインが合わない、単に美しくない状態となるだけの「欧文フォント指定があるから、それを消さずにその後ろに日本語フォントをWindowsとMacで並べればいいよね」という最高に頭の悪いアクションが生まれる、というわけだ。

だが、和文フォントをシステムデフォルトのものを指定するのが 全く意味がない のに対して、Arialを指定することは前述のように多少意味がある。 ただし、現在はCSSを使ってUIサイズを文字サイズ基準で指定できるため、まともなデザインセンスがあるのであれば問題にはならない。 そう、デザインについて数字でしか理解できないエンジニアが解決方法としてフォント指定に走るのはまだわからなくはないが、デザイナーがそれをやったら完全にデザインを投げ捨てているということになる。

基本的に「なり」のデザインになっていれば特に指定する必要はないのだが、UI上(好ましいことではないが)ボックスの中に入っていないテキストなどを書く必要がある場合はArialを指定するのは意味のあることである。 もちろん、その場合でもGoogleがしているように

とするのが適切。

ただし、google検索においてArialの指定が必要かどうかは疑わしい。 ただし、英語で検索するとGoogle検索の結果はArialの場合は2行であるため、2行に内容を詰め込むためには詰め詰めのフォントを使わせたい、というのがあるのかもしれない。そうでないフォントを使うと3行になったりするからだ。 その意味では「ゆるやかに意図を使える指定」ということで、ある意味妥当である。

Google検索の英語での結果 (Raleway)

このArialと汎用のサンセリフを指定する方法は日本語であっても有効である。 日本語はユーザーが設定したサンセリフ体が使われるだろうし、設定していなくても適切な日本語フォントが選択されるため、全く問題ない。

だが、そんなことを理解せず、思考停止してArial > Helvetica > MSPゴシ > ヒラギノにしているサイトが あんまりにもあんまりにもあんまりにも多い ので、3現実的に美しく読みやすく表示させようと思ったら、 「ArialとHelveticaとMS Pゴシックを置き換える」必要がある。

FontConfigに関してはウェブブラウザは当該フォントがFontConfigのエントリ上存在する(物理的にはなくてもいい)場合にその第一候補だけを取得するので、Arialに複数のフォントを設定しても駄目。 そのためArial+MS Pゴシックで合成されることを前提とした設定を行う、ということになりそうだ。

せめて日本語サイトで欧文フォントを指定していなければArialを英語専用で考えることができるのに、langも使わずまぜおって…

UI部品がArialでないと困るという場合でも、それはUI部品をクラス指定して、あるいはUI部品のタグで指定してフォントを指定すべきで、bodyに指定すべきではない。

デザイン的に指定したい (今の時代にデザイン的にデフォルトフォント、かつArialを指定したいとかセンスが死んでるけど4) 場合も「共通で入っている」とかじゃなくウェブフォントにすべき話だ。 和文フォントは大きすぎるため非常に迷惑になるが、欧文フォントは小さいので結構平気なもの。 Roboto, Open Sans, PT Sansあたりはキャッシュされている可能性が高いので、自前ではなくGoogle Fontsあたりを指定するのが良い。

なおWindows

Windowsでは標準でSerifやSans-serifを置換えることができないけれど、 Google ChromeもFirefoxもフォントの設定ができるし、している人は多い、少なくともユーザーにはその自由があるのでやはり強制はすべきでない。

Arialは本当に見やすいか?

冒頭の画像は

  1. Oxygen-Sans
  2. Arial
  3. Sen
  4. Input Sans Narrow

である。 私はInputが圧倒的に読みやすい。

見て気づくかと思うが、Arialはボックスに対して黒い「太めフォント」であり、極めて文字間を詰めた「詰め詰めフォント」である。 ある意味ではMS Pゴシックと類似の特性と言っていい。

Arialは「詰め詰めのフォント」であるため、代替は意外と難しい。 実際にArialは日本語フォントと比べpx数の決まったUI上に載せることが多く、サイズが違うフォントはUIからはみ出すケースが少なくないのだ。

そこでSans-Serifフォントから適当に見繕って表示させてみた。 Arialはとってもプロポーショナルなので文によって長さは大きく変わるが、おおよそこんな感じになった。 なお、試したフォントは200弱ほどあった。

サンセリフフォントの比較 (1)

サンセリフフォントの比較 (2)

サンセリフフォントの比較 (3)
サンセリフフォントの比較 (4)
サンセリフフォントの比較 (5)
サンセリフフォントの比較 (6)
サンセリフフォントの比較 (7)
サンセリフフォントの比較 (8)
サンセリフフォントの比較 (9)
サンセリフフォントの比較 (10)
サンセリフフォントの比較 (11)
サンセリフフォントの比較 (12)
サンセリフフォントの比較 (13)

この中からArialの代替になりそうなフォントを比較してみる。

Arialと代替フォントの比較

割と小さなところにも使われたりする(例えばTwitterのスクリーンネームとか)ので、グリフが小さいフォントは割とツライ。 UIフォントとして人気の高いUbuntuとOxygen-Sansは幅も似たようなもので優秀に見える。

私はlやtの字形がカーブしてくれているほうが見やすいように感じる。ここにはabilityみたいな縦棒いっぱいの単語がないが、 ぱっと見に字形を区別しやすいフォントが日本人には望ましいのではないか。日本語にはあまり「ぱっと見に字形を区別できない字が並ぶ」ということがないし、単語を字形で判断しようとするので、スペースで区切られた単語単位で識別して字は見ないという習慣があまりないためだ。

そう、日本人は日本語に慣れているが、日本語と英語では性質が違う。 日本語では一文字あたりの意味価値が高く、文字の識別が重視される。対して英語は単語感覚なので、どちらかといえば「単語の形」で見ていて一文字ずつはあまり見ていない。

Arialは詰め詰め黒々であり、単語の形で見るのであればなんとなく見やすいかもしれないが、ちゃんと文字がどう並んでいるかを識別しようとするとコストが高い。もうちょっと離すか、細くするかしてほしいし、字形も区別しやすいようにしてほしい、と感じるわけだ。 しかし字を離すと幅が増えてしまう。 TwitterのスクリーンネームなどでもArialが使われてしまうため、グリフ自体を小さくするとそれはそれで見づらい状況になる。

普通のCondenbcedでも厳しいくらい幅が狭く、代替を考えるのも難しい。

なお、字形の差については実はあまり問題がない。読みやすいフォントに代替するのであれば問題になるのは幅であり、例えばSans-serifではなくSerifを選択しても構わない。 ただし、それはデザイン的にArialが選択されている場合には違和感があるかもしれない。

Arialの代わりを探せ

もう少し長文で比較する。Arialがちょうど3行になっている。

Arialと代替フォントの比較 詳細(1)

Arialと代替フォントの比較 詳細(2)

デザイン的にも幅的にも差を小さくしたいのであればUbuntu、またはOxygen-Sansが有力候補だ。 Ubuntuは若干幅広、Oxygen-Sansは細字で詰めているため幅は逆に詰まる傾向がある。

また、リストに入れ忘れてしまったがSource Sans Proはかなり優秀な候補だ。 Source Han Sans Proの日本語部分でもあるため、かなり使いやすい。合成フォントとして人気の高いOpen Sansはやや幅が増えるが、こちらも優秀。

字形が違うものはどうだろうか。 Overlockは英文なら読みやすいのだが、日本語の中に混じっていると結構読みづらい。 Ralewayあたりだと変化が激しく若干の違和感があるが、不自由はない感じになる。

個人的に良いと思えたのはFira Sansだった。SenやAmikoもなかなか魅力的だが、幅の差がちょっと大きい。 今のところFira SansとRalewayとSenで迷っている感じだが、どうも私にはRalewayが良さそうである。

あとはもう好みの問題だ。だが少なくとも、Arialが他のなにより素晴らしいとは私には思えない。

設定例

メトリック互換

メトリック互換フォントに何を使うかはお好みではあるけども。

いい感じに表示する

和文はDPI100程度ならばさわらびゴシック、DPI150程度ならばMMCederがいい感じだった。


  1. もちろん、Helveticaで指定しても両方で使えるのだから、これを言う人は知恵が足りない。

  2. 相手がWindowsでない可能性、相手がMS Pゴシックを持っていない可能性についてわずかでも考えたのだろうか? 相手のことについて思索を巡らせず、自分に問題がないから構わないと考えるのはこの上なく愚かである。

  3. そんなこと言ってこのサイトも…と思っているみなさん。 あんまりCSSいじりたくなかったけど、直しました。アップデートでまた直すことになるのかなぁ。一応追加CSS側で上書きするようにしてはいる。

  4. 「英語のオーソドックスでキレイなフォントを指定したい」場合、RobotoあるいはOpen Sansが現代の主流。 現代は選択肢も豊富で、改良も続けられてきたので、Arialはさすがに古い。

蘇ったFreetype2 Infinality

Archの人たちは本当に熱心だ。

Infinalityといえば、フォントの美しさにこだわるLinuxerにとってかけがえのないキーワードであり、定番テクニックだった。

FreeType2が2.7になったとき、同時にInfinalityも消滅した。

これは、FreeType2がInfinality相当のフォントレンダリングを取り込んだから…でもあるが、実は作者失踪のため、でもある。 FreeType2がInfinality相当のサブピクセル計算方法を取り込んだから十分だと考えたのか、それともやる気を失ったのか、いずれにせよ公式にInfinalityの役割を終了することなく…つまり、Infinalityのまざまな機能は取り込まれなかったが計算式だけは取り込まれる形でInfinalityは消滅した。 もちろん、Infinalityはそれ以前に終わっていたのだが、FreeType 2.6の間は機能していた。2.7になって互換性がなくなり、機能しなくなったのだ。

これに対して不満を持つ人は多かった。

まず、Infinalityが終了したことに気づかず、トラブルに巻き込まれた人、というのがとても多い。

そして次に、FREETYPE_PROPERTIES="truetype:interpreter-version=38"は十分ではないと考えた人もまた、いたのだ。

実際、私もFreeType 2.6 InfinalityからFreeType 2.7になってフォントレンダリングの質は落ちた、と感じた。 だが、upstreamの方針ならそれもまた致し方なし…と考えたのだ。

しかし、そうではなかった。 FreeTypeはInfinalityの機能を取り入れる予定はなかったし、別にInfinalityパッチが不要のものになったわけでもなかった。

そしてついにFreeTypeパッチは蘇った。

AURにあるfreetype2-infinalityはFreeType 2.9に対応した新しいInfinalityパッチつきFreeTypeである。 cairo-infinality-ultimate, fontconfig-infinality-ultimateが新たなる対応ソフトウェアとして登場している。 なお、Java用のInfinalityパッチとlib32のFreetypeパッチは投げ捨てられたままだ。

freetype-ultiamte5はInfinalityではない、さらに別のパッチである。 TomaszGasior氏の作で、Infinalityを使わず、直接にFreeTypeにパッチを当て、Infinality Ultimate5相当のレンダリングを得ているという。 fontconfigやcairoにinfinalityパッチを当てる必要もない、なかなか効率的なパッチだ。

FreeTypeはClearTypeのフォントレンダリングを取り込もうとしているらしい。 だが、特許上の問題から今のところ難しいらしい。

この機能自体は実装はされていて、しかし有効にできないオプションとなっている。

Technically, no. The patents cover the whole process of generating and displaying sub-pixel images. Since the font engine doesn’t do the display part, it cannot infringe. Apart from that, FreeType has provided the capability of converting vector shapes into un-filtered sub-pixel images for a long time.

By default, FreeType’s scan-line converter returns ‘gray’ sub-pixel images, where for each pixel the color components are equal (this is, R=G=B). The result is visually identical to gray anti-aliasing and cannot infringe any of the ClearType patents.

Similarly, the LCD-specific filtering API is disabled by default, which means that it returns an error and doesn’t alter sub-pixel images.

You can override these limitations by activating option FT_CONFIG_OPTION_SUBPIXEL_RENDERING in FreeType’s ftoption.h configuration file, but you should do that at your own risk.

この機能を(自己責任において)有効にした状態でビルドしたものがfreetype2-cleartypeである。

そしてこのいずれも、最も劣悪にまで落ちてしまったLinuxのフォントレンダリングを改善してくれる。

リスク順に考えてみよう。

freetype2-cleartype

特許上の問題がある。設定オプションを変更しているだけなので、Infinalityパッチ環境で2.7に上がったときのような問題は起きないと思われる。

技術的には最も安全。特許状の問題は、個々の環境で有効にする分には問題はない…?

freetype2-ultimate5

小規模なパッチで、取り残される心配は作者が投げない限りはなさそう。

動作もinfinalityに比べれば軽く、戻すのも比較的簡単。 ぜひともupstreamに取り込んで欲しい逸品。

freetype2-infinality

fontconfigとcairoにも依然としてパッチを当てる1必要がある。 動作も重く、やや不安定。

現状では問題なく動作しているが、リスクは最も高いように思われる。

freetype2-ultimate5とinfinalityパッチは関係がないはずだか、freetype-ultiamte5 + fonconfig-infinality-ultimate のほうが美しいように感じた。

なお、これらのパッケージはAURのものであり、Arch、あるいはAURを利用する他のディストーション(Anterogos, Manjaro)以外においては導入は難しいかもしれない。


追記。実際に比較してみた。

設定を全くせずにインストールだけするとfreetype2, freetype2-cleartype, freetype2-infinalityの結果は全く同じだった (composite -compose Difference afile bfile difffileidentify -format "%[mean]" difffileで確認)。

freetype2-ultimate5は異なるレンダリングをしている(見た目にも明らかに濃い)が、fontconfig-infinality-ultimateによる違いはなかった。

繰り返すが、これはあくまで「設定は一切せずに」比較している。

ただ、結局はfreetype2-ultimate5がよさそうだという感触なのだが。

FreeType2 ClearType option
FreeType2 Ultimate5 patched

  1. FontConfigのほうはpatchというか、/etc/fonts/conf.avail.infinalityを作ってこれにリンクを張るものだけれども

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

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

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

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

“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にする」という手法が成立しているからだ。

コーディング(プログラミング)向け 欧文モノスペースフォント特集!!

改定を重ねて大ボリュームになってしまったので独立!

欧文モノスペースフォント + 和文デュアルスペースフォント ってどうなの?

百聞は一見に如かず、とりあえず見てみよう。

結論としては、「違いがある分、コメントや文字リテラルとの区別がつきやすくなって却ってみやすい」というのが私の意見。

レンダリングがよく、ウェブのように複数のフォントを順に指定できるVSCodeでやっている。

Input Mono > モトヤLマルベリ等幅 > MMCedar

Input Mono + マルベリ

私が普段VSCodeで使っている組み合わせ。

日本語の中に混じっていても読みやすい。割と統一感がある。

Fira Code > Migu 1M

Fira Code + Migu (in text)

Fira Codeもお気に入りのひとつ。

Fira CodeがどちらかというとSerifチックなので、Migu 1Mとはあんまり合っていないかもしれない。 だが、これがコードの中に入ると、どうだ。

Fira Code + Migu (in code)

違和感ないと思う。

Nova Mono > モトヤLマルベリ等幅 > Migu 1M

Nova Mono + マルベリ (in text)

Nova Mono はかなり癖のあるフォントだけれど、意外と日本語とまじってしまうと気にならない。 丸ゴシックのほうがいいというのはあるけど、丸ゴシックならだいたいいい感じだ。

Nova Mono + マルベリ (in code)

半々くらいにまじっているこのコードだとむしろ見やすい。

monofur > VLゴシック

monofur + VL (in text)

形状が独特なだけでなくグリフサイズが異なるmonofur。

違いがくっきりな分、かえって見やすい。

monofur + VL (in code)

agave > Migu 1M

agave + Migu

私がメールのサマリー部分で使っている組み合わせ(本文はInput Monoの組み合わせ)。

「違うと却って読みやすい」というのが伝わるのではないだろうか。

おすすめの欧文モノスペース(コーディング)フォント

日本語を交ぜ書きするため、一般的には日本で欧文モノスペースフォントが紹介される機会は少ないし、紹介されるとしてもだいたい定番のものになる (Source Code Pro, Anonymous Pro, Menlo, DejaVu Sans, Inconsolata, Droid Sans Mono, Ubuntu Mono あたり)。

そこで今回合成前提に欧文モノスペースフォントを探し回ったので、よさげなのを紹介しよう。

なお、日本語フォントだと

  • Migu 1M / VLGothic (アルファベットは同じ)
  • Migu 2M
  • MigMix

あたりが定番で、コーディングに適した欧文フォントと合成したものとしては

  • Osaka等幅 (Monaco)
  • Ricty / Myrica / Myricam (Inconsolata)
  • Source Han Code JP (Source Code Pro)
  • 更紗ゴシック (Iosevka)
  • Cica (Ubuntu Mono)

がある。

更紗ゴシックは中国語フォントだが、Jという日本語フォントファミリーを持っているので使いやすい。

monofur

monofur

まるっこくて可愛らしいフォントだけど、見やすく疲れにくい実用的なコーディングフォント。 識別性も大変高い。

ややコミックフォントっぽいけれど、実際はコードがびっしりでもかなり見やすい。

mononoki

mononoki

デフォルメ強くてシンプル。Ubuntu Monoなんかに近いフォント。

Ubuntu Monoほど文字密度がないので、記述量が多くても黒黒としなくて楽。 Ubuntu Monoほど特殊でもないし、より見やすいと思う。

やや幅なあるボクシーなスペースを持っている。

Agave

agave

monofurに近いまるっこい系。 もっとデフォルメが強くて非常に実用的。

似たグリフを持っている文字が全く違う形状になっているので識別は非常にしやすい。 グリフは小さめで、スペースの節約にもなる。

スペースの比率は昔ながらのターミナルフォント的。

印刷するときにも好まれる感じのフォントだと思う。

Monoid

Monoid

今風ターミナルフォント。

線が少なくシンプルだけど先別しやすい。

そして、めちゃめちゃキレイ。Retinaというスタイルがあるくらいだから自信あるんだろう。 すっきり見やすい。

フォントは縦長でグリフが大きめ。 ->, >=, !=, */ といった文字列が特殊な表示になる。

私のmonospaceはMonoid+Migu 1Mになっている。

Hermit

Hermit

ちょっとくどいけど、すごくかわいくて見やすい。

古のIBM系ターミナルフォントを今風にしたみたいな感じだ。 よく見るとブサイクなのだけれど、なかなかかわいらしい。

Atomで使うと細いウェイトが優先される。

Input Mono

Input Mono (Default Setting)

非常に人気の高いらしいフォント。

実際、きれいでかなり見やすい。 テイストとしては Source Code Pro に近い。わずかにタイプライター調。

密度あげたい人はCompressedというバージョンもある。 私はコーディングフォントは四角いスペースのほうが好きだけど、縦長が好きな人にはお勧め。 そこまでいかないCondensedやNarrowもある。

また、好みの分かれるグリフ(i, l, {}, *, a, g)についてはダウンロード時に調整可能。

Luculent

Luculent

lの見やすいフォント。

グリフはちょっと縦長だけど、左右に少しスペースがあるので割とみやすい。 縦長ウィンドウには割と合う。

Boldがわかりやすいのも特徴的。

Monofonto

Monofonto

あまり変哲のなさそうなコンソール系フォントだけど、グリフが小さくて見やすいので、ディスプレイの解像度が低かったりすると結構便利だと思う。

1366×768で作業している人はとりあえず入れておくといいかも。

昔からある、コーディングフォントとしてはお手本のような形状。

Sudo

Sudo

Monofontoよりさらに小さくてみやすいミニマル向けターミナルフォント。

小さいのもあるが、どちらかといえば縦長で横のスペースが少なくて済む。 逆に縦に関しては行間広めなので意外と節約できない。

フォントサイズが小さくなっても読みやすい。

Envy Code R

Envy Code R

丸みを帯びて読みやすいターミナルフォント。

シンプルながらグリフの識別も楽で、連続するシンボルも見やすい。 シンボルは合成するというアプローチもあるが、こちらは逆に明確に分割する。

アプローチとしてはUbuntu Monoに近いが、もっとオーソドックスな形。

Fantasque Sans Mono

Fantasque

カーブがかってちょっとおしゃれなフォント。コード密度が高いときにはそれほど読みやすくないけど、識別はしやすい。

ちょっとタイプライターフォントと草書体フォントを混ぜたような感じ。 小文字のベースラインがちゃんと揃ってないのもおしゃれなんだろうか。

l, 1, Iの識別性は大変よい。その他見分けやすく読みやすい。 タイプライター系フォントが好きな人には結構いいかも。

CPMono

CPMono

グリフサイズがboxyなフォント。 おしゃれなterm系フォントといった趣。 ちょっとごついけど、結構見やすい。

欠点として、()[]が識別しにくい。あと、1lもだいぶ識別しづらい。 実用よりはややおしゃれよりのフォント。

Fira Code

Fira Code

Source Code Proと同じようなオーソドックスなフォント。 見間違いやすい文字の識別性が非常に良いよう設計されているほか、->, =>, >=, */, == != && といった文字列の結合・特殊化も行う。

すごく今風なコーディングフォントという感じで、欧文圏ではかなり人気もあるらしい。

NovaMono

NovaMono

シンプルな形状でまるっこいフォント。全体的に丸いので読みやすくはないが識別性は高い。

「識別しやすいおしゃれフォント」としても使える。密度の高いコードに使うとなかなか読みづらい。

OCRA / OCRB

OCRA

OCRB

OCRフォントは決まりきった形状。 特殊なフォントでコーディングに使うことは稀だが、OCRBはなかなか使いやすい。

Cousine

Cousine

非常にオーソドックスでみやすいモノサンズ。

Droid Sans MonoやDejaVu Sans Monoと引き換えにできるかも。

Crisp

Crisp

レトロビットマップ調。

Iosevka (更紗ゴシック)

Iosevka

変形するシンプルなターミナルフォント。

あまり使われないけれども、更紗ゴシックでも使われている。

Iosevka Term

Iosevka Term

変形しないIosevka。Fira Mono, Menlo, Pragmata Proなどさまざまな形状のものがあり、これはMonaco形状。

NK57 Monospace

NK57

レトロなターミナルフォント。

幅広でボクシーだが、幅は色々あり、 Cd(Condensed), Sc(Super Condensed)、さらに逆に幅広な Ex(Extended), Se(Super Extended)が揃う。

Space Mono

Space Mono

ちょっと誇張した形状のターミナルフォント。

Telegrama

Telegrama

レトロ調ターミナルフォント。

ビットマップ風のRawとスムーズなアウトライン調のRenderの2スタイルがあるが、スタイル指定できない場合はRawが選択されてしまうため、 Rawはインストールしないのも手。

TerminessTTF Nerd Font

TerminessTTF Nerd Font

Terminusに大量のシンボルフォントを含むNerd Fontのパッチをあてたもの。

Terminusはビットマップフォントだけど、こちらはスムーズなアウトラインフォントとして扱える。

Camingo Code

Camingo Code

オーソドックスなターミナルフォントだけれど、これ系としてはシンボルフォントが少し特徴的。

ターミナルフォントは似通ってるのが多いので、説明書きが大変。

Espresso Mono

Espresso Mono

キレイなターミナルフォント。 アンダーバーがややみづらい。

昔はよく見たけれど、最近はちょっと入手困難。

Andale Mono

Andale Mono

シンプルで余白大きめのターミナルフォント。

シンボルが見やすくて結構実用的。

SF Mono

SF Mono

AppleデフォルトのSan Franciscoフォント…らしい。

お手本のようなターミナルフォント。 @の造形がちょっと微妙なのが残念ポイント

IBM Plex Mono

IBM Plex Mono

IBMで今なお使われているコンソールフォント。

Go Mono

Go Mono

セリフ系のものスペースフォント。

セリフ系としては割とみやすい。

Overpass Mono

空間ひろめでみやすいターミナルフォント。

Nouveau IBM Mono

Nouveau IBM

私にとってはすごーく懐かしいIBMのコンソールフォント風。

DEC Terminal Modern

DEC Terminal Modern

Unixのレトロななにかでよく見かけるDECのコンソールフォント風。

意外とみやすい。

IBM 3270 Font

IBM 3270

Nouveau IBMよりさらにレトロなIBMフォント。

Cutive Mono

Cutive Mono

線の細いセリフ系モノスペースフォント。

おまけ。定番モノスペースフォント

Source Code Pro ( Source Han Code JP / Merica / Mericam ) / Noto Mono

Source Code Pro

Adobe と Google の共同開発フォント。 フリーフォントの品質の革命とも言えるもので、非常に良い。

グリフは割と幅があるのだが、スペースは行間が大きいため縦長。 表示スペースを多く取ることに好みが分かれる。

非常に見やすくモノスペースフォントの優等生。

DejaVu Sans Mono

DejaVu Sans Mono

Bitstream VesaのUnicode版として2004年から開発されている老舗フォント。 モノスペースフォントも歴史は長い。

グリフが揃っていることを重視したフォントプロジェクトなので見た目に美しくはないが、実用性はMonacoに負けず劣らず高い。

Droid Sans Mono

Droid Sans Mono

ハンドヘルドデバイスなどでの利用を想定し、アセンダーコーポレーションが開発するフォントファミリーのDroid。

その中のモノスペースフォントとしてDroid Sans Monoがある。

Android端末上で等幅フォントを表示する機会は少ないのだが、実は欧文圏では割と人気がある。 日本で人気がないのは、多分Droid Sans Japaneseの品質がだいぶひどいことにあるだろう。

オーソドックスだが、0とOの識別性が低いのが難点。

Inconsolata (Ricty)

Inconsolata

日本人でもある程度使っている人はいる、Rictyに含まれているので実はかなりいる細くて縦長のものスペースフォント。

飾り気はなく、美しくもないが、シンプルで見やすい。 また、特殊スペースが小さくても文字が小さくても読みやすい。

Ubuntu Mono (Cica)

Ubuntu Mono

本家は別にかわいい路線じゃないのに、なぜかかわいいフォントで人気になってしまったUbuntuフォントファミリー。

Ubuntu MonoもちょっとかわいいフォントとしてSource Code Pro, DejaVu Sans Monoあたりと並んで割と席巻している。

日本でもユーザーは多く、最近はCicaという合成フォントも登場している。

Anonymous Pro

Anonymous Pro

細めのモノスペースフォントで、ややタイプライター風。

ブック向きで印刷映えする。

Iとlがやや判別しにくい。 広い画面で使うにはあまり向いていないフォントでもある。

Hack

Hack

Anonymous Proと並んで「欧文モノスペース」として紹介される定番フォント。

細めのタイプライター風のAnonymous Proに対してこちらは太めのターミナルフォントになっている。 ターミナルフォントとしてはオーソドックスな形状。識別性はかなり良い。

Meslo (Menlo)

Meslo

Mac OS Xのモノスペースフォントは10.6からついにMenloになった。

というわけで負けじとBitstream Vera Sans MonoをMenlo風のフォントに仕立てたのがMeslo。

本当にMacは世界的にファンが多い。

フォント自体はHackと非常によく似たターミナルフォント。 Monacoほどの識別性がないため、だいぶ地味になった。

Monaco

Monaco

Apple製のフォントはプロプライエタリだが、GitHubにクローンプロジェクトがある。

コンパクトで縦長のグリフを持つ。長くMac開発環境の定番として君臨しているだけあって非常に見やすい。非常にオーソドックスで望ましい形をしている。 book系のものスペースフォント。

Roboto Mono

Roboto Mono

非常にオーソドックスなターミナルフォント。 シンプルなだけにみやすい。

monospace fontを指定した話

Mimir YokohamaのCSSでmonospaceをより積極的に指定するようになった。

Mimir Yokohamaにはプログラミング関連の記事があるが、基本的には初心者向けである。

そのため、ユーザーはプログラミング向けのフォントを持っていない可能性もある。 また、そうでなくてもブラウザのmonospaceフォントをプログラミング向けのフォントに設定している可能性は低い。

日本語OSの場合、Windowsではデフォルトに“MS ゴシック”、Macでは“平成角ゴシック”が使用される。 これらはいずれもコードの表示には全く適さない。

英語環境の場合はWindowsは“Courier”, Macは“Courier New”が使われるようだ。適しているとはいえないが、いくらかマシである。

だが、現在の環境では1それぞれコーディング向けのフォント、Windowsなら “Consolas” が、Macなら “Menlo” が導入されている。 なので、次のようにすれば話は解決する。

Linuxのことも考えなくてはいけない。 Linuxの場合はコーディングに適したフォントが豊富なので心配する必要はないのだが、日本語環境だとmonospaceが “IPA ゴシック” だったりするかもしれない。 と、なるとこうなる。

だが、私は無意味なシステムデフォルトフォントの強制などしない。 ユーザーがわざわざ(おそらくは好みによって)インストールしているものは尊重されるべきだ。

そこで、「わざわざインストールした可能性の高いものを優先する」というポリシーで追記した。

ただし、グリフ変形のあるフォント、モノスペースではあるがコードとしての読みやすさに欠けるフォントは除外した。 これは、コードに慣れていない初心者に無用な混乱をもたらさないためだ。

一方、初心者が学びに使用する上で望ましいフォントとしてInputを挙げている。 そのためにインストールガイドまで容易するほどだ。

Inputを配布しないのはInputがライセンス上それを許していないためである。

また、Webフォントとして利用することもInputは許可していないが、それを別としても(和文フォントのように重いわけではないが)表示に必須ではないにもかかわらずそれなりにサイズのあるフォントをダウンロードさせることは全く好ましくないため、Inputに限らずWebフォントを使うのではなく、できるだけコーディングに適したフォントで表示させる、という方法を取っている。

また、Sans-serifやSerifと違って意図したように表示されない場合の問題が大きいため、かなり記述量が網羅的に多くなっている2

なお、monospaceフォントの記述を行ったのは、これからプログラミング関連の記事を更新するための布石でもある。

実はChiemoniでも同様の問題を考慮して同様の記述を加えている。


  1. Macがコーディング向けの“Monaco”を採用したのはとても昔の話なので案ずることはない。Windowsの場合、Windows Vista以降は“Consolas”が導入されている。

  2. Serifフォントは「明朝体ならなんでもいい」に近い感覚なので別に細かく記述する必要もないが、Sans-serifは「丸ゴシックで表示したい」ということであり、丸ゴシックは比較的少ないので網羅的に記述することもできなくはない。 だが、丸ゴシックでなければ困るわけでもないので網羅的な記述にはなっていない。

フォント帳アプリを作る → 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等幅は専用に調整されてリリースされているものなので含めてもいいかもしれないが。

ハイアクセシブルウェブサイトとウェブデザイン (フォント関連)

font-familyの指定

font-familyにシステムデフォルトのフォントを並べているのを非常によく見る。 例えばYahoo! Japan

MSN Japan

Google (google.co.jp)

まず先に言うならば、Arialは欧文書体であり、フォント解釈を厳密に行う環境の場合、Arialが指定されることで文字化けが発生する。 ここではArialがないというケースを除外して次のように処理される。

  • Arialにグリフがないフォントを置き換える
  • Arialにグリフがないためフォント自体を置き換える
  • font-family自体を解釈せず既定のフォントで表示する
  • Arialのみで表示しようとする (グリフのない文字は文字化ける)

このうち最も困るのは最後のケースだが(Arialを指定したがために文字化ける)、実際は欧文をArialで表示し、和文を他のフォントで表示して「美しい」と感じるのは難しい1。それよりは全部和文書体の方がバランス的にもマシである可能性のほうが高いのだ。そのため、最初のケースも明らかに意図的でない限りはまずい動作をする。2

昔、ごく限られた条件下では、フォントが指定されないことに起因して文字化けるということがあった。 これは、ブラウザがデフォルトフォントを欧文フォントに決め打ちしており、フォントレンダラーによる文字選択は可能なので、指定しなければフォントレンダラーに選択を任せないために文字化けるという状況であった。

しかし、現状で考えると

  • 日本語版のWindows/Macであれば和文フォントがあり、メジャーなブラウザは和文フォントを選択する
  • 非日本語版でデフォルトの和文フォントがないのであれば、指定したところでそのフォントはないので使えない
  • 日本語環境を無視しているようなブラウザをわざわざ使用するユーザーは文字化けすれば設定すると思われる

ということから、システムデフォルトのフォントを指定することは 現実的に意味がない

強いて言えば、ヒラギノを優先して指定することで、Windowsユーザーでもモリサワ書体を購入しているユーザーにはヒラギノを優先して使わせる、ということも可能だが、それは「ヒラギノが他のどんな書体よりも美しい」というMaccerの思い込みに過ぎない。3

Mimir Yokohamaでは次のように指定している。4

通常フォントをサンセリフ体、本文フォントはセリフ体を指定している。 セリフ体のSource Han Serif JPを除くと全て商用フォントである。 これは、もしユーザーが商用フォントを持っているのであればそれを使ってもらおうということである。 本来のfont-familyの使い方であると言える。

適当に選択しているわけではなく、本文フォントとなるセリフ体には流れるようなグリフで、十分に収録グリフがあり、長文を読むのに疲れないフォントであることを選択基準にしている。 サンセリフ体についてはいわゆる「丸ゴシック」である。「丸ゴシック」という抽象フォントがないため、イメージとしてより好ましいフォントを並べる、という方式をとっている。もしあるのであればsans-serifではなくrounded-sanscjk-rounded-gothicのような指定がしたいところである。

font-family指定がシステムデフォルトフォントを指定するというのは、「システムデフォルトフォントが嫌いで、わざわざ商用フォントを入れて設定しているユーザーに対してシステムデフォルトフォントを強制する」ということでもある。 これはユーザービリティを高めているのではなく損ねている。 そんなことに貴重な数十バイトを使用するべきではないのではないか。

webfontについて

webfontはCSS 3.0で追加された、ウェブリソース上に配置されたフォントをダウンロードして使用するものである。 font-familyがシステムフォントしか指定できないために、結局システムデフォルトフォントばかり指定するという無意味に近い状況がこれによって改善された。

なんでこんなものが追加されたかというと、従来デザイン上特定のフォントを使用したい場合にどうしても「画像を使う」という状況であったが、W3Cとしては常に文字情報であればテキストとCSSを使うべしという思想である。 これを実現するためにCSSにテキストを重ねたり傾けたりして配置する機能と共に、特定のフォントを使わせる方法を提供したものである。

「デザイナーの意図するフォントを指定できるようにした」と解釈される場合も多いが、実のところそれは副次的なものであり、W3Cがこの仕様を制定した意図としては「テキスト画像を撲滅したい」ということであり、既にテキストとして表示されている情報がどのように表示されようが(W3Cにとっては)どうでも良いのだ。

だが、実際のところW3Cの意図に反して画像撲滅よりは従来からテキストで表示されていた部分のデザイナーの意図反映に使用されている5

このために「確実に好きなフォントが使える」程度の理由でwebfontが指定される傾向があるのだが、それはデザイナーの完全なエゴである。

欧文フォントであれば(W3Cが考えたように)ロゴ画像をダウンロードするのとさして差のないデータ量であり、それほど躊躇われるものではないのだが、和文フォントであると常用漢字のみ収録のものですら2MB程度ある。画像などよりもはるかに大きく、通信料金で考えると2円ほどかかる。 これを表示ごとに要求することになるのだ。6

しかも、そもそもフォントレンダラーは一種のバイトコードインタープリタであり、潜在的にはフォントファイルはウィルスとして機能しうる7

また、そうでなくてもテキストと異なるグリフを持つフォントをダウンロードさせることにより、コンピュータ(例えばGoogleやSymantecのチェック)を欺いてユーザーに嘘の情報を見せるサイトを作ることもできる。 これは詐欺などにおいて有効な手法である。

にも関わらず、現状主だったモバイルウェブブラウザにおいてはwebfontを無効化する機能というのはない。 私も仕事にしていたこともあるくらいだからフォントは大好きなのだが、それでも自分の望むデザインのためならユーザーに負担を強いたり、不快な思いをさせても構わないというデザイナーのエゴには賛同できない。

長文のための工夫

私が書くコンテンツは(この文章を含めて)往々にして長文である。

これは、意味ある情報を提供してこそ意味があるという思想に基づくもので、内容空疎なイメージ戦略や思考停止で選ばれるものを提供しようとは思っていないから…なのだが、長文を含めて読むのが得意な人は比較的少数だし、やはり長文を読むのはどうしても負担になりやすい。

そこで、可能な限り長文を読みやすいように心がけている。

本文に対する設定としては

  • フォントは細めで、流れるような(連続した文字を少ないコストで読める)明朝体
  • 自動カーニングで行間を詰める(長文の流し読みが楽になる)
  • これだけでは「文字量が多く黒い」と感じてしまうため、少しだけ文字間を空ける
  • 黒さを軽減するため、行間を少し空ける
  • 結果として段落間の行間が詰まってみえるため、段落間に空白をもたせる

このほか、リズム感のある句読点や、かぎかっこの使い方、言い回しの選択などの技法と組み合わせてできる限り「楽しく読める長文」を心がけている。

ウェブサイトは内容であって見てくれではない、ということを忘れてはいけない。


  1. この指定は「欧文のみの要素に対して欧文フォントを適用する」指定ではない。和文フォントが適用される条件でもArialのグリフがあるものはArialが使われるのだ。

  2. もちろん、欧文書体を和文書体に含まれていない特定のフォントを選択してほしいという理由で意図的にこのようなことをすることもできるが、その場合は和文書体よりも先に欧文書体を書くべきで、MS PGothicよりもArialが後、というのはArialの欧文よりMS PGothicの欧文のほうが好ましく、けれど和文書体にある欧文ではなくArialを使ってほしい、というよくわからない美的センスである。

  3. モリサワ書体を含め、商用フォントを選択肢とするのであれば、無条件に「ヒラギノが最高」ではなく、数多のフォントからそのサイト、その文章に適切なフォントを選択できるはずだ。

  4. Chienomiでは既存のWordPressテーマを使用しているため、私は関知していない。

  5. これは当然の帰結と言える。デザインされた画像を作成するのと比べて、CSSでそれを実現するのは難しいし、同じフォントであってもレンダリングで見た目に差が出ることから望むほどデザインを再現してもらえない。記述量も多く、しんどい。

  6. キャッシュがあるから、というのは傲慢である。特にモバイル環境ではキャッシュを取り直す状況は非常に多く、セッションごとに取得すると考えて間違いない。

  7. このために以前のWindowsではフォントインストールにセキュリティリスクがあるという警告が出されていた。

Pandoc + TexLive (LuaTex)によるPDF生成と和文フォント

Pandocは非常に便利なツールだが、オプションがなかなか複雑で、特にPDFにする場合などは長くて毎回打つのはしんどい。 このことは初心者にとって使いにくい理由のひとつになっていると思い、簡単に扱うためのZshスクリプトを書いた

だが、この際に思わぬことに気づいた。

LuaTeX(TexLive)経由でPDF化する際に、ドキュメントクラスがarticlereportなら-V mainfontが効くのだが、ltjarticleltjsarticleでは効かない。 正確には、欧文にしか効かない。

追いかけると、LuaTeXはmainfontは欧文フォントの指定であり、和文フォントは独立してmainjfontを用いること、とある。 しかし、-V mainjfont=...は効かない。

検索するとmainfontを指定すれば良い、というページばかりヒットするのだが。 諸君は本当に試したのか。見聞きしたままコピペしてないか。

というわけで、Pandoc 日本ユーザー会の[藤原 惟さん(すかいゆきさん, @sky_y)](https://twitter.com/sky_y)にご報告させていただいた。

すると、一時間ほどでご回答いただけた。

-V CJKmainfont=...とすると和文フォントが指定できる、と。

-V mainfont=...で欧文フォント、-V CJKmainfont=...で和文フォントの指定。 早速スクリプトにも反映した。

今回の解決はすべて藤原惟さんのおかげである。 改めて、この場を借りて感謝申し上げたい。

さて、Pandocは非常に便利なツールなのだが、多様なフォーマットに変換する都合からか、微妙なバグが割と多い。 そのバグが変換先エンジンの問題なのか、Pandocの問題なのか切り分けにくいので毎度なかなか辛い。

現時点では--pdf-engine=lualatex環境下において

  • テーブルが右に突き抜けてしまうことがある (発生するテーブルであれば、書き方を変えても駄目)
  • ページを下に突き抜けてしまうことがある (脚注やページ番号にはかぶってページの外に出る。 表と画像を併用すると発生しやすい)

ということを把握している。 どちらもPandocよりはTexLiveが原因のような気がするが、発生原因が特定できず、現在のところ謎バグである。

また、

  • インラインコードの--がTeXのハイフンに変換される
  • コード中の"がTeXの引用符に変換される

という問題もあるのだけれど、これも冒頭で紹介したスクリプトにおいては発生せず、

pandoc -s --filter pandoc-crossref -f markdown -V geometry=a4paper -V geometry:margin=1in -V mainfont="Source Han Serif JP" -V monofont="VL Gothic" -V documentclass=ltjarticle --pdf-engine=lualatex --toc "$1" -o "${1:r}.pdf"

とすると発生する。CJKフォントを指定しても発生する。ドキュメントクラスをltjsarticleにしても発生する。 けれど、スクリプトが実行しているデフォルトの内容としては

pandoc -s -f markdown -V geometry=a4paper -V documentclass=ltjsarticle --pdf-engine=lualatex --toc -o test.pdf test.md

なのだけど発生しない。元のコマンドでフォント指定をやめると発生しなくなる。 どうも試していくとmonofontを指定するとフォントがなんであれ駄目っぽい。

Gtkなデスクトップ環境でGtkとQtのテーマと格闘する

Gtk環境でのQt

作業環境はManjaro XFceであり、実際の利用環境はCinnamonで、KDE Plasmaは入れていない。

KDE環境だとQtのstyle (QtだとthemeではなくてVisual Styleと呼ぶ。Windows風)は色々入っていたりするのだけども、こういうGtkデスクトップ環境だと古臭いの(ClearlooksとかMotif)とかしか入っていなかったりして、Qtアプリの見かけがだいぶよろしくない。

そこでまず、QtらしいStyleを導入する。 Qt4とQt5のStyleは分かれていて、Manjaro/Archだとkde4やkde5という名前で分けられているようだ。 とりあえず見た限りplasmaパッケージに含まれてはいるものの、KDE本体に依存するようなパッケージはない模様。

Qtのテーマ設定はQt4はqtconfig-qt4、Qt5はqt5ctで行う。

これでKDEとは関係ないけれどQtを使うアプリ(例えばEksterteraとかq4wineとか)の見た目がよくなり、 Ruby qtbindingsも快適に使うことができる。

そう、そもそも今回、ruby-qtbindingsを使ったら見た目がひどかったことからスタートしているのだ。

Gtk2テーマ

Gtk2は恐ろしく鬼門だ。 特に厄介なのが次のアプリ

  • Sylpheed / Claws Mail
  • Mikutter
  • Leafpad

なぜならば

  • Sylpheed / Calws Mailはテーマによっては起動しない。
  • Sylpheed / Claws Mail / Mikutterはスクロールバーがおかしいテーマが多い
  • MikutterはBreezeテーマなどタブの表示が変になるものも多い
  • スクロールバーずれ程度で問題がなく美しいOxygen-GtkはLeafpadはSEGVる

Leafpadを分離するのが良案か。

#!/bin/bash

GTK2_RC_FILES=/usr/share/themes/Adapta-Eta/gtk-2.0/gtkrc exec /usr/bin/leafpad

なお、Gtk3版のl3afpadを使うという手もある。

XFce4は.gtkrc-2.0や環境変数で使用するgtkrcを指定していると、全体的にそれに従う。 外観の設定に左右される範囲よりも大きいようだ。

Oxygen-gtkは良いのだけどなかなか問題がある

  • Gtk3アプリでは表示がおかしくなる可能性が高い
  • Xfce4ではアイコンが反映されなくなる
  • 部分的にUIフォントを頑なに無視する
  • もう開発も止まっているようで今後使えなくなるかも

安定して使えるGtk2テーマがなくなるのはなかなか痛い。見た目はよくはないが、XFceテーマシリーズが安定しているようだ。

Gtk3

Gtk3のほうはもっとシンプル。

Gtk2テーマを指定してXFceを起動すると、Gtk3テーマもそれに従おうとするので、明示する必要がある。

Gtk3も同一テーマで構わないものであれば良いのだが、oxygen-gtkは駄目だ。

if [[ $DESKTOP_SESSION == xfce ]]
then
  export GTK_THEME=Adapta-Eta
fi

しかし、これでもアプリケーションから開くときにGeditを指定するとOxygen-Gtkを使用してしまう。 同様のケースでGeditはfcitxが死んでいる状態で起動したりするので、コマンド名で指定して起動する必要がある。

Cinnamonではデスクトップ設定が反映されるので設定しないほうが良い。

GUIツールキットのお話

今回はRuby qtbindingsを使おうとしたところからスタートした。

RubyでのGUIはまるでスタート廃れたかのような状態にあり、まるでruby-gnome2が唯一の選択肢であるかのようである。 ただ、ruby-qtbindingsは開発は継続しているし、Windowsでも動作するようになっているようだ。

個人的にあまりGtkは好まない。 UIとして使いにくいというのもあるし、設定が複雑でうまく反映されないというような理由もある。 プログラミング上も、QtのほうがAPIは使いやすい。

UIとして優れているのはGtk2だと思う。

Gtk3はメニューが非常に少なく、わかりにくい。 また、ファイルダイアログが劣悪で、ファイルを開くときはまだ良いのだが、ディレクトリを開く場合は非常に辛い。 というのは、何もファイルを選択しない状態で入力を開始した場合のみキーボードからのパス入力を受け付けるが、 Enterを押した時点で「開く」動作をする。 そのため、ディレクトリを開く動作のときには最後まで入力するか、クリックするかしか選べない。

Qt4/Qt5のダイアログはファイル名としてディレクトリパスを入力することもできるが、やはりディレクトリを開く場合には一発で開かれてしまう。 さらに登録される場所がさらに限定的となり、Gtk3よりなお悪い。 なお、XFce4ではQtのファイルダイアログをGtk3のものに置き換えるようだ。

Gtk2のファイルダイアログではファイルリスト側にフォーカスされていればWindows同様にインクリメンタルサーチとなり、 ファイル名欄が常に存在しディレクトリに対して入力を行うとまずディレクトリに移動するという振る舞いとなっている。 これはおそらく最も適切である。 (だが、これも場合によるようで、Qt4/5のような振る舞いをする場合もある)

API的に、あるいは設計的に見ればGtk2からGtk3、Qt3からQt4というのは大幅に進化している。 実際に「よくなった」のだ。

だが、現状でGtk3、あるいはQt5の熟成度というのは全く足りていない。 Qt4からQt5はある程度の互換性を持った状態で進化している。 その進化はわからないでもない。コンピュータの進化に合わせて、あるいは周辺環境の進化に合わせてコンポーネントを作り直した。 その際にいくつかのいまひとつな設計を修正し、テーマデザインにフラットデザインを推奨した。

だが、そのような変更は必要だったのか疑問だ。 内部的な進化や、標準テーマデザインの変更に関しては互換性を維持しての改修でもよかったのではなかろうか。

期間的にGtk3やQt5は日が浅い。 Gtk3のコンセプトが不評ということもあるが、2011年にGtk2は開発終了しているにも関わらずGtk3への移行が進んでいないプロジェクトは多い(XFce4もそのひとつだろう)。 現状ではGtk2を採用するプロジェクトもGtk3への移行を模索する時期にきているが、Gtk3に移行できているプロジェクトはまだ少ない。 Qtに関しては各プロジェクトが苦労してQt3から移行を完了し、あるいは移行できなかったプロジェクトは廃止されているが、 Qt4を採用しつづけるプロジェクトはまだ少なくない。

この状態でさらに非互換性を持つGtk4やQt6へ移行する必要があるのだろうか。 いずれのツールキットもより熟成すべきであるように私には思える。

また、GUIプログラミングも以前は盛んでwxwidgetなどが流行したときもあったのだが、早々に廃れてしまった。 WXWidget自体は現在も開発が続けられているが、wxrubyは既に終了しており、rwxは十分に開発・テストされていないようだ。 RubyにおけるGUIプログラミングの選択肢は非常に乏しく、qtbindingsも将来的には不透明だ。

さらに、Gtkのその問題点から開発者が離れている。 これはGtkの問題点というよりも、Gnomeの方針に開発者がついてきていないという問題なのだが、 GnomeはGtk4においても方針を維持しており、今後もこの傾向は続くだろう。

ユーザー側にはあまり見えない状況ではあるが、実はLinuxのGUI周りはかなり不安定な状況にある。 個人的にはQtがより普及し、バインディングが安定していてくれると良いのだが…