Japanese Gap Analysisを読んでみる

2018/10/18

 JAGATのXMLパブリッシング準研究会の活動でここ数年、日本語組版処理の要件を扱っているのですが、その流れで先日(再度)作られたW3CのJapanese Layout Task Forceに協力することになりました。そもそもXMLパブリッシング準研究会での研究活動の最終的な目標のひとつはW3Cに何らかの形でフィードバックを行うことだったので、歓迎すべき流れです。これに従い、報告に当たっての要素の大項目分けに相当するJapanese Gap Analysisを読み込んでみました。かなり噛み砕いて日本語組版での用語に擦り合わせる作業が必要になり、ちょっと意味の取れない箇所もありました。お気づきの点は随時ご指摘いただければと思います。

全体的な位置づけの確認

 まず、文書の全体的な位置づけを確認しておきます。世界中の書字言語でどこまでCSS等での組版処理が実現できているかを示すマトリックスがこちらです。色分けされていますが、

  • 濃い は 「All needs covered (ie. OK), or not applicable」 → 全ての要望が実現できているか、あるいは(その言語では)適用する必要がない
  • 黄  緑 は 「Basic needs covered, but work needed for advance publishing」 → 基本的な要望はカバーできているが、より高度な要望のための作業が必要
  • オレンジ は 「Can create interoperable web pages, but work still needed for basic features」 → 運用可能なWebページを作成はできるが、まだ基本的な部分で対応しなければならない要素が残っている
  •  赤  は 「Something prevents interoperable or effective use of the language in webpages」 → 運用可能なWebページをこの言語で作成するに当たって阻害する要素が残っている

 という意味です。その他に「?」が随所にあり、これは状況の調査がまだ済んでいないということのよう。
 なおこの文書含めて何度も「Script」という単語が出てきますが、これはこの場合は「書字言語」、書き言葉の意味です。Languageだと話し言葉を含むもっと広い意味での言語の意味になるので峻別のために使っているのでしょう。

 マトリックスの列が項目分け、行が各国の言語です。
 この行の中の「Japanese」の文字をクリックすると(すぐ上のJavaneseは「ジャワ語」)、今回読んだJapanese Gap Analysisのページが出てきます。もちろん日本語だけではなく各国語向けに同様のページがあるようです。世界中の言語を網羅的に項目を作っているので、項目自体が日本語には必要の無い箇所も多々あるのですがこれはまあ仕方ないところ。今回W3Cが求めているGitHubへの意見のフィードバックはこの大項目に従い、各項目内にIssueを立てて行く形で行われていくと思われるので項目内容の把握は大事です。それでは見ていってみましょう。

Japanese Gap Analysisの各項目

2. Characters and phrases(文字とフレーズ)

2.1 Encoding considerations(エンコーディングに関する考慮事項)

OK

 OK扱いのためコメントはなし

2.2 Fonts(書体)

Needs Research

Do the standard fallback fonts used in browsers (eg. serif, sans-serif, cursive, etc.) match expectations? Are special font or OpenType features needed for this script that are not available?
   ↓
(明朝体、ゴシック体、筆記体などの)デバイス標準搭載フォントによる表示は適切ですか? あなたの言語の表示に必要な特別なフォントやOpenTypeの機能は利用できますか(Webフォントの使用などか)?

コメント:

  • 日本語では筆記体はほぼ考慮しなくてよいと思う。
  • 現状Firefoxではドキュメント側の指定フォントよりブラウザの設定項目でユーザーが設定したフォントが優先されて表示される模様。
  • 「font-feature-settings」などフォントの内部情報をCSSで呼び出して実現する表現もここに分類されるか。

2.3 Font styles(書体のスタイル)

Needs Research

Do italic fonts lean in the right direction? Is synthesised italicisation problematic?
   ↓
イタリック体は正しい方向に傾けて表示できていますか? イタリック体の合成表示に問題がありますか?

コメント:

  • 網羅的な調査はしていないが、縦書き文中に挿入された欧文部分でイタリック表示の処理に問題を持つRSはある。たとえば現状、Kindle等の縦書き時のイタリック体の表示は不適切。
  • Kinoppy等は適切に表示できている上、フォント側がイタリックのグリフを持っている場合にはそれを用いて表示しているように見える。本来はそれが望ましい。
  • Edge等は単純に文字をシアー変形処理で傾けて表示する。Kinoppy等はフォントがイタリックのグリフを持っている場合にはそれを呼び出して表示させる。欧文の部分の表示最適化の意味ではもちろん後者がよい。ただ、イタリック体の情報を持たない漢字などに対してイタリックが指定された場合に傾けて表示することが適切かどうかは議論が必要そう。
  • ひらがな、カタカナ、漢字などには本来はイタリック体の概念はなかったので本来的には当然イタリック体の合成も考慮する必要はないはず。最近モリサワなどから連綿体のフォントも出てきているが、また例外と考えてよいと思う。

2.4 Glyph control(字形のコントロール)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

2.5 Cursive text(筆記体)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

2.6 Quotations(引用)

Needs work for advanced level support

Are there any issues when dealing with quotations marks, especially when nested? Should block quotes be indented or handled specially?
   ↓
引用符を扱うときに、特にネストされたときに問題はありますか? 引用符をインデントしたり、特別に扱ったりするのは避けるべきですか?

 2.6.1〜2.6.3の子項目が立っているがこちらの守備範囲では無さそうなのでコメントはなし。HTMLのQタグを使った際に自動で付けられる引用符の挙動に関して言っているようなのだが、あまりそのあたりはなじみがない。論文などでの話だろうか。

