フォント帳アプリを作る → 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がスケーラブル)と厄介なものは色々ある。

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

日本語を交ぜ書きするため、一般的には日本で欧文モノスペースフォントが紹介される機会は少ないし、紹介されるとしてもだいたい定番のものになる (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

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

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

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

Sudo

Sudo

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

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

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

Envy Code R

Envy Code R

シンプルで読みやすいフォント。

フォントが小さいとlがやや判別しにくい。グリフが細るという問題もあるので、フォント大きめだといい。

記号の識別性が大変よい。割とオーソドックスなコーディングフォントだ。

Fantasque Sans Mono

Fantasque

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

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

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

CPMono

CPMono

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

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

Fira Code

Fira Code

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

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

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

Source Code Pro ( Source Han Code JP) / 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

Inconsolata

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

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

Ubuntu Mono

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系のものスペースフォント。

今回の件で気づいたこと

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

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

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

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

商用フォントはいいぞ

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

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

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

Operatorなんて$199もする。 1書体のお値段としては和文フォントに近い。

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

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がより普及し、バインディングが安定していてくれると良いのだが…

Blink/Mozillaブラウザの表示乱れと、BlinkブラウザのSEGVについて

LinuxにおけるBlink系ブラウザ(Google Chrome, Chromium, Opera, Vivaldi)においてページクラッシュする(場合によっては全ページがクラッシュする)という問題に長く悩まされていた。 SEGVが発生しており、エラーメッセージとしては:

../../third_party/tcmalloc/chromium/src/free_list.h:118] Memory corruption detected.

というものだ。

  • 発生がランダムである(ページによって発生しやすさには偏りがある)
  • 特定ユーザーでしか発生しない
  • 新規ユーザーを作っても発生するが、2番目のユーザーだけは決して発生しない
  • 以前にも同様の事象が発生したことがある
  • 再インストールやブラウザのバージョンによっても解決しない
  • プロファイルやソフトウェアによらず発生する

といった問題かが見られ、解決方法が見えず長く苦しむこととなった。

だが、ようやく解決が見られた。

この問題のほかに、ブラウザでのフォント表示の乱れという問題があった。ビックマップフォントと思わしき汚いフォントが表示されたり、フォントが破断しまともに読めないといった状態が発生していた。 これは拡大率を変更することで改善したりするが、別の箇所でまた発生したりもする。

これについて検証していると、フォント指定が次のようなものの場合に発生するということがわかった。

font-family: Meiryo, メイリオ, ArialMT, "Hiragino Kaku Gothic Pro", "ヒラギノ角ゴ Pro W3", Osaka, Verdana, "MS Pゴシック";

これはねとらぼのものだ。autoblogは以下

font-family: “ヒラギノ角ゴ Pro W3″,”Hiragino Kaku Gothic Pro”,”Osaka”,”メイリオ”,”Meiryo”,”MS Pゴシック”,”MS PGothic”,sans-serif !important;

アスキーは以下

font: 13px/1.231 'Hiragino Kaku Gothic ProN',Meiryo,"メイリオ",'MS PGothic',sans-serif;

これらのスタイルを削除すると正常に表示される。 このPCはMSフォントファミリーと、Osakaフォントのクローンが認識されている。そのため、ブラウザ設定によらずこのどちらかを使おうとするようなのだが、するとフォントが異常表示されるのだ。 これは、どちらか片方を削除しても解決しない。

フォント自体を削除しなくても、これらのフォントを置き換えれば解決する。

<match target="pattern">
  <test qual="any" name="family">
    <string>MS PGothic</string>
  </test>
  <edit name="family" mode="assign" binding="same">
    <string>Ume P Gothic S5</string>
  </edit>
</match>
<match target="pattern">
  <test qual="any" name="family">
    <string>MS Pゴシック</string>
  </test>
  <edit name="family" mode="assign" binding="same">
    <string>Ume P Gothic S5</string>
  </edit>
</match>
<match target="pattern">
  <test qual="any" name="family">
    <string>Osaka</string>
  </test>
  <edit name="family" mode="assign" binding="same">
    <string>Ume P Gothic S5</string>
  </edit>
</match>

単一のtest内にstringを複数置けなくなったけれど、もうちょっとスマートな書き方はできないのだろうか?

また、この問題に対処してから、ブラウザが落ちることはなくなった。 確証はないが、SEGV(Memory corruption)の原因がフォントにある、というのはちょっと想像がつかなかったし、しかも信頼できるMSフォントファミリーやOsakaフォントというのは全く想像が及ばなかった。

