overprint

印刷とそれ以上の何かについて(少し電子書籍寄り)。気が向いただけでは更新されません。

EPUB3策定の経緯と電子書籍の今後

2011年11月28日のJAGATテキスト&グラフィック研究会ミーティング「EPUB3策定の経緯と電子書籍の今後」は電子書籍ユニコード、EPUB3、CSSのすごい人たちが一堂に会して、4時間があっという間でした。報告というほどのものはできませんが、資料とメモをもとに書いてみます。

鎌田博樹 氏:電子書籍の分岐点とEPUB3

まずはEBook2.0Forumの鎌田氏から。

2011年に起きたこと
  • 英米:デジタル比率が30%へ→デジタルが主、印刷が従
  • 日本:GALAPAGOSの撤退→よい判断
  • アップル In-App Perchase改訂→HTML5への移行
    • Financial TimesのHTML5アプリ化
  • Kindleの新フォーマット
Web出版環境
  • Web内で出版→流通が完結
  • ユーザ主導…誰が読みたいか→マーケティングが重要になる
  • ショートコンテンツの流行
    • これまでは短編1本で出版するのは難しかったが、電子書籍なら可能
    • 安価に販売される
    • ISBN管理が破綻する?
  • 印刷、製本サービスはオンデマンドへ
    • 海外では印刷会社や取次がやっている事例も

参考:Web出版環境とは何か:DD研参加記(3)

WebコンテンツとしてのE-Book
  • デバイス依存→非依存、クラウド化
  • 印刷本の再現を目指すだけではない
情報・知識のコミュニケーション
  • 複雑になる(重くなる)と共有しづらい
  • マスに届けるためには軽くする必要がある
  • Web出版はメディアとしては「広いが薄い」
  • メディア統合→標準化が必要
出版プラットフォームとしてのEPUB3
  • 従来の書籍を超えたEBookが可能…DAISYなど
  • (日本語仕様が含まれたことで)日本も最終列車に乗り遅れずにすんだ
  • 拡張EBook(EBook2.0)へ

製本技術のクオリティ向上がサービスの鍵になるのでは?


小林龍生 氏:電子書籍時代のユニコード入門

続いて小林龍生氏による文字コードのお話。こちらに関しては私の勉強不足もあり、不正確な情報を記載するのもためらわれるので、少し薄くなってしまいます。

まずは結論
  • 最新のユニコード規格に対応したシステム、フォントを使えばほぼ問題ない
  • 古い環境で問題が起きる可能性がある
文字コードとは

文字に番号をつけること→どのように文字を区別するかが問題

ユニコードとは
coded characterとgryph
  • griph:抽象的な文字の形
  • 具体的な文字の形はgriph imageと呼ばれる→手書き文字は書くたびにgriph imageが異なる

1998年「文字コード問題を考える」で表示されないと言われた文字→今では表示可能

外字問題
  • 外字…符号化されていないもの
  • 異体字…音と義は同じでも形が違う文字
何と何を区別するか
  • 符合位置が異なる…78JISと83JISで入れ替わっているものに注意
  • JIS2004問題…IVSで区別
  • JISとUnicodeで区別の基準が異なる…包摂基準とUnificationRule
  • 互換漢字…使い分けの場合は注意→変わったかどうか気づかない可能性も

出版社の人は「IVS使える?」って印刷会社に質問すると通っぽい→まず「使えない」って答えられるけど

質疑応答

Q:文字は増える方向?
A:グリフの差にこだわるのは収束している。社会的コストとのバランス


氏の書かれた「ユニコード戦記」は読んでいたのですが、国際会議の舞台裏などのドラマがおもしろくて、ユニコードの技術的な部分を流していたのでもう一度見直そうかと思います。

ユニコード戦記 ─文字符号の国際標準化バトル

ユニコード戦記 ─文字符号の国際標準化バトル

村田真 氏:EPUB3策定の経緯

EPUB3の概要
  • 無償で利用可能
  • IPDF(International Digital Publishing Form)で制定
  • 北米中心だが最近はアジアなども増えている
  • シアトル以外の世界中で盛り上がっている→シアトルにはAmazonがある
他のフォーマット
  • 欧米ではPDF,amazonくらいしかない
  • 日本は他のフォーマット(XMDF,.bookなど)が有力