2.7 Numbers, dates, etc.(番号、日付その他)

OK

 OK扱いのためコメントはなし

2.8 Text boundaries & selection(テキスト境界と選択)

Needs Research

 When you double- or triple-click on the text, is the expected range of characters highlighted? When you move through the text with the cursor, or backspace, etc. do you see the expected behaviour? Are there issues when applying punctuation than could be fixed by the application? (Some of the answers to these questions may be addressed in other sections, such as line-breaking, or initial-letter styling.)
   ↓
 テキストをダブルクリックまたはトリプルクリックすると、予想される文字の範囲が強調表示されますか? カーソルやバックスペースなどでテキストを移動すると、予想される動作が見えますか? 句読点を適用する際に、アプリケーションによって修正される可能性のある問題はありますか?(これらの質問に対する回答の一部は、改行や頭文字のスタイリングなど、他のセクションで扱うことができます)。

コメント:

  • ブラウザの挙動に関する項目だろうか。

2.9 Transforming characters(字形変換)

Needs work for basic styling support

Does your script need special text transforms that are not supported? Does your script convert letters to uppercase, capitalised and lowercase alternatives according to your typographic needs? Do you need to to convert between half-width and full-width presentation forms?
   ↓
あなたの言語にはまだサポートされていない特別な文字の字形等の変換処理がありますか? あなたの言語は、すべて大文字、大文字と小文字の選択肢で文字を変換して表示することがありますか(欧文のキャピタライゼーション)? 半角と全角の字形を変換する必要がありますか?

コメント:

  • 字形の自動変換処理に関しての項目。日本語では縦書きと横書きで一部記号類の字形が変わるが、これは既にほぼサポートできている。
  • text-transform: full-width がGecko(Firefox)でのみ動作するとあるが、これは英数字の縦書き時全角変換を指したものだろう。確かにInDesign等でそういった処理はあるが、そこまで一般的なルールでもないので後回しでよいと思う。
  • Kindleは縦書きの際にダブルクォートをダブルミニュート(ノノカギとも言う)に強制自動変換して表示する実装を行っているが、これはどんな場合でもそうなるのが正しいというわけではないので明確な間違いである。コンテンツ制作者が選択すべき部分。

2.10 Inter-character spacing(文字間スペース)

Needs Research

Some scripts create emphasis or other effects by spacing out the letters or syllables in a word. Are there requirements for this script/language that are unsupported? (For justification related spacing, see below.)
   ↓
一部の言語では、単語内の文字または音節の間隔を開けて強調またはその他の効果を表します。あなたの言語に関してまだサポートされていない要件はありますか?(均等割付に関連する間隔の処理については、下記を参照してください。)

コメント:

  • いわゆる「分かち書き」に関係する部分。一般的には日本語では分かち書きは行われないが、カナモジカイに見られるように過去に事例自体はあった。また絵本や障がい者向けコンテンツでは分かち書きを行うことがあるようだ。
  • 日本語でもデザイン的な意味で見出しなどの文字の間隔を開けることはあり、これはletter-spacingで既に実現できている。

2.11 Ruby annotation(ルビ)

Needs work for basic styling support

The ruby spec currently specifies an initial subset of requirements for fine-tuning the typography of phonetic and semantic annotations of East Asian text, including furigana, pinyin and zhuyin fuhao systems. Is is adequate for what it sets out to do? What other controls will be needed in the future?
   ↓
ルビの規格は現在、ふりがな、ピンイン、(主に台湾で用いられる)注音符号のタイポグラフィの初期的なサブセットを規定しています。適切な規格化がなされていますか? 将来的に仕様の追加は必要ですか?

2.11.1 Tabular markup(表形式のマークアップ)

コメント:

  • いわゆる熟語ルビのマークアップに関する項目と思う。熟語ルビに関してはこちらを参照。
     現状ルビタグのマークアップは

     
    <ruby>親<rt>おや</rt></ruby><ruby>文<rt>も</rt></ruby><ruby>字<rt>じ</rt></ruby>

     
     のように行われるが、これを

     
    <ruby><rb>親</rb><rb>文</rb><rb>字</rb><rt>おや</rt><rt>も</rt><rt>じ</rt></ruby>

     
     のようにすることで、(過去に<rp>タグで行われていたような)ルビの表示が難しい環境でのふりがなの補完表示が可能になるということのようだ。また、通常のモノルビでのマークアップの場合の検索性の問題も指摘されている。

     
     「This also makes certain applications of double-sided ruby impossible when the ruby on each side of the base spans a different set of base characters.」がちょっと意味的にわからない。両側ルビで双方のルビが違うベース文字に対してかけられていた場合の問題ということだろうか?(超レアケースだと思います)

2.11.2 Double-sided ruby(両側ルビ)

コメント:

  • 縦組みで左右、横組みで上下に違ったルビを表示するための項目。ルビをどちら側に付けるかを指定するためのプロパティ、ruby-positionを使うことになる。Firefoxで標準動作、Safari、Chromeではベンダープレフィックスがいるが動作する、とある。

2.11.3 Ruby aligment and other styling(ルビの整列、その他のスタイリング)

コメント:

  • いわゆる肩付きルビ、中付きルビなどの指定に用いるプロパティ、ruby-alignに関する項目。Firefoxでのみ動作するほか、Edgeでは独自の構文で動作する、とある(ベンダープレフィックスのこと?)。今電子書籍では一般的にルビは全て中付きになるため、肩付き、中付きを指定できるようになるのは確かに進化ではある。ただ絶対に必要とまでは言えないと思う。