なんでそうなるのか、ということはわからないが、とにかく原因がわかってほっとしている。 わうやくまともなブラウジングができるようになって本当によかった。

ThinkPad e440 * PCLOS

ラップトップはPCLinuxOSで運用しているのだが、いくつかの不具合に気づいていた。
修正しておいた。

フォント問題

Konsoleが適切なフォントで表示しない。

KonsoleはKDEのMonospaceフォントの設定に従うのだが、KDEのMonospaceフォントは好きなフォントを指定できない。
Monospaceフォントに任意のフォントを使いたいのであれば、Fontconfigでmonospaceフォントを明に指定するしかない。

しかし、多くの場合Konsoleはフォントの幅がおかしく、おかしなことになる。
カーソル位置と文字位置がずれてしまうのだ。

この点については、Monospaceフォントをmonospaceにし、さらにフォントを選ぶことで調整する。
それでもKonsoleはずれやすいので、素直にQTerminalあたりを使うほうがマシかもしれない。
最も良いterminalアプリはXFce Terminalだと思う。PCLOSでも使用可能だ。

また、いくつかのフォントで異常な表示になっていた。
Web上で散見されたので、Fontconfigでそのフォントを置き換える。

Touchpad Synaptics

タッチパッドを使ったスクロールが正常に機能していなかった。
twofinger scrollも相当回しまくらないと動かないし、Circular Scrollingに至っては30回ほど回して3行スクロールされるため話にならない。

KCM Touchpadでいくら調整してもまともにならなかった。結局、kcm_touchpadをアンインストールして、手動で調整することで解決した。
Touchpad-solutionを入れておくとベースになる設定を作りやすい。

Section "InputClass"
    Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        #Option  "Device"        "/dev/input/mouse0"
        Option  "Protocol"      "auto-dev"
        Option  "LeftEdge"      "1700"
        Option  "RightEdge"     "5300"
        Option  "TopEdge"       "1700"
        Option  "BottomEdge"    "4200"
        Option  "FingerLow"     "25"
        Option  "FingerHigh"    "45"
        Option  "MaxTapTime"    "180"
        Option  "MaxTapMove"    "220"
        Option  "VertScrollDelta" "-100"
        Option  "HorizScrollDelta" "-100"
        Option  "MinSpeed"      "0.20"
        Option  "MaxSpeed"      "1.00"
        Option  "AccelFactor" "0.15"
        Option  "SHMConfig"     "1"
        Option  "VertTwoFingerScroll"   "1"
        Option  "HorizTwoFingerScroll"  "1"
        Option  "VertEdgeScroll"        "0"
        Option  "HorizEdgeScroll"       "0"
        Option  "TapButton1"            "1"
        Option  "TapButton2"            "2"
        Option  "TapButton3"            "3"
        Option  "EmulateTwoFingerMinZ" "40"
        Option  "EmulateTwoFingerMinW" "8"
        Option  "RTCornerButton" "3"
        Option  "CircularScrolling" "on"
        Option  "CircScrollTrigger" "6"
        Option  "PalmDetect" "1"
        Option  "PalmMinWidth" "10"
        Option  "PalmMinZ" "200"
EndSection

ついでに自動起動でsyndaemon -t -k -i 2 -dして完了。
スムーズに動くようになった。Windows 10に合わせてナチュラルスクロール化している。

USB3.0

e440がUSB3.0だとかいうので、実際に試してみた。

USB3.0ペンドライブを左側奥に挿した場合

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 5: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

左側手前に挿した場合

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

右側に挿した場合

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 7: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 7: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

つまり左がUSB3.0で右がUSB2.0。
さらに言えば、左側のUSB3.0はひとつのroot_hubで、USB2.0は3つ全部でひとつのroot_hub。

e440はUSBポートはすべて黒いので注意が必要。

ちなみに、これを調べるまでSDカードスロットが手前下方にあるとか知らなかった。
さらにBTがあることも知らなかった。ただ、BTはデバイスが見つからないので使えない。理由は分からない。

日本語入力

Gtk2アプリに大してUIMが機能しないという問題があり、gtk-query-immodulesでもどうしようもなかったので対応していた。

結局、develを含めて全UIMコンポーネントをインストールすることで解決した。
この過程でUIM appletが動作せず、uimを有効にできなくなってしまったが、再インストールで解決した。

uim-mozc-neologd-utというパッケージがあって

Uim 用 Mozc プラグイン (Mozc NEologd UT 用)
Uim で Mozc NEologd UT を使用するためのプラグインです。

