EPUB3策定の経緯と電子書籍の基盤技術
JAGAT テキスト&グラフィックス研究会のセミナー「EPUB3策定の経緯と電子書籍の基盤技術」に行ってきました。
今回はなかなか面白かったので、レポートを。
ところで、JAGATの有料セミナーといえば、高い事で有名で、その有料セミナーをレポートすることについて(特にいろいろとうるさいと評判のJAGATさんのセミナーをレポートすることについて)「問題があるんじゃないの(と、いうかJAGATが問題にするんじゃないの)」と心配してくださる方が多いのですが、レポートについては、映像、画像(写真)などがなければ、全く問題ない、むしろどんどんやれと、たまたまお会いしたJAGATの方からもお許し(?)を得ております。ご心配なく。
つーか、JAGATの人に顔も名前も所属もブログもばれてて、ちょっとビビった。皆さん、私がこれまでさんざんJAGATの悪口書いてたのに、そこには触れずにこやかにスルーしてくださる大人だったよ。「DTPエキスパートもってても何の役にもたたない!」とか「セミナー代金、くそたけえ…!」とか言っててごめんな!これからも言うけど!
で、今回のセミナー。
テーマはEPUB3策定の経緯という事で、4人のスピーカーにそれぞれの技術の解説をしてもらい、その後4人でのディスカッションがついてた。面白かったのはその中のCSS3に関する解説をやったセッションと、その後のディスカッション部分。なのでそこを中心にレポート。
それ以外のセッションも面白くなかったわけじゃないのだけど、全部詳しくレポート書くの大変だから簡単にまとめるだけにしとく。
「電子書籍の分岐点とEPUB3」
鎌田 博樹氏
オブジェクトテクノロジー研究所(有) 代表取締役。電子出版のオンラインフォーラム、EBook2.0Forum 主宰。
【内容】
ここ数年の電子書籍市場のまとめ。日本では電子書籍元年と言われながらもなかなか広がりをみせていない。従来の印刷を模す(印刷の再現、デバイス依存の)電子書籍ではなく、新しい形での電子書籍の飛躍を期待している。EPUB3でそれが近づくのではないか。
電子書籍概論的な話だったかな。手違いでスライド資料のデータがなかったりで、なんだか話が途中で切れてしまってよくわからなかった。
「電子書籍時代のユニコード入門」
小林 龍生氏
UTC(Unicode Technical Committee)で、ISO/IEC JTC1/SC2議長などを務め、ISO策定とかをやってる方。
【内容】
ユニコードの基礎知識解説…のはずだけど、がーーーっとおおざっぱに概略の説明。まぁあんまり基礎的な話をいまさら細かく説明するのもめんどくさいんだと思う(笑)
会場内にも、その辺の話はもうしってるよって人が結構いたみたいだし。ほんとに文字コードの話の知識がまったく無い人が聞いたら全然わかんなかっただろうけど…。
とにかく言いたいのは「最新のunicode環境をつかえば、大半の外字問題は解決する」「今、外字問題で騒いでいるのは大半古い環境(ガラケー)などのShiftJISでの問題」「一部古い環境に固執する人はさっさと移行しなさい」って話。
「EPUB3策定の経緯」
村田 真氏
IDPFのEPUB3国際化グループのコーディネーター。EPUB3の日本語対応実現などをやった人。
【内容】
EPUB3の基礎的な解説をちょこっと。EPUB3によって、Web関連の技術と電子書籍で同じ技術、コンテンツが共有できるようになる。
もしEPUB3で日本語縦書き仕様が規格に入らなかったら、今後永遠にWebでも、(EPUBによる)電子書籍でも縦書きは実現できなかった可能性がかなり高い。かつてInternet Explorerで縦書き再現を搭載したが、まっったく普及しなかった。世界標準のブラウザに搭載しても使われないものが、普及するわけがない。
EPUB3での日本語対応について、どのように根回しし、実装させたか。
日本語の仕様を国際規格で通すためには、国内の理論などをそのまま持っていっては失敗する。国債的にいかに役に立つかという方向から根回しして通さなければだめだ。
国際規格で日本の仕様をとおすための実践法などは、小林氏の著作「ユニコード戦記」にも同じような話が載っている。こういった戦略とか戦法って日本人はあまり慣れてないけど、それができないとこういった場でリングにすらたてないんだよなぁ。
で、ここからが最後のセッション。
「CSS3の現状と今後の課題」
スピーカーは石井 宏治氏。
2010年よりW3C CSS WGにおいてCSS TextとWriting Modes仕様のエディターとしてCSSの仕様作成。
石井氏はつまりCSSの仕様を決めるところの人なんだよね。で、ここまでのセッションの中で小林氏と村田氏というのはそれぞれ、Unicodeの規格を決めるところと、EPUBの規格を決めるところの人。
EPUBの仕様というのは、すべてがEPUBだけで決まっているわけじゃなくて、その中で使われている技術はHTML5やCSSというWeb技術やUnicodeの文字技術をそのまま使っている。で、そのWeb技術を定めているのがW3C。文字コードに関する部分はUnicodeの規格をそのまま利用している。
つまりEPUB3は、W3C、Unicode二つの規格を参照して、そこに「電子書籍」のための仕様をくっつけた規格。
今回のJAGATのセミナーは「EPUB3を構成している3つの規格、それぞれの規格制定に携わる人をよんで話をしてもらう」という趣向なわけだ。
石井氏の担当はW3CでCSSの規格の中でもCSS TextとWriting Modesの仕様。EPUB3の日本語組版部分に大きく関わる部分。
CSS3と言っているが、実はCSS3という仕様は存在しない。CSS2.xは大きな規格で仕様策定にものすごく時間がかかったので、その反省もあって、後継となるCSS3では各仕様をモジュールという小さな単位に分割して開発のスピードアップをはかっている。
だから今CSS3と一言で言っているのはCSS3という大きな仕様が一つあるのではなくて、たくさんの仕様が集まった状態の事を言っている。
モジュールはその機能によってレベルが定められている。現在のモジュールはほとんどがレベル3。いくつかのモジュールで今後レベル4が検討されている。
どのモジュールを使うか、どのレベルを使うかは実装による(つまり、CSS3対応であっても、全部のモジュールの機能をのせなくてもいいし、最高レベルのバージョンにしなくてもいいってことか)
CSSのモジュールは現在56個あってW3Cのサイトで一覧を見る事ができる。
モジュールにはその仕様がどの程度まで確定しているかをしめすStatusというのがあって
ED(Editor's Draft これは提案前の下書きみたいなもの)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
WD(草案)
↓
LC(最終草案)
↓
CR(勧告候補)
↓
PR(勧告案)
↓
REC(勧告)
最終段階のRECまでいけば、仕様として安定している(=改編されることが少ない)ということ。
一般的な用語でいえば、ED、WDは開発中でLC、CRがベータ版、RECが製品版という感じ。
それではEPUB3で採用されているCSSはどういったものかというと。
status | ||
---|---|---|
REC | CSS2.1 | |
REC | CSS2.1の一部 | CSS2.1で削除された箇条書き |
WD | CSS3.0 Speechの一部 | |
WD | CSS Fonts Level3の一部 | 外字などの埋め込みフォント |
WD | CSS Text Level3の一部 | 禁則、行揃え、圏点など |
WD | CSS Writing Modes Level3のほぼすべて | 縦書き |
CR | Media Queries | |
REC | CSS Namespaces | |
CR | CSS Multi-Column Layout | 多段組 |
Ruby、displayなどのEPUB独自拡張 |
EPUB3で採用されているCSS、こうやってみるとREC(勧告)まで行っているものは僅かで、ほとんどがWD(草案)のものばかり。つまり仕様としてはまだ安定していないものが多い。
EPUB3で、まだWDである仕様を参照するメリットは、最新の機能を使えるということ。ほとんどの機能がまだWD、開発中でありこれがRECになるまで待つのは時間がかかりすぎる。
もちろんWDであるため今後仕様が改編される可能性があり、それにより新しい仕様で作成されたEPUBと過去バージョンとの互換性に問題がでる可能性がある。こういった問題をできるだけ少なくするため、なるべく早期にWDを安定化する必要がある。
EPUB3の日本語関連仕様群
EPUB3の中で、日本語組版に関連する機能として、CSS Text Level3がある。
プロパティ名 | 内容 | |
---|---|---|
1 | text-transform | 大文字小文字、全角、大仮名変換など |
2 | line-breaak | 禁則。三段階のプリセット値から選択 |
3 | word-break | 欧文泣き別れなど。 |
4 | hyphens | ハイフネーション。一部はL4へ |
5 | text-wrap | 特定部分での改行禁止など |
6 | text-aligin,text-align-last,text-justify | 行揃えと行ツメ。両端揃え、均等揃えなど |
7 | text-indent | 字下げ |
8 | hanging-punctuation | ぶら下げ |
9 | text-decoration | 下線、取り消し線など |
10 | text-emphasis | 圏点。一部はL4へ |
11 | text-shadow | 文字の影付け |
このうち、1.text-transform(文字小文字、全角、大仮名変換など)と、2.line-break(禁則)、6.text-aligin,text-align-last,text-justify(行揃えと行ツメ。両端揃え、均等揃えなど)については一部の機能をLevel3に残すかどうか議論している最中。
つまり実装がちょっと難しいところがあるので、その部分はLevel3ではあきらめて、Level4での実装にしようか議論されてる。L4だと勧告までもっていくまで5年はかかるので、それだけ実装は遅れることになる。
6のtext-aligin,text-align-last,text-justify、これはつまり行揃えの設定なんだけど、どんな言語がきても行揃えができるようにするというのが難しいのでなかなか実装が進まないのだそうな。
石井氏はもともとマイクロソフトでWordの開発をやっていたんだそうで、当然その時行揃えなどの機能もつけていたのだけど、Wordのように使用環境が限定できるものであれば、日本語版、英語版でそれぞれ行揃えのエンジンを別にしてやればよいのだけど、EPUBのようにあらゆる言語環境で使われるものを、どんなブラウザでも行が揃うようにするというのはとても大変なのだそうな。
2の.|line-breakは禁則処理。これは現状では3種のプリセット値から(禁則文字種を)選ぶようにしているのだけど、これをカスタマイズできるようにするかどうか、そこはL4でという話になりつつある。
ここまで説明した所で、セッション2のスピーカー小林 龍生氏が乱入
小林「たとえば最近twitterで小形さんがしきりとやってるんだけど、小書きの仮名の行頭禁則については?あそこまでの実装は必要?」
これはtwitterで小形克宏氏のやってる「拗促音の行頭禁則は一般的なのか?」から始まる一連のツイートについての話。
石井氏の答えは、どこまでの複雑な禁則が必要かというのは結局クライアントの意向によるところなので、プリセットで用意しただけでは印刷組版でやっているレベルまでの要求は満たせないだろうと。
同じくスピーカーの鎌田 博樹氏「たとえば文字に関してはUnicodeではかなり広い範囲で(要望を)汲み取ってるのに、(CSSでは)組版についてかなり機能をしぼっているね」
で、小林氏が「そもそも、リフローするという前提の文字に対して、禁則もなにもないだろうと思うんだよ」と発言し、ここでちょっと議論になりそうだったのだけど、まぁその話はこのあとのディスカッションコーナーでねと終息。
CSS Writing Modes Level3
つづいて、CSS Writing Modes Level3について。
Writing Modesでは、基本書字方向つまり、アラビア語のなどの右から左に書かれる文字、日本、中国、台湾などの縦書き(行が右から左)古代モンゴル語での縦書き(行が左から右)という行がどちらの方向に流れるかを規定している。
また、縦書き時の文字の向き、ボックスモデルといわれる縦書き時や縦横混在時のレイアウトや縦中横なども。
文字の向きについてはUTR #50(Unicode Technical Report)で議論中であり、今後変更される予定。
つまり例えば縦組みの文章の中で、アルファベットが来た時、数字記号が来た時、ギリシャ文字、ローマ数字がきたとき、これらそれぞれに対して、正立するか横転するかを議論している。
難しいのは、文脈によって正立だったり横転だったりという使い分けが生じていること。
たとえばルート記号√は、数式として入ってくる場合は横転して使われる事が多いが、一文字だけだと正立で使う事もある。これは文脈によって変化するので、文字種によって分ける事ができない。
HTML5の規定の内、ルビについていくつか問題が生じている。
<rb>タグはルビの親文字を指定する、昔は必須とされていたが、省略される事が多く、現在あまり使われていない。古いIEで正しく解釈されないことから、HTML WGでは廃止にしたいとしているが、CSS WGではCSS Rubyにおけるボックスモデルで使用し、ルビの親文字に対してスタイルを設定するのに使いたい。
1文字の上下にルビをふるComplex Rubyについて、HTML WGはそんなの誰も使っていないから廃止としたい意向だが、一度削除された機能は復活できないので、まだ使う可能性があると考えるCSS/i18nでは残して欲しいとしている。
こういった細かな問題について、ぜひ現場からの実例をフィードバックして欲しい。
実際の作業でどのように使われて、どのような問題があるかの声が必要。
フィードバック先は
W3C日本語ML: public-html-ig-jp@w3.org
個人宛:kojiishi@gluesoft.co.jp/@kojiishii
石井氏のセッションはここまで。
この後、スピーカー全員でのディスカッションに。進行役は小林氏。
ここから先の話の中で各スピーカーの発言についても書くけど、これはあくまで私がセミナー聞いてメモをとった内容を起こしたもの。
録音したものをかきおこしているわけではないので、正確さには著しく欠けるものですので、ご注意を。
こんな話だったなー程度のもので、まったく同じ会話があったという訳ではありません。
内容に間違いやおかしな発言があるとしたら、私が話を聞き間違えている可能性があります。
まずディスカッションのテーマについて、小林氏より「縦組みについて、外字も含めたWeb Fontのテクノロジーについて、ルビについて、禁則処理について、EPUB電子出版の行く道と商業出版の関係について、どのテーマでやる?」と。
私は全部聞いてみたかったけど、時間的な都合もあり会場の参加者にどのテーマが聞きたいか挙手してもらったところ全体的に多かった「EPUB電子出版の行く道と商業出版の関係について」というテーマから。
小林「では鎌田さんどうぞ」
鎌田(急にふられてちょっと困ってた)「標準化っていうのは80%の要件を満たしていても、残りの20%が不満の声をあげて、その声が大きい。実装と標準化のバランス的な問題かと。組版のルールなんかはマーケットが決めていくものだから、マーケットの声の集約の仕組み、日本の中での声を集めるようなサイトはないのかと」
小林「(規格を決めていると)あれこれ足りないという声はよく聞くんだけど、じゃ、実際何が足りないのと聞くと答えが返ってこないんだよ。なんか足りないという、でも具体的な話にならない」
小林(会場に問いかけ)「ここには電子書籍を実務でやっている人が集まっていると思うんだけど、今日の話を聞いて、EPUB3を使おうと思った?」
(会場の参加者の中から、出版社の人を指名)参加者「現実的に今は.bookを使って電子書籍をやっている。将来的にはブラウザなどでも使えるEPUBがよいと思うが、今日の話を聞く中では、まだちょっと規格が定まってなくて(EPUBを)使うのは厳しいかなと感じた」
村田「結局はデバイスによって挙動が違ってくるものなので、どこまで許容するかの問題」
鎌田「何をつかっても、ある程度の許容は必要。.bookを使っててもそう。Webだってある程度そこそこ同じで見られればよいという許容がある。電子書籍の場合、お金を払ったコンテンツに対してどこまでの品質を提供しなければならないかというのはある」
参加者(会場の参加者の中から、出版社の人を指名)「逆にそこは紙との差別化で、(組版や装丁にこだわる)紙は好事家の人のためという方向性で住み分けをした方がいいような気もしている」
石井「それはある。紙が好き、紙の本が読みたいというニーズはなくならないし、そういう人は紙の本を買えばよい。kindleの組版なんか結構ひどいですよ」
小林「電子出版でどこまで紙のクオリティを引き継がなければならないと思うか?」
鎌田「とりあえず、できる範囲でやって徐々にレベルがあがればよいのでは?ワープロなんかもそうで、昔は横組しかできなかった。それまでの紙の書類は縦が多かったからこれじゃ使えないとか言われたけど、横で使ってるうちに横でもいいという風になった」
小林「ちょっと極端な言い方をすればね(実装に携わっている)石井さんや村田さんには悪いんだけど、今回EPUBで実装された縦組み、あれはそこまでして実装しなければならないものだったのか?縦組みは必要か?あ、これは議論だから極論をいうんだけどね。」
村田「縦組みは必要だと思いますよ」
石井「縦組みの方が、読むスピードが早いという調査結果があるんですよ」(人間の目の筋肉の構造についての調査結果を説明)
小林「じゃ、なんで欧文は縦組みにならないの」(会場、笑い。「まぁ、横組だと目は横についてるからとかいろいろ言うんじゃない?」「理由は後付けだから」など)
小林(会場に向かって)「改めて聞くけど、この中で『縦組みなんかいらない、どうでもよい』って人と『縦組みは絶対、なにがなんでも必要!』って人で挙手してくれる?」
(会場内ほとんどが「縦組みは必要」の意見)
小林「じゃ、縦組みはいらないって手を挙げた人の意見をききましょう」
(いらないに手をあげた)参加者「最近は端末で文章を読むし、自分としては縦でも横でも文章を読むのに関係はないと思うので」
小林「ではいる方は」
(会場内出版社の参加者)参加者「文化の連続性という意味で、縦書きというのは古典から続く文化だと思うので必要では」
鎌田「万葉集とかを、横組でよむのはちょっと違うだろうという気がするね」
小林「でも中国の古典、漢文なんかもう横で読まれてるんだよ」
(この後「草書体の連続文字なんかは縦でないと」といった意見、スピーカー4人のうち小林さん以外は縦組みは必要という意見)
小林「行末揃えとか禁則なんかもね、リフローによるレイアウトの変更、あれを許しているのに禁則は許さないというのはどうかとおもう」
(リフローすることによって、紙面レイアウトがどんどん変わるのに行末が揃ってなければならないとか、禁則がとかいうのはおかしいのではないか、といった意見がひとしきりあり)
村田「EPUBでもページ固定モードが欲しいという要求はすごくある」
小林「それはPDFではだめなの?」
村田「PDFだと遅くて話にならないんだよね。つまりEPUBのように軽くて、ページ固定レイアウトができるものが欲しいと」
村田「日本では漫画の電子出版の方からそういう要望がある」
鎌田「Appleが(iBooksでEPUBに独自の拡張を加えて、固定レイアウトを)やってた、あんなふうな?」
村田「まぁEPUB3も中身はHTML5とかなのでやろうとおもえば(固定レイアウトでも)なんでもできちゃうんですけどね。ただ、互換性とかデータの長寿性とかがあるから共通の仕様は必要だろうということで」
小林「早いPDFがあればいいんじゃないの?」
村田「あれは(構造的に)速くするのは難しいでしょう」
石井「(EPUBとPDFの対立は)FlashとHTML5の戦いと同じなんですよ」
小林「では長い目でみればPDFはなくなる可能性はある?」
村田「IDPFの中で(固定レイアウトを)やってるのは元Adobeの人ばかりだからね(笑)元AdobeがPDFがなくなる方向の動きをやってる」
小林「Webフォントの話をやりましょうか、石井さん解説して」
石井「まぁ、つまりWebなんかでFontを表示させるのにサーバーからFontもダウンロードして表示させようって話ですね」
村田「EPUBの中ではWebフォントというのは使えないんですよ。現在同梱のフォントしか使えない。使えるようにして欲しいという要望はあるけど」
小林「EPUBがあまり変更されないものという前提だとWebフォントは使わないね(長寿性を考えるとWebから落とすというのは…という話)」
村田「EPUBではコンテンツはできるだけ埋め込んでおきたい。でもそうは言いつつも映像や音声なんかは(容量が大きくなってしまうので)埋め込まないのですけど」
(会場の参加者から「Webフォントは日本語ではメーカーが許可しないのでは」「いやモリサワは金さえ払えばやる」といった声)
小林「行政なんかで必要な文字だけをサーバから一文字ずつダウンロードするというのはあるんだよね、Googleの○○○みたいなのが(ここら、聞き取れず書き取れず)」
と、かなり面白いディスカッションだったのだけど、このあたりで時間がきてお開き。
小林氏は司会進行役ということもあって、議論を引き出す為に結構過激な言い方をしてたかな。
ただ「禁則や行末処理なんかいらないだろう」というのは、ある程度ご自身の本音でもあるのでしょう(まるっきりなくせという話ではなく、リフローされるようなものに対して、そこまで細かい要求をするなという話だと思うけど)
私個人の意見を言えば、縦組みや禁則といったものが必要かという話に対しては、それは日本語の文化であるので必要だろうと。
そこで、EPUBの中にそれが必要か?という議論になるなら、では逆にEPUBの中にそれが必要ないというなら、EPUBというフォーマットは日本語の文化を残すという主旨には向いていないものということになるのだと思う。
つまり、単純にテキストの中身、内容を残したいというだけの話ならEPUBでよいけど、縦書き、禁則といった日本語文化を含めた形で保存したい時に他のフォーマット(それこそPDFとかね)を選ぶ事になるんだという事。
でもEPUBがいまどういう分野で使われようとしてるかといったらそれは電子書籍とかなわけで、そこで「テキストの内容さえあってればいいだろう」というのは通らないだろうと思う。なのでできる限りEPUBでの組版再現は必要かと。
EPUB3に関しては日本語組版対応、縦書きに対応しました!という話はよく聞くが、実際にその内容を聞いてみると、かなり未確定部分が多いよう。
デバイス、ビューワーの実装も考えると、まだまだ安定して使えるという状態ではなさそう。
中身はHTML5だから、やろうと思えばなんでもできるというのはそうなんだけど、あまりそこをカスタマイズしすぎると、他機種多環境での互換性や将来の互換性が失われる。 EPUBでの日本語表示に対しては標準機能では「ちゃんと表示できてなくても仕方ない」というある程度の割り切りが必要かな。
EPUBがもっと使われて、問題点がクリアになればそれは将来のレベルで対応されるかもしれないし、たとえば禁則処理にしたってどの程度の処理が本当に必要なのかといった議論はとにかく現状のものを使って貰わなければできない。
使う前から「あれができない、これができない」と文句をいってばかりで使わないのでは、この先よくなる可能性もないってことなんだよね。