2.12 Text decoration(テキストの装飾)

Needs Research

Some aspects related to the drawing of lines alongside or through text involve local typographic considerations. Do underlines need to be broken in special ways for this script? Do you need support for additional line shapes or widths? Does the distance or position of the lines relative to the text need to vary in ways that are not achievable? Are lines correctly drawn relative to vertical text?
   ↓
テキストに沿って描画される線(傍線)、もしくはテキストの上を通るような線(打ち消し線)の描画に関して、ローカルなタイポグラフィにおけるいくつかの側面を考慮しなければなりません。この言語では、下線を特別な方法で分割する必要がありますか? 線の形や線幅に関してさらなるサポートは必要ですか? テキストと線の距離や位置に関して、現状達成できていない点はありますか? 縦書きのテキストでの線の表現には問題がないですか?

コメント:

  • InDesign等の組版ソフトでは現状さまざまな種類の傍線、打ち消し線のバリエーションを選べるが、電子書籍ではそこまで種類を選べないのでギャップはある。波線などは使えるようになって欲しい。
  • 縦書き時にtext-decorationで指定した線がテキストのどちらの側に付くのかに関してEPUBのRS間で差異があった。このため、安全策としてtext-decorationではなくborderを使う方針としている例がある。
  • 傍線とテキストの間隔の調整などはtext-decorationでは指定できないがborderでpaddingを指定してやれば調整できる。text-decorationでも細かな調整ができるようになるべきなのかどうか。

2.13 Emphasis & highlights(強調表示とハイライト)

Needs work for advanced level support

Bold and italic are not always appropriate for expressing emphasis, and some scripts have their own unique ways of doing it, that are not in the Western tradition at all. Does this script require support for emphasising or highlighting text that cannot be achieved currently?
   ↓
太字やイタリック体は強調の表現に常に適切というわけではなく、一部の言語はそれぞれに西洋の伝統にはない独自の強調表現方法を持っています。日本語は、テキストを強調または強調するための現在達成できていない部分のサポートを必要としていますか?

コメント:

  • 日本語独自の強調表現としては圏点(傍点)があるが、これもEdgeなど一部を除けば基本的にほぼ使える状況にあるはず。ただ圏点の色指定や、特定の文字を指定しての圏点表示などは調査がいりそう。
  • 2.13.1 に追加要件としてルビと圏点が被った場合の表示についての記述がある。Firefoxは現在これを両方表示できる。Chrome、Safariは被った場合は圏点を表示しない。これはどちらが正しいのか議論が必要そう。

2.14 Bidirectional text(双方向テキスト)

Not applicable

コメント:

  • この項目はNot applicable(適用する必要がない)扱いで一般的な話としてはそれでよいと思うが、明治期などの日本語の横書きテキストには右→左の書字方向でに記述されているものがあるのでこれは考えないでよいだろうか?

2.15 Other inline features(その他のインライン項目)

Needs Research

Does the script have special ways of representing inline notes (such as wakiten or kumimoji in Japanese) or other inline features that need to be supported?
   ↓
あなたの言語には、インライン・ノート(日本語のwakitenやkumimojiなど)やサポートが必要なその他のインライン・フィーチャーを表す特別な方法がありますか?

コメント:

  • 「such as wakiten or kumimoji in Japanese」と例を上げてあるが、wakitenは傍点と同じでよいのだろうか。
  • 組み文字は「㍉」「㍾」のようなもののことのようで、これは既に表示できている。

3. Lines and Paragraphs(行と段落)

3.1 Line breaking(改行)

Needs Research

Does the browser capture the rules about the way text in your script wraps when it hits the end of a line? Does line-breaking wrap whole ‘words’ at a time, or characters, or something else (such as syllables in Tibetan and Javanese)? What characters should not appear at the end or start of a line, and what should be done to prevent that?
   ↓
ブラウザはあなたの言語のテキスト改行処理に関してどういう挙動を示していますか? 改行によって単語が分割されることは許可されますか? されませんか? あるいは(チベット語やジャワ語の音節区切りのような)独自の改行に関してのルールがありますか? 行末や行頭に来てはいけない文字はありますか、それを避けるためにどういう処理が行われますか?

コメント:

  • 改行の禁則処理に関しての項目。JLREQでは拗音、促音を行頭に置くことを禁止する、いわゆる「強い禁則」を日本語の基本ルールとしているが、過去の出版物を見る限りでは必ずしもそうとも言えない。歴史ある出版社はむしろ拗音、促音を行頭に置くことは許容していたりする。また、今後Webで日本語のテキストを表示する機会が増えることを考慮すると、画面の小さな端末で1行文字数が少なくても組版の破綻しにくい「弱い禁則」を基本とした方が良いのではないかという意見もある。

3.2 Hyphenation(ハイフネーション)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

3.3 Justification(均等割付)

Needs Research

When text in a paragraph needs to have flush lines down both sides, does it follow the rules for your script? Does the script need assistance to conform to a grid pattern? Does your script allow punctuation to hang outside the text box at the start or end of a line? Where adjustments are need to make a line flush, how is that done? Do you shrink/stretch space between words and/or letters? Are word baselines stretched, as in Arabic?
   ↓