※ インストール後はコンピューターを再起動してください。

とあり、UTが使えるようだ。
さすがTomcatさんというか、おかげで文字入力効率は大幅に向上した。しかし、Mozcではひらがな/カタカナキーが機能しないという問題がある。
普通はあまり気にしないよということかもしれないが、かな入力の一貫として私は全角英数入力のためにEisu-toggleを使っているので、ここで英数にした時にかなに戻ることが難しい。
そこで、無変換をひらがな/カタカナキーの代わりに使用するように変更した。

なお、アプレットはuim-applet-gtk-systray以外はAnthyで予測変換の候補が出ない。

デフォルトのフォントの選ばれ方がおかしい

fonts.confは以下のようになっているのだが

    <?xml version='1.0'?>
    <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
    <fontconfig>
     <match target="font">
      <edit name="lcdfilter" mode="assign">
       <const>lcddefault</const>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>serif</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>HannariMincho</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>sans-serif</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Migu 1P</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>sans</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Migu 1P</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="any" name="family">
       <string>monospace</string>
      </test>
      <edit binding="strong" name="family" mode="assign">
       <string>Ricty Discord</string>
      </edit>
     </match>
     <match target="pattern">
      <test qual="all" compare="not_eq" name="family">
       <string>sans-serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>monospace</string>
      </test>
      <edit name="family" mode="append_last">
       <string>sans-serif</string>
      </edit>
     </match>
     <dir>~/.fonts</dir>
    </fontconfig>

なぜか、明示されていないフォントはラノベPOPになってしまう。
これはいくらなんでも可読性が低すぎるため、ラノベPOPのフォントファイルをリネームして後ろに回したところ、梅ゴシックになった。
しかし、依然としてボールドには梅ゴシックが使われる。

さらに、Skypeでは途中でフォントが変わったり、まぁ猛烈に読みづらい状態だ。

意味不明なことに、not_eqappend_lastしている部分は、

     <match target="pattern">
      <test qual="all" compare="not_eq" name="family">
       <string>sans-serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>serif</string>
      </test>
      <test qual="all" compare="not_eq" name="family">
       <string>monospace</string>
      </test>
      <edit name="family" mode="assign" binding="same">
       <string>sans-serif</string>
      </edit>
     </match>

とすると、今まで正しく表示されていたアプリケーションメニューが梅ゴシックになり、依然としてfc-matchすると梅ゴシックが返る。

このbindingをstrongにしても結果は同じ、weekだと単に無視される。

この問題には長く悩まされていたが、sans-serifでなく、実体(例えばMigu 1P)を指定すると反映された。

だが、CinnamonのUIについては改善せず、これは~/.theme/<theme>/cinnamon/cinnamon.cssstage要素に対して指定されているものを変更する必要があった。

sans-serifを指定して動かない理由はわからず、その際の挙動についても理解に苦しむが、とりあえずここまで。

Windowsのセットアップ

問題点

WindowsUpdateでコケてまともに起動しなくなったWindowsをリカバリし、まっさらにした。

だが、やはりWindowsUpadteでコケる。かなり慎重に行ったが、それでもコケる。

updateを終了してリブートすると15%まで進行したあと数時間停止、 その後ようやく再起動して構成して再起動(これもかなり長い。ステージ)、5/5になっている。 構成して、構成に失敗したので戻すとして再起動、 そして戻すとして数時間にわたって待たされた後再起動。 そして構成を戻すとし、1回目はステージ5/5の35%から構成して、2回目はそのままログオン画面へ。

見てみると117個中97個、x64 based systemとある修正と、同じ記載のある.NET FrameWorkが全てコケている。2回実行したが、結果はこの通りだ。

そもそも、WindowsUpdateの最中に自動スリープするというのは相当おかしいし、 Update中のネットワーク断(うちではしょっちゅう起きる)や電源断も想定して叱るべきだろう。それでシステムが壊れる設計というのはイカれてる。

セットアップ

まぁ、もうUpdateは諦めよう。近く10が来るのだし。

まず、いつも通りTrueCrypt.chによるドライブ暗号化。

導入するソフトは順序はそれほどない。

カテゴリ ソフトウェア
ウェブ Cyberfox, Opera Developer, SRWare Iron
メール Opera Mail
Twitter TweetDeck, V2C
2ch V2C
エディタ UnEditor, SakuraEditor
マークダウンエディタ Markdown#Editor, HarooPad, CuteMarkEd
オーディオ AIMP
ビデオ VLC Media Player
マルチメディア Free Studio
IM Skype
IME Google日本語入力
アンチウィルス Avast!
アンインストーラ Geek Uninstall
ランチャ Launchy
SSHFS Win-SSHFS
端末 TeraTerm
VSパッチ UXThemePatcher

