‘EPUB3’ タグのついている投稿

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)

 4.4 に関して肩文字→柱文字に訳語を修正しました。

(2018.11.5)

JAGATセミナー「EPUB制作現場の実態と今後の課題」を終えて

2013/06/28

 6月17日、JAGATにて「EPUB制作現場の実態と今後の課題」と題しまして、緊デジなど昨年度のDTPデータからの電子書籍作成の状況を実際に電子書籍制作を担当した現場の視点で語ってもらい、今後の制作環境の構築に役立ててもらおうということを狙いとしたトークセッションが行われました。こちらは私がJAGATさんにお願いしまして実現したイベントなのですが、有り難いことに多くの方にご来場いただき、ご好評をいただいたようで何よりでした。

 今回はセミナーでお話ししたことの振り返りとまとめです。以前に触れたことと重複する部分もあるかとは思いますがご容赦ください。

昨年度までの電子書籍関連トピックスの軽いおさらい

 昨年度は緊デジなどを含めて、電子書籍関連の大きなニュースがそれこそ日替わりで飛び込んできた感がありました。ここで緊デジ、EPUB3を中心として、昨年度までの出来事を時系列順に軽く振り返ってみたいと思います。

2011/10/10:EPUB 3.0 Final Specification(IDPF)

 IDPFによるEPUB3の最終勧告です。ひとまずこれをスタートラインとします。

2011/10/14:EPUB3日本語ベーシック基準 Draft1.0(ボイジャー/インフォシティ)

 EPUB3の最終勧告を受けて発表された日本語書籍向けEPUBガイドラインです。こちらはボイジャーさん、インフォシティさんが中心になってまとめたもの。

2011/11/24:JBasic08(イースト)

 同じく日本語書籍向けEPUBガイドラインです。こちらはイーストの高瀬さんが中心になってまとめたものです。この時の会議には私も参加させていただいています。

2012/3末:緊デジ説明会

 年度末の3月末に行われた「経済産業省コンテンツ緊急電子化事業」通称緊デジ事業の説明会です。沢辺さんがユニークな説明をされていたのを覚えています。この時に中核企業としてパブリッシングリンクさんが入ることが発表されています。

 この時に配布された資料からの抜粋です。

  • 「出版デジタル機構は100万タイトルの制作を目指す」
  • 「中間交換フォーマットと.book/XMDFの配布用ファイルの双方を納品」
  • 「緊デジフォーマットは出版デジタル機構でも採用する」
  • 「PDFは採用しない」

 ここで出てきた「中間交換フォーマット」は、三省懇で作られたもののことを指していたようなのですが、独自仕様のXMLです。これはこの時点では仕様がほとんど公開されておらず、後日発表の詳細な資料待ちと言った状況でした。PDFが不採用だった理由は各電子書籍ストアの販売体制の問題とのことだったように思います。

2012/4/2:出版デジタル機構正式に発足

 出版デジタル機構正式設立はこの日でした。当時の出版デジタル機構(仮称)準備会のサイトには、設立の目的として、

  • 「国内における電子出版ビジネスの公共的なインフラを整備することで、市場拡大を図る」
  • 「日本の電子出版物の国際競争力を強化する」
  • 「研究・教育・教養分野における電子出版物利用環境を整備する」
  • 「国内で出版されたあらゆる出版物の検索を可能にする」
  • 「電子出版・電子書店などへの新規参入を容易にし、誰でもが電子出版による言論表現活動に参加できるようにする」

 との文言があります。このニュースは、さまざまなメディアでかなり大きく取り上げられました()。

2012/4/10:電子化仮申請「93,725」点

 これは日本出版インフラセンター(JPO)が行った各出版社からの電子化希望数の集計数です。ただしこの時点では著作者サイドの二次使用許諾が取れていなくてもOKとしたため、あくまで「仮」の集計でした。

2012/5/10:電子書籍制作仕様書確定版公開

 コンテンツ緊急電子化事業電子書籍制作仕様書v1.01の発表です。この時点での規定内容をちょっと抜粋しますと

  • 「配信用電子書籍ファイル(XMDF or .book)」と「アーカイブ用中間作業ファイル」の納品
  • 「現状ではEPUB3の基準になる日本語用ビュアーが揃わないため、当初は制作・配信ともに実績のあるXMDFもしくはドットブック形式を出版社や電子書店の意向を受けて作成する」
  • 「同時にビルド(電子書籍パッケージ化)直前の状態のXMDF記述フォーマットやTTXなどの作業ファイルを納品してもらい、アーカイブ」
  • 「中間作業ファイルを保存しておくことによって、市場がEPUB3や次世代の電子書籍フォーマットを必要とした時点ですぐに再ビルドが可能な状況を目指す」

 とあります。ポイントは「中間交換フォーマット」が「アーカイブ用中間作業ファイル」に変わったことで、つまり独自仕様のXMLファイルの納品からXMDF/ドットブックの中間作業ファイルの納品へと方針が変化したわけです。現実味のある形になってきたと言えます。この時点でもまだ求められる納品ファイルはXMDF/ドットブックのみでしたが(リフロー型)、実際まだこの時点ではEPUB3を全面採用したストアはなく、信頼できるビューアもほとんど存在しない状況でしたので、まず現実的な判断だったと思います。