段落のテキストの行末を一直線に揃えるように組版処理が行われることは、あなたの言語のルールに従っていますか? グリッドパターンに従うように組版処理を行うために補助は必要ですか? あなたの言語は句読点がテキストボックスの行頭もしくは行末にはみ出して表示されることを許容していますか? 行末ラインを一直線に揃えるために各行内のスペース調整が必要な場合、それはどのように行われますか? 文字や単語の間のスペースを伸縮させていますか? アラビア語のように単語のベースラインは伸びていますか?

コメント:

  • 均等割付(ジャスティファイ)に関する項目。日本語は一般的に均等割付処理が行われる言語で、また単語と単語の間にスペースを入れることは一般的には行われず、均等割付のためのスペース調整は文字と文字の間をツメる、アケるという形で行われる。行頭字下げ、行末字上げや行中の括弧類、句読点など前後のツメ・アケ処理に関連する現在規格策定中のプロパティ、text-spacingはここで議論されるべき項目だろう。
  • 伝統的な日本語書籍組版には「書字方向のテキストボックスのサイズを本文文字サイズの整数倍にする」というルールがある(いわゆるベタ組)。これもここの項目の範疇だろう。

3.4 Counters, lists, etc.(カウンター、リスト)

Needs work for basic styling support

The CSS Counter Styles specification describes a limited set of simple and complex styles for counters to be used in list numbering, chapter heading numbering, etc.The rules plus more counter styles (totalling around 120 for over 30 scripts) are listed in the document Ready-made Counter Styles. Do these cover your needs? Are the details correct? Are there other aspects related to counters and lists that need to be addressed?
   ↓
CSS Counter Stylesの仕様はリストや章見出しの番号などに用いられる限定されたシンプルな、あるいは複雑なスタイルを規定しています。追加されるカウンタースタイル(トータルで30の言語にまたがる120種類にもなる)は、Ready-made Counter Styles.にリストアップされています。これはあなたのニーズを満たしていますか? 細部は正しいですか? カウンターやリストに関して対処しなければならない別の側面の課題はありますか?

コメント:

  • リストや見出しの自動ナンバリングに関しての項目。現状<ol>タグで囲ったリストでは各項目先頭に自動でナンバリングされた数字やアルファベットを表示できるが、これの種類の拡張が検討されている。Ready-made Counter Styles.を覗いてみると、「甲・乙・丙・丁」や「子・丑・寅・卯・辰・巳」といったような項目も見える。また、縦書き時のリストナンバーにピリオド付き数字を使う例も挙げられている。li::marker { text-combine-upright: all; }の指定を使うようだが、これはまだ一般的には使用できないとのこと。
  • 電書協ガイドでは本文中にリスト構文を使うことを禁止しているが、セマンティクスやアクセシビリティの観点からは本来はリストはリスト構文で記述されることが望ましい。

3.5 Initial letter styling(段落先頭の文字のスタイル)

Needs Research

Does the browser or ereader correctly handle special styling of the initial letter of a line or paragraph, such as for drop caps or similar? How about the size relationship between the large letter and the lines alongide? where does the large letter anchor relative to the lines alongside? is it normal to include initial quote marks in the large letter? is the large letter really a syllable? etc. Are all of these things working as expected?
   ↓
ブラウザやeリーダーは、ドロップキャップなどの行や段落の最初の文字の特殊なスタイルを正しく処理していますか? 大きな文字が入った際の行間のサイズ関係はどうですか? どこに大きな文字のアンカーは並んでいますか? 大きくした文字の最初に引用符を含める表示は正しいですか? 大きな文字は本当に音節ですか? これらのすべてが期待どおりに機能していますか?。

コメント:

  • ドロップキャップなど、段落の先頭文字に特殊な組版処理を行う例は日本語書籍ではあまり多くはないが、雑誌などを見るとそれなりの頻度では使われている。またこれは段落の最初に文字が来たときに限らないが、行中の一部の文字を大きくした際にline-heightがそれに引きずられて変わってしまい、レイアウトが崩れる例はずっとある。CSS Rhythmic Sizingでそのあたりが手当てされるはずなので普及を待ちたい。

3.6 Baselines & inline alignment(ベースラインとインラインの文字揃え)

Needs Research

Does the browser support requirements for baseline alignment between mixed scripts and in general?
   ↓
ブラウザは、多言語混植の場合と一般的な場合それぞれに対してベースライン位置揃えができていますか?

コメント:

  • 上付き、下付きなどで使われる行中の一部の文字の位置合わせの指定。上付き、下付き程度ならば現在もう使えるが、多言語の混植となるとちょっとわからない。

3.7 Other paragraph features(その他の段落の機能)

Needs Research

In your script, is the first line of text typically indented at the start of a paragraph? Are there other features of paragraph design that are peculiar to your script?
   ↓
あなたの言語では一般的に段落行頭のインデントが行われますか? あなたの言語に特有の段落デザインに関するそれ以外の機能はありますか?

コメント:

  • 日本語は一般的に段落行頭字下げを行う言語なのでここは相当する。

4. Layout & pages(レイアウトとページ)

4.1 Bidirectional layout(双方向レイアウト)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

4.2 Vertical text(縦書きテキスト)

Needs work for basic styling support

Are the script requirements for vertically oriented text met? What about if you mix vertical text with scripts that are normally only horizontal? Do you need a switch to use different characters in vertical vs. horizontal text? Does the browser support short runs of horizontal text in vertical lines (tate-chu-yoko in Japanese) as expected? Is the orientation of characters and the directional ordering of characters supported as needed?
   ↓