これはWindowsを単独で使う想定ではなく、なるべくサテライトとして、ここにデータをためずに使う想定だ。 だから、ソフトウェアもそれなりに絞っているし、データは主にsshfsを介する。

だが、これだけやるとWindowsでも結構使えるようになる。

VSとフォント

ビジュアルスタイルに関しては、FunkVSを使用したのだが、フォントがかなり多岐に渡って変更される。この影響は大きく、「どこの部品にどこで定義されたフォントが使われるか」ということも変更されるらしい。

色とデザインの詳細から設定できない部分のフォントに日本語でないフォントを設定されてしまい、Operaではアドレスバーとタブに日本語が表示されなくなった。豆腐になる。

Funkはかなり気に入っていたのだが(特にサブメニューが網掛けで表示されるのは凝っている)、この問題は様々なところに影響を及ぼすため、Skylim VSに変更した。

加えてWindows7 Start Orb Cahngerを使ってstart orbを変更していっちょできあがり。

もちろん、事前にフォントの導入は済ませてあり、またMacTypeも導入してある。壁紙やフォント設定も行った。

FontConfig, Zsh compilation, Zsh prompt

FontConfig

うまく動かないといっていたlocal.conf及びUser configだが、どうも/etc/fonts/conf.d/のリンクをmvして戻すと有効になるようだ。理由はわからず、競合するリンクを削除しても変わらない。

また、それでもなぜかUserに対してのserifだけが適用されない。謎だ。

Zsh Compilation

以下の設定を追加してみた。

# Complation options
setopt auto_menu
setopt glob_complete
setopt auto_list
setopt list_beep
setopt list_types
setopt rec_exact
menu_complete

menu_completeは使いにくかったのでやめた。

Zsh Prompt

Momonga Linuxのzshrcサンプルを流用していて、これが結構いかしたプロンプトなのだが、Manjaroのetc版と比べてGitが有効になっていないので、有効にすると同時にちょっといじってみた。

zshのプロンプトにgitのステータスをシンプル可愛くを参考にしたのだが、これをそのまま追加するとRPROMPTと競合してしまう。どうやら、プロンプトの設定自体を動的に行うとRPROMPTの文字数が計算できなくなるようだ。

RPROMPT込みで流用できるのはきたけーさんのブログだが、これだと情報量が少ない。

そこでこれを合体させ、さらに色使いを変更し、終了ステータスで変更するのをプロンプト全体ではなくプロンプト($)のみにした。

## prompt
# USER -->
# For git. I referred http://kitak.hatenablog.jp/entry/2013/05/25/103059 and http://yoshiko.hatenablog.jp/entry/2014/04/02/zshのプロンプトにgitのステータスをシンプル可愛く. Thank you.
# VCSの情報を取得するzshの便利関数 vcs_infoを使う
autoload -Uz vcs_info

# 表示フォーマットの指定
# %b ブランチ情報
# %a アクション名(mergeなど)
zstyle ':vcs_info:*' formats '[%b]'
zstyle ':vcs_info:*' actionformats '[%b|%a]'
precmd () {
psvar=()
LANG=en_US.UTF-8 vcs_info
if [[ -n "$vcs_info_msg_0_" ]]
then
psvar[1]="$vcs_info_msg_0_"
if [[ -n "$vcs_info_msg_1_" ]]
then
psvar[2]="$vcs_info_msg_1_"
elif [[ -n "$vcs_info_msg_2_" ]]
then
psvar[2]="$vcs_info_msg_2_"
elif [[ -n `echo "$st" | grep "^Untracked"` ]]
then
psvar[2]="Untracked"
else
psvar[2]="Clean"
fi
fi
}

# バージョン管理されているディレクトリにいれば表示,そうでなければ非表示
#RPROMPT="%1(v|%F{green}%1v%f|)"
# <-- USER
PROMPT='%F{cyan}[%n@%m${WINDOW:+[$WINDOW]} %.] %1(v|%F{yellow}%1v|)%2(v|(%2v) |)%{%(?.$fg[green].$fg[red])%}%(!.#.$)%{$reset_color%} '
RPROMPT=[%~]
SPROMPT='zsh: replace '\''%R'\'' to '\''%r'\'' ? [Yes/No/Abort/Edit] '

結構イケる。