EPUB3の基本原理
デモンストレーション(EPUB3文書)
なぜHTML5を採用したのか
  • 流行っているから
  • 構造を表すタグを使用できる
  • APIを使っていろいろできる→複雑にすると長期利用、相互運用性、アクセシビリティに影響する
CSS3
  • いろんな仕様を参照している
  • WorkingDraftレベルも
デモンストレーション(表示システム)
Media Overlay
縦書き導入の歴史
  • 今回導入に失敗したら二度と採用されなかったのではないか
国際の場で通すために
  • 肩書きに関係なく、個人の信用が大事
  • 日本だけの主張をしない→他の要望のなかのひとつとしての日本語の要求

石井宏治 氏:CSS3の現状と今後の課題

最後はCSS仕様策定にかかわる石井宏治氏によるCSSのお話。

EPUB3とはWeb技術の融合

→同じ技術、ツール、コンテンツが使える

IDPF、W3CUnicodeの関係

仕様の参照関係…EPUB3はW3Cの仕様を、W3CUnicodeを参照している

CSS3とは
  • モジュール…項目に分けて開発。現在56個(一覧)。ステータスで安定度を確認
  • レベル…各モジュールごとに設定

→実装によって対応が異なる

EPUB3 CSS Profile

EPUB3で使えるCSSの定義
参考:http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-profile

WorkingDraftを参照する意味
  • メリット:最新機能が使える。国際化機能の多くを取り入れようとすると現状はWDを使わざるを得ない
  • デメリット:仕様変更の可能性→挙動など互換性に問題が起きるかもしれない
  • VersioningStrategy…参照する仕様のバージョンを固定する
    • WebとEPUBで採用仕様がずれる可能性
    • 互換性リスク
  • 仕様策定をできるだけ早く
日本語関連仕様
  • CSS Text Level3…決まらないものはLevel4に送って、仕様を決めるか?
    • 禁則処理…3段階プリセット→Level4で個別指定?
    • どんな言語にも対応させるような仕様を実装させるのは難しい
  • CSS Writing Modes Level3
    • 縦書き時の文字の向き…OSやアプリケーションに依存している現状を解決する→仕様改変予定
    • ボックスモデル…レイアウト規定方法→縦横混在時はまだ不安定
    • 縦中横
  • 文字の向き→Unicodeで定める
  • ルビ…HTML5 Ruby
    • <rb>…親文字指定を廃止にするか省略可能にするか
    • ComplexRuby

ディスカッション

最後に4名によるディスカッション。「縦組みに関して」「Webフォントによる外字処理」「ルビ」「禁則処理」「電子出版、商業出版の未来」を軸に参加者も交えて議論がおこなわれました。その発言の内容のみをメモを元にピックアップしてみます。

  • 標準化の話題では80%のニーズを満たしていても、残り20%の不満を訴える声が強い
  • 「〜が足りない」「〜がダメだ」という人は多いが、具体的に「じゃあ何?」というと答えが返ってこない
  • マーケットの要望の声を集約していくものはないのか?
  • EPUB3は完成度の高いものを期待していたが、まだ仕様確定していない部分もあり(CSSがWD状態など)まだまだという印象
  • 完成度が高すぎない方が印刷本の残る道がある
  • 電子出版でどこまで紙の印刷品質を再現させる必要があるのか(会場アンケートでは完全再現を目指すべきというひとはいなかった)
関係者の尽力によりEPUB3に縦組みが入ったが、そうまでしていれなきゃいけないものなのか?
  • (会場アンケート:別に縦組みなんてどうでも良いと思う人→数名)
  • 普段ヨコ組みしか読まないので、さほどこだわりはない。
  • 和歌など縦組みを前提した文書もある
  • 紙の時代を超えた書き方もあるのではないか
リフローを許しておいて禁則処理にこだわるのはおかしいのでは?
EPUB固定レイアウト
  • 仕様策定上の要求が強い
  • PDFでは動作が遅くて使い物にならない→EPUBに期待されている
Webフォントの話
  • 現状のEPUB3ではダウンロード方式は認めていない→将来性を考えるとEPUBではパッケージに同梱という方向性
  • 日本語フォントは同梱は厳しいのではないか
  • 必要な文字をサブセットして同梱するのは可能では?→現在仕様策定中
EPUB3は仕様上なんでもできる
  • 印刷物の延長で考えていると大切な部分を見落とす可能性もある