縦書きテキストの言語的要件は満たされていますか? 縦書きの文中に通常横書きでしか表記されない多言語が混ざった場合の表示はどうでしょうか? 縦書き、横書きで異なる文字を使用するためのスイッチがいるでしょうか? ブラウザは(日本語の縦中横のような)縦書きテキスト中にごく短く横書きが混じるようなケースをサポートできていますか? 必要に応じた縦書き中の文字の向きの指定はサポートできていますか?

コメント:

  • 和文中に英文が混じる程度の表記はほぼ表示が実現できているが、アラビア語のような右から左に書くような言語でどうなるかは調査してみないとちょっとわからない。
  • 縦横で文字の字形(句読点や括弧類など)を随時切り替える仕組みは既に動いている。
  • セマンティックス的には異なる言語が挟まる際には属性値langおよびxml:langで該当部分を指定し、それに準じてフォントが変わる形が良いように思う。

4.2.1 Vertical form controls(縦書き時のフォームのコントロール)

One major gap is handling of vertical text in forms. Only the Firefox desktop browser does a good job of this.
   ↓
大きなギャップの一つがフォーム内テキストの縦書き時の表示です。現状Firefoxだけがこれをうまく処理できています。

コメント:

  • これは日本語組版ではなく完全にWebサイト制作での話。ひとりのユーザーとしてはフォームは横書きでよい気はしている。ドロップダウンメニューなどはそのまま横倒しにして配置されてもちょっと違和感がある。

4.2.2 Upright text orientation(テキストの正立指定時の向き)

Another gap is the CSS text-orientation property. It is only supported as standard by Firefox. Safari has buggy support if you use the -webkit proprietary extension: it has a problem centering the letter in the vertical line.
   ↓
さらにCSSのtext-orientationプロパティにもギャップがあります。これはFirefoxのみでサポートされています。-webkitのベンダープリフィックスを使用している場合、Safariはバグのサポートを受けています。垂直に文字をセンタリングするときに問題があります。

コメント:

  • 縦書き中の文字の正立横転指定(text-orientation)は効かないRSがまだ多い。また、関連してまだUnicodeの標準的な縦書き時の文字の向きの基準に準拠できていないRSもあり、表示するRS次第で文字の向きが変わってしまうような現象も起きている。Kindleでのキリル文字、ギリシャ文字などがこれに相当する。
  • 1桁の英数字を正立で表示させたい場合に一般的に行われているTIPSとして「全角文字に打ち替える」というものはある。ただ困るのは必ずしも全角文字があるわけではない記号類なので早めのギャップ修正が望まれる。
  • EPUB制作では現状text-orientationがアテにできないため、代替としてtext-combine-uprightを使うということが行われている。

4.2.3 Tate-chu-yoko(縦中横)

The CSS text-combine-upright property works with the all value in all major browsers, although for Edge you need to use the proprietary property -ms-text-combine-horizontal.
With the digits value, it is only supported by Edge (with it’s proprietary property name), but Edge stretches single digits to fit the width of the (vertical) line. Tests:
   ↓
text-combine-upright:allは全てのメジャーなブラウザで動作しますが、Edgeではベンダープリフィックス付きの-ms-text-combine-horizontalを使う必要があります。
text-combine-upright:’digits’(指定テキスト内の何桁の数字までを縦中横表示するかを指定する自動縦中横の指定)は現在Edgeで(ベンダープリフィックス付きで)のみサポートされていますが、Edgeは数字の横幅を縦組みの行の横幅に引き延ばして表示してしまいます。

コメント:

  • 縦中横は動作する環境がほとんどだと思われるが、text-combineのみをサポートしていてtext-combine-upright(こちらが最新のプロパティ)のサポートが遅れているRSはあり、またまだベンダープリフィックスが必要なRSもある。
  • 縦中横の際の字形変化の挙動に関しても統一はされておらず、何桁あっても変形させて1emに入れようとするもの(これを1桁英数字の場合にも適用してしまうのがEdge)、変形はせずに横書きで表示し、文字数が多すぎると隣の行に重なる実装をしているものの2種に大別される。
  • 一部RSではフォント内のグリフ情報を呼び出して等幅3分字形、等幅4分字形などで表示するような実装も見られるようだ。

4.2.4 Lists(リスト)

 3.4で既出なので割愛

4.2.5 Table cells(表のセル)

If you place the writing-mode property with a value of vertical-rl on an individual table cell, you would expect the text in that cell to be displayed vertically. This works as expected in Edge, Internet Explorer and Gecko browsers. Blink and Webkit browsers, on the other hand, leave the text horizontal but rotate the characters to the left. Note, also, by the way that you have to set the height of the cell in these browsers for a span to be displayed vertically.
   ↓
表組みの個々のセルに対してwriting-mode:vertical-rlの指定をすると、そのセル内のテキストが縦組みで表示されます。これはEdge、Internet Explorer、およびGeckoのブラウザ(Firefox)では正常に動作します。一方、Blink(Chrome)とWebkit(Safari)のブラウザでは、テキストは水平のままで文字を左に回転させて表示してしまいます。いずれにせよ正しく表示させるために、これらのブラウザでセルの高さを設定する必要があることにも注意してください。

コメント:

  • 表組みの項目行のみ縦組みというのはかなり目にはするので実現できるようになることを期待したい。

4.2.6 Logical properties(論理的プロパティ指定)

