本記事は、アーカイブに保存されている過去の記事です。最新の情報は、公益社団法人日本印刷技術協会(JAGAT)サイトをご確認ください。
国際大学 フェロー
村田 真 氏
EPUBはHTMLやCSなど最新のWeb技術にもとづく、誰にでも無償で利用可能な電子書籍フォーマットである。今までのフォーマットは、使うと誰かにお金を払わなければいけなかったが、これはそういうことはない。
制定しているのはIDPF(International Digital Publishing Forum)という団体で、そこには約360のメンバーが入っている。アジアが40ちょっと、アメリカがかなり多く、ヨーロッパやインドも入っている。北米中心の団体だったが、最近はだいぶ他の地域でも増えている。
シアトルを除く世界中で盛り上がっている。AppleもソニーもGoogleもKobo(Koboというのはbookを入れ替えた名前の、最近楽天が買ったところである)もバーンズ&ノーブルも盛り上がっている。
なぜシアトルかというと、シアトルにAmazonがあるからである。Amazonは、出版社からのEPUBファイルは受け付けるが、大手出版社はAmazonのフォーマットを使うのを拒否してEPUBで提供している。そして、EPUB3という最新のバージョンが2010年10月に完成している。(図1)
▲図1
他の電子書籍フォーマットについてだが、欧米は以前は多くのフォーマットが乱立していた。Eバベルの塔と言われた。マイクロソフトやアップルも、もともとは電子書籍をやっていた。アップルは今でもやっているが、マイクロソフトは以前は盛大にやっていた。それで世界征服しようとしたが、マイクロソフトの電子書籍は完全に失敗して、撤退した。
マイクロソフトもアップルも独自フォーマットを作ったが、全部壊滅している。残ったのはPDFとAmazonのフォーマットだけである。PDFは形式的にはISOの規格だが実質的にAdobeの規格である。Amazonのものは独自である。完全独自で残っているのはAmazonくらいだが、Amazonがどこまで独自なのかは、なかなか悩ましい。
日本と中国だけは別のフォーマットが残っている。XMDF、ドットブック、中国ならCEBXがある。理由としては、少し前まで縦書きがEPUBではできなかったからである。
現在日本1ヵ国で作ろうとしているIEC規格、電子書籍交換フォーマットがあるが、これはアクセシビリティに問題があり、日本語と欧米言語しか扱えない。つまり、中東や台湾等では扱えず、Webとの親和性が乏しい。
そういう意味で、XMDFやドットブックは使われ続けるだろうが、中間フォーマットがEPUBと競合したりEPUBより普及するとは、全く考えていない。(図2)
▲図2
EPUB3の基本的な原理についてだが、EPUBの原理とは、私の意見である。まず、Webの世界と電子書籍の世界の相乗効果で、Webの世界は、やはりみんなが使っている。それと、電子書籍の世界が、どちらも同じ技術でつながることによって、コンテンツが相互に利用できるし、技術も利用できるし、ノウハウも相互に利用できる。現時点でたしかにWebのレイアウトは貧困だが、それはいくらでも上がっていくだろう。
世界中の言語と文化の支援についてだが、一応の成果は得たと思っている。
3番目がアクセシビリティである。例えば目が見えない、漢字が読めない、もしくは、全部見えるが手でページをめくれない、大きい文字でないと見えない、縦書きだと読めないが横書きだと読めるなどいろいろある。EPUBは、そういう人のためのアクセシビリティを非常に考慮してできている。
もともとはEPUB3の前のEPUB2が、中で2つに分かれていて、実質的には2つのフォーマットだった。アクセシブルなDAISYというフォーマットがあって、それはアクセシビリティという意味ではいいが、普通の人はほとんど使わない。もう1つは、アクセシブルではないが、みんなが使っているEPUB2本体である。その2つが、実は分離していた。EPUB3では、それらが統合された。その3つがEPUBの基本的な原則だと思う(図3)。
▲図3
EPUBの中身だが、基本的な要素としてはWebの技術である。HTML5、CSS、SVG、ビデオイメージがある。イメージもJPEGなどいろいろある。それにJavascriptがプログラミング言語的なものとして加わって、さらに少しWebらしくなくなってくるが、テキストからスピーチ(テキスト読み上げ)、それからSMIL、テキスト音声の同期、こういうものが構成要素であって、これを本の形にまとめ上げる。
例えばカバーシートが付き、スパイという背表紙の中に、どのHTML5から先頭で、このHTMLが先頭で、次がこのHTMLで、その次がこのHTMLで、その次はこのSVGなどのような順番付けをする。あとは、目次や索引だが、これを付けると、大分本らしくなる。
今のままだと複数のファイルなので、それでは配布しにくい。そこで1つのZIPにまとめる。その後でメタデータ、これは作者が誰で、言語は何で書かれていて、タイトルは何などの情報を付け加える。最後に、必要だったら暗号化と署名をして、これでEPUB3の出版物ができ上がる。
EPUB3でできた文書の例である。表紙があり、先頭タイトルがあり、目次がある。目次をクリックしてみる。「花咲くマルチメディア時代」とある。
ちなみに、このツールはつい最近出たフューズネットワークという会社のツールである。このツールは今ベータ版で、ただでダウンロードできる。ファイルの中身は、ZIPの中身だが、イメージがあったり、HTMLがあったりする。
ナビゲーションは目次だが、これもHTMLである。第3章もやはりHTMLである。正確に言うと、XML構文のHTML5になっている。この辺は、参照されているJPEGである。あとはスタイルシートがあり、フォントや行間を指定している。
順番に並べていて、最初にオーナー、その次にタイトルページがあり、そのようなコンテンツを順番どおりに並べている。これが1つのEPUB出版物の例である。
もう1つ別のものだが、「剣道先生」というもので、なかなかおもしろい内容である。横書きになっていて、たくさんHTMLがあり、JPEGもあり、先ほどと構成はほとんど同じである。
次に縦書きで、「草枕」の最初だが、カバーがあり、目次があり、一番有名なところがある。このクオリティは、WebKitの最新の近いバージョンだが、印刷のプロから見たらまだまだだろう。
このように、EPUB3ではHTML5を使っている。理由の1つはHTML5が流行っているからである。今やバズワードなので、HTML5を使わないと格好が悪い。
また、HTML5では構造を表すタグを導入している。それは<section>、<article>、<header>、<footer>、<figure>、<figcaption>で、これらは今までのHTMLにはなかったが、HTML5にはある。きちんとした本を作ろうとしたとき、<figure>や<figcaption>があるのは、明らかに便利である。セクションの入れ子構造もそうである。
これは静的なHTMLの書き方だが、HTML5は対話的なAPIがたくさんあり、すごいことができる。例えば「アングリーバード」のゲームもHTML5でできるし、何でもできる。EPUBではそれを採用しているので、実はHTML5のAPIがみんな使える。
細かいことを言うと、これがHTML5にある対話的な機構である。ビデオや音声、canvas、拡張されたForms、Application Cache、現在の位置を表すAPIのGeolocation、あとはWebGL、WebSocket、Drag and Drop、とにかくいろいろなAPIがある。
もちろんJavascriptは従来どおり使えるし、APIが全部使える。それから、プログラミングしなくてもCSSだ
けでもアニメーションができる。もちろんJavascriptからDOMがいじれる。
しかし、こういう機能をたくさん使ったときに、本当に安定して長期に動くのか。ビューアが違ったときに、同じように本当に動くのか。相互運用性はあるのか。アクセシビリティは担保できるのか。つまり、目が見える人はいいが、そうではない人にとっては全く読めないコンテンツになるのではないか。こういう心配は多分にある。
大体、Javascript関係は、ブラウザが違えばすぐ動かなくなるし、ブラウザが少し新しくなるとすぐ動かなくなる。EPUBで使えるからといって、こういうものを使うと、同じような問題は当然起こる。
そういう意味で、使えはするが、すぐ使われるようにならないかもしれない閲覧環境を限定できる場合など、例えば学校教育に使われるだろう。(図4)(図5)
▲図4
▲図5
EPUB3ではCSSのいろいろなモジュールを使っている。
まずCSS2.1だが、これはもう勧告になっている。その他にCSS2.0やCSS Writing Modesのワーキングドラフトから少し持ってきたり、CSS Text Level 3のワーキングドラフトやフォントから少し持ってきたりしている。しかも、ワーキングドラフトレベルのものを持ってきている。
それで安定して動くのか、また今後動作が変わったり、構文が変わってエラーにならないのかについてだが、結論を言うと、EPUBで構文を固定したので、構文エラーにはならない。ただ、動作が微妙に変わることはありえる。
例えば縦書きにしたとき、縦書きの中でギリシャ文字が入ったとき、横に寝るのか、縦に立つのか、そういう動作が、ビューアのバージョンが変わると変わってしまうことはありえる。
「草枕」のデモだが、ブラウザベースで動くEPUB Reader、BiB.liophileがある。日本から出たものだが、Google Chromeの上で動くサイトで、EPUBをWebサーバ側にアップロードすると、読めるものが入っている。同じ「草枕」だが、読めるものが返ってくる。先ほどはスクロールだったが、これはページ単位の切り替えになっている。
もう1つ、台湾のトリプルアイが出したものだが、これもGoogle ChromeベースのEPUBビューアである。EPUB文書をWebサーバ側にアップロードするようになっていて、ファイルを選択してアップロードすると読める。例えばクロニクルをやってみると、サーバ側に「JEPA chronicle」がアップロードされていて、「閲覧電子書」を選択すると表示ができる。
「草枕」の縦書きだが、どちらもサーバ側にEPUB文書をアップロードするので、十分グーグルクロームで閲覧できる。
Firefoxでも同じものはあるが、それはローカル側で動く。ただし、縦書きをサポートしていない。今、ブラウザベースでEPUBのビューイングをすると、みんなアップロードしてしまう。
当然、フォントの大きさも変えられる。やはり行の下はいまひとつである。しかし、ルビは結構まじめにやっている。行末の問題を除いては、一応まともな表示はしている。
以前アドビの人と話したときに、「日本人は大変こだわる。アメリカ人などはハイフネーションもろくにしないようなテキストでも許しているが、日本人は大変レイアウトにこだわって、ちょっとやそっとでは許してくれない」と言っていた。
Media Overlayとは、テキストと音声の同期である。これもクロームである。これは子どもなどには、漢字が必ずしも読めないときに、大変いい。それ以外に、いろいろな障害を抱えている方にとって、これは大変便利な機能のようだ。
SVGの中にたくさんテキスト要素がある。その1個1個のテキスト要素に対して座標位置を示している。
さらによく見ると、1個1個の文字にIDが振ってある。このIDを利用して、ここでは音声ファイルの何秒目から何秒目までというのを全部書いてある。
小林氏:ソースは読み上げる順番なのか。
村田氏:順番でなくてもいい。技術的にはできるが、順番のほうがいいだろう。技術的には、どう並べてもMedia Overlayは動く。これはEPUBではなくて、EPUBの中で使えるHTML5とSMILとCSSを単にWebブラウザ上で表示しているだけである。これがiBookとかiPhoneの上で動くはずである。
非常にマニアックな例だが、この技術が他に使い道がないかというと、そんなことはない。例えば地図などに使うと大変おもしろい。地図のいろいろなところのテキストにMedia Overlayをかけて、右側の画面からクリックできるようにすれば、地名を読み上げてくれるような地図が誕生する。
EPUBは他のものとどんな関係があるか。図6で今お話ししているのが一番上にあるEPUBである。これをIDPFがやっている。一番下に踏みつけられているのがUnicodeである。この上にCSSとかXMLとかHTML5が乗っている。その上にRELAX NGというスキーマ言語があり、そういうものをEPUBは使っている。
このCSSに関わっているのが、Elikaであり、石井さんであり、村上さんである。EPUBの縦書きとか禁則処理は、全部CSS次第である。(図6)
▲図6
EPUB3で縦書き導入の歴史だが、まず、1993年の日本語組版規則(JIS x 4051)がある。それがバージョン2になり、バージョン3から小林先生がやっている。
「日本語組版処理の要件」という、小林さんがリーダーのタスクフォースでできたものがあり、W3Cのテクニカルレポートになっている。これは英文がメインで、日本語は一応自由になっている。中身は同じはずである。日本語を全く知らない人が見ても意味が通じる解説本である。
これをもとに、2010年の4月に日本語要求仕様案を作った。EPUBに対してここまではやってくれということである。その後すぐソウルで非公式に、中国、日本、韓国のエキスパートが集まって会議をし、そのときにEPUBでこういうことを対応しよう、だから文句を言わないで協力して欲しいということを少し言ってきた。
その後、6月にニューヨークでEPUBワーキンググループの第1回会議があった。このときにEnhanced Global Language Supportサブグループができて、私がコーディネータになった。私はスカイプで入って、私のいない時点でこういうグループは作らないことになっていたが、私が入って「作る」になり、コーディネータのポジションを取った。
その後、2010年8月に札幌会議があり、この時点で要求書を固めた。小林さんと私である。このとき、台湾から非常に多く参加した。韓国も2~3人参加した。その後、台北会議があるが、その前にElikaさんが日本に1ヵ月滞在して、延々と意見調整をしていた。
その成果をもってEGLS台北会議に参加し、これらができるようにやって、みんなが承認した。その結果をもって、EPUBワーキンググループの第2回の会議に行き、サブグループの結論なので少しは修正があるが、大体そのまま通った。
2011年の1月に、実際のCSSのどのプロパティを使うか、その詳細を決めた。そのときは石井さんも参加された。2月に一般公開ドラフトができ、あとは精度を高めてEPUB3は完成した。
総務省のほうでは、三省合同の懇談会が2010年にあって、最初EPUBは予算がもらえそうもなかったが、11月になる頃、やっと予算が付いた。もう大体一番苦しい時期が終わった頃に予算が付いた。
その他、総務省のほうで、CSSの縦書きという予算が別に付いている。一応、建前ではEPUBとCSS縦書きは別ものになっている。世間的には、この事業がEPUBの日本語仕様策定に貢献したことになっている。
私がコーディネータになれたのは、いろいろな理由があるが、まず1つは韓国や台湾、中国に一生懸命根回しをした。会ったことはなかったが、台湾に一番根回しをした。一番縦書きに関して熱心なのは日本と台湾である。その次は香港で、韓国や中国は、あれば使うが、なくても別にいいという感じである。
それから、私はXML制定当初から仕様に関わっていて、特に私が制定に非常に深く関わったスキーマ言語のRELAX NGとNVDLの2つはどちらもEPUBが使っている。議長のMarkus Gyllingは非常に私の仕事を評価してくれていた。2010年の5月か6月頃、私がスウェーデンに行き、たまたま彼と会う機会があった。そのときに中国と韓国の代表も引き連れて会った。Markus Gyllingからすると、私に頼んでおけばこの辺にも話が通じるのだろうと思ったのだろう。
また、小林先生がまとめた日本語組版の要件が大変よくできていて、評価されている。縦書きについての記述は台湾からも高く評価されていて、大体これでいいことになっていた。それが大きい。
EPUB3のタイミングで縦書きができた。もしできなかったらどうなっていたか。先ほど鎌田さんは3年くらい遅れるのではないかと言ったが、私は未来永劫、絶対できなかったと思う。
なぜかというと、Internet Explorerで実装したけれども普及しなかったからである。シェアナンバーワンのブラウザが実装してさえ普及しないのに、どんなタイミングで普及するのか。電子書籍の導入のタイミングにいつあうのか。
技術や標準化はタイミングなので、タイミングを逃すともうだめである。私は、3年後ではなくて、今回失敗したらWebの上では戦いで死んだと思うし、電子書籍の縦書きもいずれなくなったと思っている。最後のチャンスを捉えてやっと間に合ったと、思っている。
実際、この縦書きは、普及すると思う。Webkitの上で実装が進むとChromeとサファリで実装されるし、電子書籍でみんな使うだろう。例えばソニーの電子書籍リーダーもEPUB3は当然サポートする。(図7)
▲図7
次に駄目な発想についてである。日本人はこう考える人が多いので、だめになる。国内で日本語組版に関する有識者を集めて議論し、得られた結果を国際で通す。これはだめである。
国際でどういうふうに反応されるかというと、「なぜ日本で勝手に決めるのか。国際の場でしろ。縦書きは香港にも台湾にもあるし、内モンゴルにもあるじゃないか。右開きは中東にもあるし、ルビは台湾にも中国にもある。なんで日本で勝手に決めるのか」。当然、こういう反応が来る。
さらに、国際に出ていく人も酷い目に会う。まず、国内で実に細かい議論をやって消耗し尽くす。そして国際に出ていくと、今まで考えていなかったような新しい要求が出てきて、仕切り直しになる。それなのに短時間で勝負をつけなくてはいけない。国内合意と違うことをするので、国内に帰ってきて立場がない。こういうことになる。
したがって、一番いいのは、国内でコンセンサスを得ようとしないことである。国内では情報交換だけでたくさんである。
国際の中で勝つためにはどうしたらいいか。香港や台湾はもちろんのこと、中東の要求まで全部含めて対応しよう。その一環として、日本語にも対応しよう。それから、ベテランエキスパートの国際的な人脈が非常に大事である。
日本の会社名とか組織名、肩書きは何の意味もない。日本の会社の実装で、世界中で普及しているものなど、ないのだから、日本のどんな大会社の名前を言っても、「ふーん」でお終いである。
せいぜいソニーくらいだろう。しかし、ソニーのEPUB Readerも、アドビがレンダリングエンジンを作っているからちょっと弱い。
そして、国内では情報交換だけがいい。「日本独自のものは一切ない」、そう言わないとだめである。「単にこれは国際化のためにやっているのであって、日本もたまたまメリットがあるだけだ」、むしろそういうスタンスで、実際にはたとえ日本にしかメリットがない場合であっても、そう言うべきである。
こういう発想で行くと、国内の人からどう見えるかというと、「日本のことばっかりを考えてくれないし、日本の中の肩書きとか所属組織とか、そういうものに注意を払ってくれないし、国内のコンセンサスを無視する」。実質的には英語で議論できない人を排除するとそうなるが、残念ながら仕方がない。そして、日の丸を立てないので役所からも嫌われる。だから私は日本で嫌われる。
前回発表のときには、「だから私は嫌われる」と書いたが、それだと国際的に嫌われると思われてしまう。嫌われるのは日本でだけである。スキーマ言語の文脈では違うが、EPUBの文脈ではそうである。
これは石井さんと木田さんがやっているが、箇条書きの番号生成にどうやって漢数字やイロハを入れたか。これはCSS2.1になかった。それで、負けるやり方は何か。「2.1にはこういうものがない。日本では困る。だから入れてくれ」。これが負ける発想である。予想される反応はこうである。「なんでCSSにないの?そっちで頑張ったら?日本だけの都合でそんなことはできない」と言われる。
木田さんや石井さんが実際にやったことは、こうである。
「幾つかの番号生成方式、ユダヤや漢数字などそういうものはCSS2.0にあり、EPUB2にもあった。しかし残念ながらCSS2.1のスコープが決まるときに、実装がないものはみんな落とされてしまった。でも、今は実装がある。国際的な要求を満たすため、またEPUB2.0との互換性のために入れるべきだ。」
そうしたら一瞬で通った。上のロジックでいくと、もめる可能性は高い。ユダヤのは1つだけだが、それが入っていると入っていないでは、全然違う。
最後に嬉しかったのは、台湾の人に感謝してもらえたことである。先日台湾に行く機会があって、旧交を温め合いつつ、非常に感謝もしてもらえて、大変嬉しかった。
その後、ソウルにも行ったが、ソウルでは、ソウルCJK会議のとき、日本語組版の要件の話がたくさん議論されて、韓国でもそういうものを作ろうという話が出た。やらないだろうと思っていたが、実はやっていた。今まで全然わからなかったが、この前行ってみたら本当にやっていたので、それも大変嬉しかった。
(図8)(図9) (図10)(図11)(図12) (図13)(図14)(図15)
▲図8
▲図9
▲図10
▲図11
▲図12
▲図13
▲図14
▲図15
鎌田氏:縦組出版をやっているアジアのマーケットは潜在的にあるのか。
村田氏:台湾はかなり電子書籍はやる気である。香港もそうだ。ただ、実際問題としては普及していないという話である。
台湾は今までずっとデバイスというかハードウェアだけやっていたが、それらはこれから中国本土に全部取られてしまう。そういう意味で、これからはソフトだ。電子書籍は是非台湾でコンテンツ作成を頑張ってやりたい。その一環として、EPUBには非常に積極的に取り組んでいて、彼らは、縦書きはマストである。
私がIDPFにいろいろ働き掛ける前に、台湾も一生懸命働き掛けていた。5人くらいで、IDPFのリーダーたちに「縦書きを入れてくれ」と陳情しに行ったりしていた。なかなかそれが、日程の都合があって実現はしなかったが、台湾としては縦書きを入れてほしくてたまらなかった。
台湾のマーケットがどれくらい大きいか、私は正確に知らないが、香港と足すと、日本より増えるのではないか。
鎌田氏:縦組ルネッサンスのようなものも含めて、20世紀は失われた世紀である。文化的な意味で豊かにしなかった。実用的にはいいが、文化的には豊かにしていない。何千年の漢字文明にアクセスするには縦組が必要であるというような話をしたい。
村田氏:それで中国本土に売り込もう、ついでに繁体字に戻してもらおうというのは、なかなか難しい。
鎌田氏:繁体字で読みたいというニーズもあるはずである。
2011年11月28日TG研究会「EPUB策定の経緯と電子書籍の今後」より(文責編集)