2012/6上:電子書籍制作発注会社公募説明会

 緊デジ電子書籍制作の「正規受注会社」の公募説明会です。東京会場、東北会場に分けて2回行われています。東京会場での説明会は講談社さんの社内ホールで行われたと記憶しています。このあと応募社に対して1次審査が行われ、通過した会社に対して試作コンテンツの制作依頼が発注されました。この時点ではリフロー型のEPUB3は採用されていませんので、ドットブックもしくはXMDFでの試作です。

2012/7/2:楽天Kobo日本市場参入発表

 2011年末に楽天に買収され「楽天Kobo」となったKoboの日本国内事業開始発表です。これは初のEPUB3全面採用ストアの登場基準になる日本語用EPUBビュアー(Kobo touch)の登場を意味していたため、EPUB3普及の決定的な分水嶺となる出来事だったように思います。

2012/7/25:緊デジタイトル申請条件緩和

 Kobo参入を受けて緊デジのタイトル申請条件の大幅緩和が行われています。内容は以下の通り。

  • 「上限を年間発行点数の2倍まで」という申請上限の廃止
  • 図書寄贈の義務化も「可能な範囲での寄贈」に
  • EPUB3リフロー型の採用
  • 制作会社の指定が可能に
  • PDFフォーマット指定可能に

 制作会社の出版社側からの指定が可能になり、EPUB3リフロー型が採用されたことで「ほとんど仕切り直し」になった感があります。この時点ですでに正規受注制作会社の審査中でしたので、なかなかやきもきさせられた記憶があります。

2012/8/10:電子書籍制作発注会社発表

 緊デジ制作会社の審査発表です。「なお、EPUBの制作と入力・校正に関する審査につきましては、後日改めて発表いたします」とありますので、これはあくまでXMDF/ドットブックの制作会社という扱いだったようです。「東北作業○○%以上」等の表記がかなり目立つことでわかるように、ここでの審査基準は東北との関連性がかなり重視されたようです。

2012/9/5:緊デジ更なる条件緩和

 ここで、更なる条件緩和が発表されています。内容としては

  • 「EPUB3へのコンバート対応」
  • 「第二次出版社申請受付」

 の2点です。コンバート対応は、すでにXMDFやドットブックになっているものをEPUB3に変換するのを1タイトルとして数えるというような話で、おそらく緊デジの制作物のうちかなりの割合がこれだったのではないかと思われるのですが、発表資料からは詳細な内容が読み取れないので分かりません。

2012/9/11:「電書協EPUB3制作ガイドver.1.0」発表

 電書協からEPUB3制作ガイドの発表です。このガイドの性格についてはさまざまな否定的な意見もあったのですが、「印刷物からの電子化」という目的に限って言えば、かなり制作現場の現実に即したガイドラインかと思います。

2012/10/5:緊デジEPUB3テンプレート公開

 電書協EPUB3制作ガイドの発表を受けて、緊デジのEPUB3が「電書協EPUB3 制作ガイド」に準拠することが発表されました。7/25の発表で緊デジでリフロー型EPUB3が採用されること自体は発表されていたのですが、どういったEPUB3を制作すべきかの指針は示されていませんでした。それがここで規定された形になります。

 これでようやく、EPUB3のビューア、マークアップ規定が揃い、実際にEPUB3を制作できる環境が整ったことになります。とはいえ、もうこの時点で制作期間は半年を切り、かつある程度誰もが制作に参画できるわかりやすいツールがあるわけでもありませんから、前途多難が予想されました。

2012/10/25:Amazon Kindle日本市場参入

 長らく参入がささやかれていたAmazon、Kindleが正式に日本市場参入の発表をしたのがこの日です。実質これで完全に「電子書籍」の市場形成が確立した感があるように思います。

2012/12/14:ボイジャー「BinB」による緊デジEPUB校正システム稼働開始

 ボイジャーの「BinB」を利用した緊デジの公式なEPUB3校正システムが、この日に開始されています。出版社サイド、制作者サイドが同じ環境でコンテンツを見ることが保証されなければ効率的なコンテンツ制作環境は期待できませんから、これは重要な一歩だったと思います。

 ただし、初期にEPUB3の表示の乱れが多く見られたことや、制作側が柔軟に何度もアップロードして更新できる仕組みになっていなかったこと、ボイジャー社が不具合を修正してもサーバのアップロードスケジュールとの兼ね合いですぐに修正が反映されなかったことなど、課題も数多く見られました。
 上記の理由で実際にはこちらの校正システムを使用せず、ストアのビューアなどを利用してEPUB3制作を進めた制作会社も多かったのではないかと思います。

2012/12/31:緊デジリフロー型底本/データ発送〆切

 緊デジタイトルの出版社からパブリッシングリンクへの発送〆切です。フィックス型は10日ほど余裕があり、1月11日に設定されていました。当然といいますか、ここにとても多くのコンテンツが殺到したようです。この時点での正式な納品最終納期は1月31日でした。正直軽くクラクラしました。