A great deal of time and confusion can be saved by using ‘logical’ properties, rather than right, left, top and bottom, for things such as alignment.
CSS is developing the necessary keywords in the Logical Properties specification, which at the time of writing is still an editor’s draft. Some of the properties described there, however, are already supported by browsers.
Unfortunately, Microsoft Edge still doesn’t support the start and end values for text-align
   ↓
たとえば(padding、marginなどの)方向の指定のために上下左右ではなく「論理的」な値で指定することで、混乱を避け時間を大幅に削減できます。
CSSはLogical Properties仕様で論理的な指定のための値を決めていますが、これはまだ現在はエディターズドラフトの段階です。ただし、そこに記述されているプロパティの一部は、すでにブラウザでサポートされています。
残念ながら、Microsoft Edgeではtext-alignのstartとendの指定値はまだサポートされていません。

4.3 Notes, footnotes, etc.(注釈、脚注ほか)

Needs Research

Does your script have special requirements for notes, footnotes, endnotes or other necessary annotations of this kind in the way needed for your culture?
   ↓
あなたの言語には注釈、脚注、後注などに対して何らかの特別な文化的要望がありますか?

コメント:

  • 注に関する項目。日本語書籍での注の表示のひとつに「割注」があり、これはJLREQにも記述があるのだが、アルゴリズム的にはWebやEPUBでの実現は難しそう。個人的意見としては電子では必要ないのではないかと思う。紙の本の割注も決して読みやすいわけではない。また、これは項目的には3の「Lines and Paragraphs」の中に項目を立てるべきかもしれない。
  • EPUBで画面を分割して脚注を表示するのはコンテンツによってはニーズがありそうだがまだ一般的なブラウザでの実現はできていない。また、epub:type=”footnote”の指定による脚注のポップアップ表示は現在iBooksおよびKoboのiOS版、EdgeのEPUB表示(脚注のテキストが同一のXHTML内にある場合のみ)で実現できている。

4.4 Page numbering, running headers, etc.(ノンブル、肩文字その他)

Needs Research

Are there special conventions for page numbering, or the way that running headers and the like are handled?
   ↓
ノンブルや肩文字の扱いに関して特別な規則がありますか?

コメント:

  • ノンブルや肩文字に関する項目。現状EPUBではOPFに記述された書名が肩に表示される実装を行っているRSが多いが、一部のRSではXHTMLのTITLEタグに記述されたテキストを表示するようだ。いずれにせよRS側の独自処理であり、制作側がCSS等で指定できるわけではない。

4.5 Other page layout & pagination features(その他ページレイアウトと改ページ機能に関するもの)

Needs Research

Some cultures define page areas and page progression direction very differently from those in the West (eg. kihon hanmen in Japanese). Is this an issue for you? Are widows and orphans relevant? In what order do pages progress, RTL or LTR?
   ↓
いくつかの文化では、ページ領域とページ進行方向を西洋のそれとは非常に異なる形で定義しています(例:日本語の基本版面)。ここに何かしらの問題はありますか? ウィドウ、オーファン(孤立行)などについてはどうですか? ページ進行方向は右→左ですか、あるいは左→右でしょうか?

コメント:

  • EPUBでのページ番号に関する話として、実ページリンクの話題がある。これは電子教科書方面でのニーズから策定された規格のようで、リフロー型EPUBのXHTMLの中に紙の本での各ページ開始位置をタグとして記述しておき、RS側の処理でページ番号を表示させるものだ。iBooksでかなり前から使えるほか(参照)、最近はAmazon Kindleもパブリッシングガイドラインで対応を表明した(サーバ側処理が必要なため表示未確認)。専門書などでは底本内にとても多くのページ番号に基づく参照情報があり、その中には外部の他の本に対する参照情報も当然多数含まれる。一方でEPUBには現状外部の他のEPUBパッケージ内の特定の箇所にリンクを貼る手段がない。このため、おそらく専門書のリフローでの電子化を今後進めていくには実ページリンクを広く使っていく必要が出てくるのではないかと考えている(あるいはフィックス型で電子化するかだが・・・)。

5. Other(その他)

5.1 Culture-specific features(文化特有の機能)

Needs Research

Sometimes a script or language does things that are not common outside of its sphere of influence. This is a loose bag of additional items that weren’t previously mentioned. This section may also be relevant for observations related to locale formats (such as number, date, currency, format support).
   ↓
言語は時に、その影響の圏外では通用しないことをすることもあります。これは以前には言及されていなかった追加項目に対応するための項目です。このセクションは、ロケールフォーマット(番号、日付、通貨、規格のサポートなど)に関連する項目にも関係します。

5.2 What else?(何か他にありますか?)

Needs Research

There are many other CSS modules which may need review for script-specific requirements, not to mention the SVG, HTML, Speech, MathML and other specifications. What else is likely to cause problems for worldwide deployment of the Web, and what requirements need to be addressed to make the Web function well locally?
   ↓
SVG、HTML、Speech、MathML、その他の仕様はもちろんのこと、スクリプト固有の要件のレビューが必要な他の多くのCSSモジュールがあります。Webの世界的な展開にあたって何かしらの問題が発生する可能性がある要素は他にありますか? Webの機能をローカルでうまく機能させるためにはどのような要件を解決する必要がありますか?

 以上です。推測して用語を補足せざるを得なかった箇所もありますし、自分的にスコープ外の部分は流してもいます。全文の忠実な翻訳ではないことにご留意ください。意図の取り違え、単純な間違いなどありましたらご指摘いただけると助かります。

(2018.10.19)



