続・EPUB3におけるウェブフォント指定のちょっとした落とし穴

まえがき

id:momdo:20130906:p1
が少しごちゃごちゃしてきたので仕切り直し。

この記事にはいくつか問題点があって、

• 初期の元のEPUBファイルであるpg35597.epubに含まれていたwoffが壊れていた*1
• もとのpg35597.epubが同名で何回か差し替えられている
• Himawari Reader側のキャッシュ機構が機能して、きちんと読み込みできなかった可能性*2

このような点で、かなり混乱している（というか嘘が混じっている可能性）。ただし、いろいろ調べた結果も混じっているので、先の記事はそのままにしておくことに。

さて、どうして豆腐になるのかテストをいくつかしてみた。

(1) woffを本当に読み込めないのか？

自分でwoffが読み込めないかもと書いていて流石にこれは怪しいと思ったので、pg35597.epubの中身を少し改造してみた。

/* OpenTypeのみ */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.otf) format('opentype');
}

body {
  font-family: Braille6, monospace; 
}

/* TrueTypeのみ */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.ttf) format('truetype');
}

body {
  font-family: Braille6, monospace; 
}

/* WOFFのみ */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.woff) format('woff');
}

body {
  font-family: Braille6, monospace; 
}

という感じでCSSを書き直し、念のため指定フォント以外のフォントファイルをepubコンテナの中に含めないようにし、3水準の別名ファイルを作成してHimawari Readerで読ませたところ、どれも意図したとおりのレンダリングとなった（ちゃんとウェブフォントを読んでいる）。

流石にwoffが読めないというアホな展開はなかった。

(2) font-familyの検証

となると、怪しいのは俄然font-familyである。この記事を書いた時点でのpg35597.epubのCSS（/OEBES/style.css）はこのように記述されている

@font-face {
    font-family: Braille6;
    src: url(font/braille6.otf) format('opentype'), url(font/braille6.ttf) format('truetype'),url(font/braille6.woff) format('woff');
}
body {
  text-align: justify;
  text-justify: inter-ideograph;
    font-family: "Apple Braille", Georgia, "Segoe UI Symbol", Braille6, monospace; 
  vertical-align: baseline;
  word-wrap: break-word;
}

で、この記述がされている状態のpg35597.epubは手元のAndroidで読むことができなかった、と。検証のためにまた3水準用意してみる。

/* ケース1 */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.woff) format('woff');
}

body {
  font-family: "Apple Braille", Braille6, monospace; /* iOSにある点字フォントらしい */
}

/* ケース2 */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.woff) format('woff');
}

body {
  font-family: Georgia, Braille6, monospace; /* Georgiaに点字のコードポイントに対応するフォントあるの？ */
}

/* ケース3 */
@font-face {
  font-family: Braille6;
  src: url(font/braille6.woff) format('woff');
}

body {
  font-family:"Droid Sans", Braille6, monospace; /* Android4.0あたりで標準フォントになったはず */
}

とすると、1のみが意図したとおり、2と3のケースが意図しないレンダリング（ウェブフォントを無視する）となった。
これとよく似た症状を見つけたので引用しておく。

現象というのはタイトルにも書いている通り、 Lunascape を webkit エンジンで利用しているとき、CSS で指定した font-family の解釈がおかしいのです。

（引用者：中略）

ここから分かるのは、font-family の1つ目に、インストールされていない未知のフォントが指定されていると、以降の指定はすべて無視されて、エンジン設定で指定したデフォルトのフォントが使われるということです。

@ub_pnrが2年前に通った道だった…（ぉ　と言っても微妙に挙動が違いますが（1のケースもAndroidからすれば未知のフォントなのでは、というところが腑に落ちず）。

なお、当たり前と言えばあたりまえですが、Android標準ブラウザでもまったく同じ挙動を示すので、わざわざHimawari Readerに食わせる必要もないという話も。

まとめ？

Android webkitのfont-familyの挙動が微妙と言うことに起因しているので、現時点ではウェブフォントを指定するならばウェブフォントのみを指定しまうのが一番無難、なのかもしれない。
手元のChromeで試した感じではフォールバックがおかしくなるような感じはないので、時間が解決してくれるでしょう…これなんて昔のIE？

*1:https://twitter.com/kzakza/status/376401393994571777

*2:https://twitter.com/HimawariReader/status/375639355122937856 https://twitter.com/HimawariReader/status/377432598777036801