2012/1/23:制作納期の最終デッドラインの通知

 この日、制作会社のみに向けて、制作納期の本当のデッドラインが告知されています。

2012/2/19:EPUB制作時の参考資料「正立指定が必要な文字」の公開

 EPUB3およびWebで長らく懸案となっていた縦組み時の記号類の正立/横転表示が各ビューアによって異なることに対処するための基礎資料の公開です。この資料自体は大変有用なもので、私もとても助かったのですが、この時期にこういった「基礎的な資料」が公開されていること自体、実質的にはEPUB3制作のフロー自体がこの時点でも未完成であったことを示唆しているように思います。(参考:Draft Unicode Technical Report #50 UNICODE VERTICAL TEXT LAYOUT

2013/2/27:緊デジ制作仕様書v1.8の発表

 この日に発表された緊デジ制作仕様書v1.8には、「納品するファイルを明確にするため、ファイル/フォルダ保存・命名ルールを詳しく規定し直した」という記述があります。実際にはこのあたりにデータの納品が集中していたことがわかると思います。

2013/3/1:重要なお知らせ:制作納期の期日につきまして の告知

 ここで制作納期が「3月18日まで」、とはっきり線引きがされています。ここが本当の最終デッドラインということでしょう。窓口担当者は相当大変だったろうなと同情を禁じ得ません。

2013/6/3:タイトル申請数と達成状況の最終確定値ならびにタイトルリストの公開

 緊デジ事業終了後の資料公開です。総タイトル数は64,833とのことでした。資料が取り回しにくいPDFで、また出版社名すらない「タイトルのみの羅列」だったことなどからかなり批判も出ました。これに関しては、今後の電子書籍制作環境の整備のためにも、より詳細なきちんとした資料を、できればCSVデータなどのより二次利用がしやすい形で出して欲しいと個人的には思っております。

登壇者の発表内容

 今回は私が登壇者の一人ということもあり、他の登壇者の方の発表内容のメモが追いつかなかった部分があります。記述に間違いなどありましたらご指摘ください。速やかに修正させていただきます。

(株)三陽社メディア開発室 田嶋セッション

 最初は私のセッションからでした。
 私の所属する三陽社という会社は、創業が1949年の比較的古い活版印刷系の印刷会社で、学術系や文芸系を中心として比較的伝統的な出版社さんからお仕事をいただいています。その関係で社内に保管されている大量の印刷データの電子書籍化をどうにかしようというのが会社としての電子書籍の取り組みのスタートラインでした。また、クライアントさんからも比較的古い時期にSONYのリブリエ用データ制作の依頼などもあり、そういう経緯を踏まえて2012年にメディア開発室という部署を立ち上げ、電子書籍制作の研究を本格的に始めています。

 2011年あたりに危惧していた点としまして、私の会社の場合、メインの組版ソフトがAdobeのInDesignではなくモリサワのMC-B2であるため、これを起点としてのEPUB3制作はちょっと一般ルートで進みそうにないということがありました。そのため、自社である程度まで進めるしかないと考えていました。そこでまずはMC-B2のデータをInDesignタグテキストに変換してInDesignで読み込める形にし、当時、将来できるであろうと想定していたInDesignからのEPUB3制作ルートに乗れる形を整えました。
 ただ結局、InDesignからの電子化もそう簡単ではないことが徐々に判明し、かなりの部分を自力でワークフロー構築することとなりました。

 電子書籍の形式としては最初はモリサワのMCBookの研究から始めています。これはMC-B2/Indesignのデータを読み込めることが売りのひとつでしたが、結局元データの事前の整備が必要になり、かえって手がかかることから、MC-B2→InDesignでデータを整備→XMLでタグ付けして書き出し→PerlでMCBook用XMLデータに変換、の形でデータの制作フローを整えました。
 MCBookは注や異体字関係の機能が充実しており、また組版も非常にきれいだったためかなり期待をしました。しかし、当初Appleのアプリ型ソリューションだったことから外資相手の契約が必要になり、出版社サイドの会計処理が煩雑だったこと、結局特定メーカーへのロックインになってしまうことなどの問題点もありました。
 このため、結局残念ながら会社的にはビジネスには結び付いていません。

 ただ、このMCBookの制作の際に開発した変換スクリプトをもとにして、JBasic08準拠のEPUB3用にInDesignデータからXHTMLを生成するワークフローを発表したりしまして、EPUB3制作のノウハウに結びつけることはできました。

 緊デジについては受注価格的には会社的に厳しいラインになるのはわかっていたのですが、ノウハウの蓄積を考えると貴重な機会と思えましたので、業務の延長線上にあるリフロー型の制作のみに絞って受注を目指すことにいたしました。当初はEPUB3のみを想定してフロー構築をしていたのですが、XMDFもしくはドットブックでの納品が求められるとの話が3月末にあり、また独自形式のXMLでの納品も必要との話もあったため、InDesignからXMDFにも変換できるようにスクリプトを制作しました。

 2012年の6月には電子書籍の外字問題に関するエントリをブログに書いたのをきっかけにしまして、当時出版デジタル機構の技術アドバイザーだった深沢英次さんにお声がけいただき、InDedignから電子書籍を制作した際に文字化けを起こす文字のレポートを書きました。これは非常に勉強になりました。こちらのレポートは今、出版デジタル機構さんのホームページの「技術部だより」にありますので、興味がある方はぜひご覧いただければと思います。

 8月には緊デジ正規受注会社の発表があり、私の所属する会社は結局正規受注会社には選ばれなかったのですが、もともとお付き合いがあり、紙の書籍の制作をさせていただいていた出版社さまからの「制作会社指定」の形で緊デジ事業に参加することになりました。
 従って私の所属する会社で緊デジで制作したコンテンツの元データはほとんど自社に保存されていたもので、MC-B2のデータや、古いものでは電算写植のデータもありました。後から数点、他社制作データの電子化依頼もいただいたのですが、これもMC-B2のデータがほとんどでした。

 電子書籍の形式としては全てリフロー型のEPUB3なのですが、学術系などの組版の複雑な書籍が中心でしたので、底本に割注が含まれていたり、多数の索引があったりして、それのリンク設定にかなりの時間を取られました(文書内の注リンクは緊デジでは出版社独自仕様拡張の扱いでした)。
 また、もともと付き合いのある出版社さんのコンテンツが中心ということで、正字対応など字形にもかなり細かく対応する必要があるのはわかっていましたので、底本と引き合わせて校正をしたりもしました。そのあたりの厳密な校正はもともと会社的に強い部分なので、ここは社内リソースをかなりアテにすることができました。

 制作上大変だった点として、もとのデータの作り方が制作者によって異なるので、制作時に適宜判断しなければならなかったといったような点が挙げられるのですが、これはおそらく全ての制作会社にとって労力が必要だった部分なのではないかと考えています。
 InDesignに限らずDTPソフトというのは「紙の本」を効率良く制作するために機能拡張を繰り返してきています。紙の書籍の制作というのは結局書籍として完成した状態の見た目が全てで、そこに至る経路はどんな道を辿ってもいいという世界なので、当然制作会社ごとにノウハウも違いますし、人によっても違ってきます。100人オペレータがいれば100通りのやり方があるくらいに考えても良いくらいだと思います。

 もちろんきちんとした印刷会社は社内でミスを減らすためにワークフローを統一しているとは思いますし、私の会社もそれはやっているのですが、例えば緊デジのようにどこで作られたかわからないデータを受け入れて電子書籍にするような話ですと、元データがどう作られているのかをそれぞれ分析し、必要に応じて修正することを考えなければなりません。見かけは同じでもどの機能を使ってそれを実現しているかというのは正直データを開けてみないと分かりません。そうしないと例えば、意図しない箇所で改行がかかり、ビューア上で組版が大きく乱れるなどといったことが起きてしまいます。まずこの元データ整理の部分の自動化はできないと思います。

 また、全般に「紙の本の組版をそのまま再現したい」という出版社サイドの要望が強く、これの対応も大変でした。正確な組版の対応は「ページの概念がない」リフロー型電子書籍ではどこまでいっても限界がありますし、当然できないことや「やらない方がいいこと」も沢山あります。それを出版社さんに説明し納得してもらうために、何故やらない方がいいのかを説明して、代わりの選択肢を箇条書きにして送って選んでもらうなど、かなり神経を使いました。

 校閲用のビューアに関しては、Kobo touchとReadium、Kinoppyを併用する形で制作を進めました。KoboとKinoppyで校閲を行った理由は、この二つのストアは当時すでに出版デジタル機構からのコンテンツ供給が確定していたからです。また、ビューアが当時もうかなり組版的に安定していたという事情ももちろんありました。他にはiBooksなども使っていましたし、社内での読み合わせ校正用としてはMurasakiからプリントアウトし、底本と引き合わせたりもしていました。

 また当時は、それぞれのビューアごとに表示が微妙に異なるといったようなことがあり、あるビューア向けに表現を追い込んでも別のビューアだと崩れてしまうといったようなことがありました。これはWebが辿ってきたのと同じ道だと思います。電書協ガイドはそういうビューア間の「方言」を吸収するために作られた側面があり、電書協や出版デジタル機構が各ビューア開発会社にガイドに沿った形でビューアの改訂を要請し、同時に制作者としてはこの電書協ガイドの仕様に沿ってコンテンツを作ることで近い将来にはほぼ全てのビューアで同じ表示が得られる、というのが緊デジでの電書協ガイド仕様採用の意図だったと思います。
 しかし、ビューア自体の改訂が緊デジの制作期間内に間に合うかと言えばそれは無理なわけで、校正者としてはどうしても目の前の、まだ表示が不完全なビューアの表示に引っ張られます。これはまあ仕方ないことだったかなとは思います。
 今は大分各ビューアの改訂も進んできており、まあ正直当時この状態だったらなと思わなくもないのですが、これはいわゆる「鶏と卵」的な話でもあるので、生みの苦しみ的な部分はやはりくぐる必要はあったのかなと思います。

 スケジュール的には当初は出版関連業における閑散期にあたる夏場に人数を割いての作業を想定していたのですが、結局冬場の繁忙期に完全に重なってしまったことが痛かったように思っています。

 EPUB3制作の流れのおおざっぱなまとめとしては、MC-B2のタグテキストをPerlでInDesignタグテキストに変換し、タグ付けを行ってXMLで書き出し、それをまたPerlで変換してXHTMLにし、自社制作ツールでOPFパッケージングファイル、目次ファイルなど必要なファイルを生成してEPUB3に、というような感じで制作を行っています。
 このあたりの流れについては7月に出展の決まりました電子出版EXPOでも展示を行っておりますので、ご来場の際はぜひお立ち寄りいただければ嬉しく思います。

 今後は印刷物の制作とも連携させたワークフローを整え、会社全体で効率良く電子書籍を作れる体制を整えたいと考えております。

(株)デンショク 営業部課長 石倉章晴さんセッション

 デンショクさんは私が所属していますJAGATの研究会でお世話になっている会社さんなのですが、もともとモトヤの関連会社で、InDesignでデータベース組版の仕組みを構築し医学書を中心とした制作を行われています。また、書籍だけではなく、同じデータベースからiPadや各種タブレット類へのアプリ制作などもされているとのことです。必ずしも一般販売される書籍だけではなく、病院内で医師や看護スタッフが利用するソリューションの提供がかなりの比重を占めるとのことで、こうしたマルチな展開はぜひ見習いたいところです。

 緊デジではドットブックとEPUB3の制作依頼、技術指導の依頼があり、主担当1名ほか、システム開発・タグ付け担当各1名で作業を行ったとのこと。
 元データは電算写植機データからのドットブック制作がかなりの冊数にのぼった他、EPUB3も6点ほど制作されたとのことでした。エディタとしては当初はFUSEeを検討したものの、結局Dreamweaverをメインに使ったとのことです。また、私の作ったスクリプト・アプリ類をかなりご活用いただいたとのことで、これは作成者として嬉しい限りです。

 制作時の問題点として、技術的には「確認したい箇所を底本から探す手間」を挙げておられました。これは大いに頷けるところです。元データがInDesignであればDTPデータをPDFに変換し、検索するなどの方法も考えられますが、もとが電算写植機のデータなどではちょっと方法が思いつきません。

 また、営業面での課題としては、Web制作会社なども電子書籍制作に進出してきていることなどからすでに電子書籍制作の値崩れが始まっており、効率を良くして人件費を落としても利益が出せそうにないことなどを指摘されており、これに対する対策として、「電子書籍技術を含めたビジネスモデルの開発」「会社における電子書籍の位置づけの明確化」「印刷物と電子書籍が効率的に制作できるワークフローの確立」などを挙げておられました。このあたりは大いに参考にしたいです。
 さらに、「非販売系書籍の電子化」も将来的には対象になってくるのではないか、と話されておられ、特定組織内でのみ流通する文書類や、役所などが無料配布する資料などの存在を考えると、確かに決して軽視できない分野であるように思いました。

(有)眺(ティアオ) 代表 野知潤一さんセッション

 九州で電子書籍制作の会社を営まれている野知さんのセッションです。電子雑誌トルタルにも参加されています。今回は私からお願いしてご登壇いただきました。
 電子書籍の制作には2001年から関わっておられ、最初はメディアワークスのライトノベルHPでの立ち読み版制作だったとのこと。縦書き、ルビ対応が必要だったため、当時その技術を持っていたボイジャーのソリューションを採用し、2年間で200冊ほど制作されたとのことでした。
 2003年には九州のシティ情報誌の文芸賞の電子化、2004年から始めた自社文芸サイトの作品をドットブックにして2005年から理想書店で販売、2007年には女性向け官能小説(ケータイ向け)などのお仕事をされていたものの、どれも大きな売り上げには結び付かず、iPhoneの上陸を機に現在の流れに至るとのお話です。

 緊デジでは九州の出版社に積極的に営業をかけたのですが、参加したのは海鳥社だけで当初は50〜70冊というような話だったものの、出版社サイドでの著作者への許認可に時間がかかり、最終的に16タイトルの電子化という話になったのが12月末とのこと。

 データ形式としては旧バージョンのEDICOLORデータがほとんどで、中国や九州の歴史ものが多く、文字コード外の地名・人名がたくさん出てくるもので外字対応に追われた他、ルビの点数がとても多く、大変苦労をされたとのことでした。外字に関しては、当初出版社から要望のあった形式が文字コードがShift_JISのドットブックだったため、文字コードがUTF-8のEPUB3なら外字化しないで対応できるJIS第3・第4水準の漢字まで外字画像化して対応せざるを得なかったとのお話でした。

 さらに画像が350点以上ととても多い本もあったとのことで、画像をコンテンツ内のどこに配置するかにかなり苦心をされたようです。
 現状EPUB3でも画像の回り込みの対応は十分とは言えず、どうしても文章が画像で寸断される箇所が出てしまいます。これは結局文字の拡大縮小ができる「リフローの利便性」「厳密な組版」がぶつかる部分なので、多分将来的にも完全な対応は難しいのではないかと思います。

 全てドットブックのコンテンツを納品したところで制作業務が終わったと思っていたところ、2月28日の時点で「EPUB3も作って欲しいという要望が判明」し、対応に大わらわだったとのこと。ここではドットブックからEPUB3への変換および、UTF-8で外字から外れる文字の非外字化が技術的課題になったようです。
 聞くだに大変なお話で、本当に苦労が忍ばれました。

 野知さんが語っておられたことで特に印象的だったのが、「単純に広く読者を獲得する目的でパブリッシュ(出版)するのなら無料のWebベースの方が、Kindle Direct Publishingのような有償コンテンツ販売よりも向くのではないか」という言葉で、さらに「パッケージで固め、値付けしたとたんに圧倒的に読者が減るのが大きな問題」とも言われていました。今後はブラウザベースでタテ書きでコンテンツを公開できる方向性を考えたいとのこと。

 私も現在のセルフパブリッシング(プチ)ブームがどこまで続くのかは少し疑問には思っており、まずWebベースで無料公開し、一定の人気を集めた後に有償コンテンツ販売に移行するというルートが定着する可能性は十分にあると考えています。

(株)シーティーイー 新規事業推進プロデューサー 鎌田幸雄さんセッション

 シーティーイーの鎌田さんのセッションです。鎌田さんもJAGATの研究会でお世話になっており、今回登壇をお願いしました。シーティーイーさんは43年の歴史を持つDTP制作会社とのことで、鎌田さんはQuarkXpress向けのAppleScriptをかつて積極的に発表され、著書も書かれている方とのこと。私は不勉強で知らなかったのですが、どこかでコードのお世話になっていたかも知れません。

 モリサワのMCBookを中心にし、現在MCBook、EPUB3の同時納品フローを構築しているとのこと。理由として、もともとシーティーイーはDTPの制作会社であり、会社全体としてCSSの知識は浸透していないことを挙げておられました。緊デジは主に価格面での判断で受注は見合わせたとのことで、現在月産50冊程度の電子書籍制作体制を構築しておられるそうです。

 DTPを中心とした制作会社にとってCSSの知識が壁になるのは私も痛感しているところで、緊デジが電書協ガイド仕様を採用した理由も「CSSがあらかじめ規定されているフレームワークだから」という部分が大きかったように思います(担当者が勉強すれば、という声も聞こえてきそうですが、「社内に一人詳しい人がいる」のと、「会社としてほぼ全員に一定レベルの知識が期待出来る」のは大違いです)。
 また、MCBookでのフロー構築は私も検討はしたのですが、鎌田さんのお話によると結局MCBookが電書協ガイド仕様のEPUB3書き出しにきちんと対応できたのは5月あたりだったとのことなので、これは見送って正解だったようです。

 出版社さんとあらかじめ相談して作り方を規定し、異体字はMCBookの機能で対応、現在WordからMCBookへのフローも構築しているとのこと。人員としては管理スタッフは2名ほどに留め、制作自体は単価の安い地方で行っているとのお話でした。
 また、最近は電子と紙の同時発行の依頼が増えているとのことで、今後増えてくるタイトな制作スケジュールに対応するために、DTPも含めたデータ作成のあり方を考えておられるとのことでした。

 とても興味深かったのは、MCBookは結局プロプライエタリ(特定メーカー依存)のツールなため将来的に継続してのコンテンツ制作のベースにするにはコピー&ペーストができないなどの問題点もあり、IDML経由でのコンテンツ制作を考えているとのお言葉です。
 IDMLはInDesignから書き出せる互換ファイル形式の一種で、通常はCS5→CS4など下位バージョンへの互換目的などで使用します。これはZIPパッケージ内にXMLが収められているもので、一応原理的には全ての要素をXMLで書き出すことが可能です。ただし、あまりに複雑すぎるため、私などはこれをハンドリングすることは早々にあきらめ、InDesign内でXMLタグを付加し、書き出して変換する方法を選びました。もしIDMLから変換してEPUBを制作できるのであれば、タグを付加する手間を省くことができ、かなりの省力化が期待出来るのではないかと思われます。

 以上、セミナーのまとめでした。長文にお付き合いいただきありがとうございます。この後質疑応答も行われたのですが、いささか長くなりすぎましたし、私自身が登壇者で詳細なメモは取れていませんので、省略させていただきます。今回会場には深沢さん、沢辺さんをはじめ、緊デジ制作でお世話になった方々もご来場いただき、活発な質問も飛び交いました。これを機会として、リアル、ネットを問わず活発な議論が継続して行われるようであれば、これに勝る喜びはありません。

 ご来場いただいた方々、本当にありがとうございました。

(2013.6.28)

緊デジ(電書協)仕様のリフロー型EPUB3を作ってみる

2012/12/03

 AmazonのKindleストアもついに日本展開を開始し、Google Play Booksもサービス開始するなど、いわゆる「黒船」陣営も軒並み出揃ったことで、ついに本当の意味での「電子書籍元年」が始まった感があります(Apple iBookStoreが未だにロールアウトしないのが気になるところではありますが)。こうした中でpubridgeと紀伊國屋書店、楽天koboとの電子書籍配信・販売合意が発表され、緊デジ事業で制作されたコンテンツの提供先も確定しました。これから先も次々に提供先が増えていくことになるのでしょうか。

 緊デジ仕様のEPUB3は、まだ校正用ビューア等の仕組みが発表されていないため正式には制作開始前の状態ですが、「電書協EPUB3制作ガイド」に準拠するという方針は発表されており、「緊デジ版EPUB3テンプレート」も発表されているため、既に制作自体は可能です。

 ということで、以下は緊デジ仕様のリフロー型EPUB3コンテンツ制作の具体的な流れです。あくまでまだテスト段階ではありますが、ご参照いただければ幸いです。

1 本文用のXHTML/CSSファイルを準備する

本文用のXHTML/CSSファイルを準備

本文用のXHTML/CSSファイルを準備

 本文用のXHTML/CSSファイルを準備します。私は今回、テキスト部分に関しては以前のエントリで発表させていただいたInDesignでXMLのタグ付けをしてXMLを書き出し、Perlで変換する方法でXHTMLファイルを制作しましたが、これは印刷用データからの変換を前提としたワークフローですので、もとがテキストデータであれば初めからDreamWeaverなどweb系のツールを利用したほうが効率は良いかと思います。XHTMLファイルのタグ付けルールは前述の「緊デジ版EPUB3テンプレート」及び準拠している「電書協EPUB3制作ガイド」に従います。

 画像のみで1ページのページに関しては、「kinidigi_reflow_template」内の「p-005.xhtml」(1ページ画像テンプレート)を元に、タイトル、ファイル名、alt(代替名称)を書き換えてファイルを準備します。

 「電書協EPUB3制作ガイド」は基本的に紙書籍の電子化を目的としたガイドラインで、印刷データや.book、XMDFといったレガシーフォーマットからの変換を念頭に置いているものと思われ、全体的に現在もしくは近い将来に各ビューアが実装可能なプロパティだけに絞り込んだ、かなり保守的な仕様です。そのため電子ならではのインタラクティブな表現などはほとんど期待できませんが、その分ビューアの側の表現の揺れなどはそこまで気にしなくても良さそうな印象があります。緊デジ用EPUBに用いるためのXHTMLファイルは、この「電書協EPUB3制作ガイド」に従い、基本的に支給されたCSSファイルの記述を利用する形で制作します。通常書籍で必要とされる表現はほぼ網羅されていますので、書籍(文章もの)のコンテンツであればほぼ事足りるものと思います。自分でclass名を定義する必要はほとんどありません。

見出しid番号を連番で振っておく

見出しid番号を連番で振っておく

 もし、各作品ごとにCSSの追記が必要な場合は、必ず「book-style.css」内の作品別カスタマイズ領域内に記述します。その場合でも電書協ガイド(17ページ)で規定されている「RSによる対応を想定するHTML 要素とCSSプロパティ」の範囲内での記述に留める必要があります。

 本文用のXHTMLファイルは最終的に「p-001.xhtml」「p-002.xhtml」といった形で連番のファイルにリネーム※1し、目次に表示させたい見出しには「id="toc-001"」といった形でユニークな見出し番号を振っておきます。なお、IDの属性番号は1文字目は必ず英文字である必要があります。これはXHTMLを含むXMLの属性名命名規則の縛りです。数字は2文字目以降にしか使用出来ませんので念のため(私は一度やらかしました)。

2 カバー/注意書き/奥付/本扉などのXHTMLファイルを準備する

テンプレートをコピーし、書き換える

テンプレートをコピーし、書き換える

 「緊デジ版EPUB3テンプレート」のファイルをコピーし、書き換える形で、カバー/注意書き/奥付/本扉などのファイルを整えます。

 カバー「p-cover.xhtml」は、タイトル名を書き換え、イメージファイルのalt領域にタイトル名を記述すればOKです。カバーに用いる画像ファイルは「cover.jpg」の名前で準備しておいてください。

 電子化にあたっての注意書き「p-caution.xhtml」は、タイトル名と縦/横の記述を書き換えればOKです。

 奥付は通常、電子化クレジット「p-credit.xhtml」と、底本奥付(テンプレートの「p-006.xhtml」を参照)の2種類が必要です。電子化クレジットは各出版社から支給されるデータをもとに入力することになります。底本奥付は画像を用意し、タイトル名とファイル名の連番(p-xxx.xhtml)、目次用のid番号を書き換えればOKです。底本奥付用の画像ファイルは「original_credit.jpg」の名前で準備しておいてください。

 本扉「p-titlepage.xhtml」も基本的には画像ページでOKですが、出版社からの指定があった場合はテキストで準備することになります。画像の場合はテンプレートの「p-005.xhtml」(1ページ画像テンプレート)を元にファイルを整えます(ファイル名は「p-titlepage.xhtml」にリネーム)。テキストの場合はテンプレートの「p-titlepage.xhtml」を書き換えてください。

 書き換えが必要な箇所は、「電書協EPUB3制作ガイド」(26ページ〜)に色文字で示されています。ご参照ください。

3 作成した各ファイルをEPUB圧縮用のフォルダにまとめる

 「kinidigi_reflow_template」のフォルダをまるごとコピーし、フォルダ名をリネームしてから、作成したXHTMLファイルを「xhtml」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKですが、次のステップで「OPFパッケージファイル生成アプリ(緊デジ用)」を使用する場合は、「p-toc.xhtml」はそのまま残しておいて下さい(名前の抽出用です)。画像ファイルは「image」フォルダに収納します。元から入っているファイル類は捨てるか上書きしてしまってOKです。

4 OPFパッケージドキュメントを準備する

ファイルごとの見開き表現の有無を記述

ファイルごとの見開き表現の有無を記述

 OPFパッケージドキュメントを準備します。OPFパッケージドキュメントは、書誌情報やユニークIDの記述、EPUBパッケージ内に収納する全ファイルの登録、コンテンツの並び順や右綴じ/左綴じの規定、見開き表現の有無などを規定するもので、電書協ガイド/緊デジのテンプレートでは「standard.opf」の名称で規定されています。基本的にこのファイルを書き換えることになります。なお、このファイル名は「META-INF」フォルダ内の「container.xml」に登録されていますので、変更するとEPUBファイルとしてパッケージングができなくなります。

 今回私は、以前のエントリで発表済の「OPFパッケージファイル生成アプリ(緊デジ用)」を使用してOPFパッケージドキュメントを準備しました。image/xhtmlの登録作業や書誌情報やユニークID入力補助を目的としたアプリです。なお、このアプリを利用した場合でも、ファイルごとの見開き表現の有無(spine項目内「properties="page-spread-left"」記述部分)は手動で書き換える必要があります。
 ちなみに緊デジ仕様のEPUBでは、ユニークIDにJP-eコードを用いる部分が電書協ガイドのそれとは異なります。もし上記アプリを用いて緊デジ仕様以外のEPUBを制作する場合は、JP-eコードはuuid等に置き換える必要があります。

5 目次(p-toc.xhtml)ファイルを準備する

目次ファイルを準備する

目次ファイルを準備する

 目次ファイル「p-toc.xhtml」を準備します。なお、ここで言う目次ファイルは本文内にページとして表示される目次ファイルです。リーディングシステム内メニュー表示用の目次ファイルは「navigation-documents.xhtml」ですが、こちらには「表紙」「目次」「電子化クレジット」のみが登録され、緊デジでのEPUB3制作では通常書き換える必要はありません。この「p-toc.xhtml」も「OPFパッケージファイル生成アプリ(緊デジ用)」で自動抽出が可能です。ただし、目次は各書籍ごとに底本の体裁が異なるため、いずれにせよ後から細かな部分の編集は必要と思われます。

 目次のリンクの確認は、ファイルをSafari/Chrome等のブラウザで開くことで行うことができます。目次に限らず体裁の確認は、実際にEPUB圧縮するのと同じ構成のフォルダにXHTMLファイルを収納した上で、ブラウザで行うのが便利です。

6 EPUB圧縮を実行する

epub packagerを用いたepub圧縮

epub packagerを用いたepub圧縮

 OPFファイル、目次ファイルを上書きし、EPUB制作に必要な全てのファイルが整ったところで、EPUB圧縮を実行します。macで作業をしている場合は、フォルダ内の不可視ファイル「.DS Store」を除去する必要がありますので、まず「Ds Store Remover」にEPUB圧縮するフォルダをドラッグ&ドロップし、「.DS Store」を除去します(同種のアプリは複数あるようです)。

 その後、実際にEPUB圧縮を行います。ターミナルでコマンドを打ち込んで圧縮することも出来るのですが、私は普段「epub packager」を利用しています。ドラッグ&ドロップで圧縮できるので便利です。

7 エラーを修正する

epub Checkerでバリデートチェック

epub Checkerでバリデートチェック

 epub内のエラーを修正します。xhtml内idの二重登録、画像ファイル名の記述ミスなど、epub制作には間違いは付き物です。これをチェックし、全てのリーディングシステムできちんと表示されるepubを制作するために、バリデータでepubをチェックする必要があります。

 前出の「epub packager」では、epub作成時にバリデートもしてくれるのですが、実際にどういった部分に問題があったのかまでは表示してくれませんので、「Not Valid」と表示された場合は、バリデータでepubデータをチェックし、エラー部分を修正する必要があります。私は同じ会社から出ているアプリ「epub Checker」に、生成されたepubをドラッグ&ドロップし、バリデート作業を行っています。これはIDPFのepubcheckを内部的に利用したGUIアプリですが、epubcheckに関してはIDPFからCUI版のコマンドラインツールも配布されていますので、Windowsなどの環境でもそちらを利用してバリデート作業を行うことができます。epubcheckのエラーメッセージについては、前エントリ「IDPFのバリデータに叱られてみた」をご参照ください。

 全てのエラーを修正し、バリデータをノーエラーで通過できれば、epubファイルはひとまず完成です。

※1 電書協ガイドでは、ファイル名/id番号共に版元ごとに変更可能な項目として指定されていますが、本エントリではサンプルコンテンツの表記に従って「連番」としています。項目があまりに多数に及ぶ場合など、修正がしやすいような命名法を採用しても特に差し支えはありません

(2012.12.3)

 ファイル名/ID名の命名方式に関してご指摘をいただきましたので、追記いたしました。

(2012.12.10)

プロフィール
Jun Tajima

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

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