Kindleで画面内表示画像サイズを%指定する

2018/09/28

 各ストアビューア向けのEPUB制作で、画面サイズに対して%で画像表示サイズを指定することは長らくできておらず、悩ましい問題です。これは2014年頃にEPUB組版表現の対応状況を調査し始めてから状況がずっと変わっていません。特にKindleでは、PaperWhiteなどの電子ペーパー専用端末とAndroid版では%指定が効くものの、iOS版Kindleアプリで効かないという状況が続いており(参考/項目7-9)、このために画像を画面内の特定のサイズで表示させるために「余白部分込み」で画像化するというまるでWebの初期のようなTipsを使用せざるを得ませんでした。
 これをやってしまいますと、ビューア側の設定で背景色を変えた際に余白部分が白く表示されて見えてしまうので可能ならば避けた方が良いのですが、サイズ指定が効かないよりはマシということで使われてきたわけです。
 ただ、最近JAGATの研究会活動の一環として改めて挙動をチェックしてみたところ、%指定が効かなかったiOS版Kindleでもどうやら単位にvw/vh※1を用いたサイズ指定なら効くことがわかりました。であるならば、もしかしたら%とvw/vhを同じ値で指定してやることでKindleの全プラットフォーム共通のサイズ指定ができるかもしれません。ということで試してみよう、というのが今回の趣旨です。

iOS版Kindleでサイズ指定が効いた!

 以下のようにCSSの指定を書き※2、テストファイルを作ってテストをしてみます。

 iOS版Kindleでの表示結果は以下の感じ。

iOS版Kindleの表示結果

 KindleはiOS版以外では普通に%指定が効くため、iOS版でサイズ指定が効けばよいので目論み通り成功です。他のKindleデバイスでも不具合は出ていないようです。ただ他社のビューアで不具合が出る可能性がありますので、一応それも見てみなければなりません。

他社製EPUBビューアで不具合が出る

 ということで他社ビューアでの表示結果もチェックしたのですが、残念なことにあるビューアで表示の不具合が出てしまいました※3。どうやらline-height(行高指定)とtext-combine-upright(縦中横)が効かなくなるようです。さて困りました。

メディアクエリで適用範囲をKindleのみに限定できないか

 ここで思い出したのがKindleのメディアクエリです。メディアクエリは一般的には表示ウィンドウサイズに応じて異なるCSSを当てる際などに使う技術ですが、Kindleでは「@media amzn-kf8」「@media amzn-mobi7」などの形で、デバイスごとに表示を切り替えるための独自の値を定義しています※4。これを利用してCSSの適用範囲をKidleのみに限定できないでしょうか。ということでCSSにメディアクエリを追記して再テストをしてみます。CSSは以下のような感じ。

 はい、成功です。

 ということでひとまず目的は達しました。とはいえ%でのサイズ指定が効かないのはKindleだけではなく、Mac版iBooks(もうApple Booksですが)でも同様だったりしますので、出来るなら将来的にはメディアクエリは外したいところです。各電書ストアビューアの表示対応を期待します。

※1 vwは表示中の画面(ビューポート)の横幅に対しての%指定、vhは高さに対しての%指定の意味。参考記事はこちら
※2 電書協EPUB3制作ガイドのCSS記述を参考にしている。
※3 中の人に報告上げてブログ記事作る間に該当のビューアで修正がかかった模様。対応が早くてありがたい。とはいえ不具合が出るビューアが1社だけとは限らないので記事としては残しておく。
※4 参考:http://epubsecrets.com/media-queries-for-kindle-devices.php

おまけ
EPUBで電書協ガイドの規定クラスに追記するには以下の形になるはず。book-style.cssの作品別カスタマイズ領域に書けばよい。

(2018.10.1)



「Kindle パブリッシングガイドライン 2018.2」更新内容チェック

2018/08/03

Amazon Kindle向けコンテンツ作成の仕様書、「Amazon Kindle パブリッシングガイドライン」が更新されていたようですので、更新部分をざっくりとチェックしました。英語版はこちら。以下、見出しは元文書の見出し項目そのまま、赤字は特に重要と思われる箇所です。ご一読ください。

“2.1.1 Kindle Create”

 Kindle Createについての表記追加。.doc/.docx形式のファイルからKindleドキュメントを生成できるもの。ただし現状まだ日本語には未対応のよう。

“3 フォーマットの比較”

 「タイプセッティングの改善のコラムを追加」とある。ここでのコラムは表組みの「列」の意味と思われる。

“6.7 サポートされる文字とスペースの使用”

 「問題を起こす可能性があるため、Unicode 形式の文字は使用しないでください」とあるが、「Unicode 形式の文字」は英語版ドキュメントでは「Unicode format characters」とあり、「Unicodeの制御文字」と訳すべき箇所。
 おそらくU+0000 – U+001F(C0制御コード)、U+007F(削除文字)、U+0080-U+009F(C1制御コード)などを指していると思われるが(参考)、U+2028(LINE SEPARATOR)、U+2029(PARAGRAPH SEPARATOR)なども制御文字であるため注意が必要。また、U+0000〜U+001Fの制御文字のエリア内でもU+000A(LF)やU+000D(CR)などは改行コードであり、これを使うなというのは現実味がない。具体的に使うべきでないコードポイントを明示して欲しい。

“7.1 内部リンクに関するガイダンス”

 「意図しない脚注のポップアップが表示されないようにするには、脚注ではない内部リンクに双方向ハイパーリンク (A から B へのリンクと B から A へのリンク) を設定しないでください。」とある。作り方としては一般的だが、制作指針に縛りをかける要望ではある。
 また「現在、電子書籍端末の固定レイアウトの本では、内部ハイパーリンクはサポートされていません。」とあり、ここはずっと変わっていない。

“7.2 外部リンクのガイドライン”

 「本から外部Webサイトへのリンクは、読者体験とAmazonによって定められた本のコンテンツをより一層意義あるものにし、それらに直接関係のある場合に限ります。」とある。外部へのリンクは技術的に可能でも規約上の制約がかかるため注意が必要。
 「Amazonはリンクを独自の判断で削除する権利を有します。」ともある。

“9.1 メタデータのガイドライン”

 「<dc:language>」および「<dc:title>」が必須、ページめくりの方向が左から右ではない場合、メタデータまたは背表紙に「<meta name="primary-writing-mode" content="horizontal-rl"/>」のような形でページめくり方向を明示する必要がある、との記述。これはAmazon独自のメタデータなので注意が必要。従来これはフィックス型のEPUBでのみ必要な措置だったように記憶しているのだが、リフロー型でも必要になったようにも読める。だとすればメタデータの追記が必要になるだろう(ちなみにこの「horizontal-rl」という記述も以前からある罠で、「horizontal-lr」もしくは「vertical-rl」になると思われる。一度引っかかった)。なお、 「背表紙」は「Spine」をそのまま訳してしまったミス。OPFのSpine項目への記述のことと思われる。「<spine page-progression-direction="rtl">」の記述で代替できるということか?

“9.3.11 Real Page Number の有効化”

 実ページ番号のサポート。教科書など教育関係の本で要望がずっとあったもので、iBooksなどではかなり前からサポートされていた(参考)。
 「出版者は、電子書籍のReal Page Numberをその電子書籍と最も一致度の高い印刷版(ハードカバー、ペーパーバックなど)にマッピングし、ISBNをhttp://kb.daisy.org/publishing/docs/navigation/pagelist.html#descに従いメタデータに指定する必要があります。」とあり、紙版の書籍と電子版の双方を刊行する前提の本で使うことを想定したものであることがわかる。米国などでのKindleの教育市場へのニーズを伺わせる機能追加。おそらくは電子教科書用だろう。
 なお、「サイドロードでプレビューできませんが、電子書籍が出版されると表示され、詳細ページにも記載されます。」とあり、残念ながら実際の挙動を確認することはできなかった。

“9.3.12 脚注のガイドライン”

 「脚注のマーキングには HTML5 の aside 要素を epub:type 属性と組み合わせて使用することを強くお勧めします。その場合、アクセス可能な端末では指示が追加されていない限り脚注を無視することができます。」とある。脚注を通常の画面内では非表示にし、リンクを叩いた際にだけ表示させるという意味かと思う。
 脚注のポップアップ表示にも対応したとのこと。なお脚注のポップアップ自体はiBooksや楽天KoboのiOS版、Microsoft Edge(同一xhtmlファイル内に脚注のジャンプ先がある場合のみ)では既に対応済み(参考)。Kindleでは専用端末のKindle PaperWhiteなどで脚注表示の挙動は見られたが、これはepub:type 属性を無視して相互リンクを脚注と見なす極めて不完全な対応だった(参考)。
 KindleがEPUBの脚注の正式な規格であるaside要素およびepub:type属性への対応を謳ったのは今回が初である。どう変わったのか挙動を見てみたのだが、現状Kindle FireおよびKindle PaperWhiteでポップアップの挙動は見られなかった。また、Kindle PaperWhiteではリンク自体が動作しないという挙動があり、これは早急に修正して欲しいところ。

“9.4.11 サポートされている SVG タグと要素を使用する”

 SVGの項目自体は以前からあったが、「タイプセッティングの改善」に関係する記述が追加されている。ここだけでなく影響はありそうなので注意が要りそうだ。

“9.5.2 シンプルな HTML の表を作る”

 ここにも「タイプセッティングの改善」に関する追加記述がある。

“9.6 MathML のサポート”

 数式のMathML表記をサポートしたとのこと。

“15.1 タイプセッティングの改善について”

 今回の更新内容の多くの項目が「タイプセッティングの改善」機能に絡むものだが、日本語はまだ対応言語に入っていないようなのでまだ考えなくてよい模様(15.5 
サポート対象の言語)。

“16 付録 B: タイプセッティングの改善でサポートされている属性とタグ”

 サポート対象のCSSプロパティ、HTMLタグが列挙されている。

今回、Real Page Number対応やepub:type 属性での脚注ポップアップ対応、MathML対応など大きな追加ポイントがありましたが、潜在的に最も大きな変化は「タイプセッティングの改善」(まだ日本語非対応ですが)に関するものでしょう。これは改訂履歴の項目の大部分がこれ絡みであることからわかります。
どうもずっとこの機能は謎のままだったのですが、今回の改訂から推測する限りでは、フォントサイズや端末の種類に伴う画面サイズなどの変化に応じてKindle側が随時CSSの値の調整を行う機能であるように思われます。つまりメディアクエリ的なことをKindleが自動でやるということです。これは日本語コンテンツでも使えるようになれば相当以上に大きな変化がもたらされるものと思います。ただし実機でのコンテンツ表示チェックは相当以上に大変になりそうです。Amazonがレンダリングエンジンの不具合を長期放置している理由もこれの対応が絡んでいるような気はします。

(2018.8.6)



プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。