紙の組版¶

丸山さん。InDesignも、ウェブブラウザも、デジタル組版で同じ。InDesignの中もリフロー。紙は最終形態だが、途中ではそうではない。べつもののように分ける理由は？

村上さん。同じデジタル組版。DTPでできたことがウェブブラウザでできなかったものがある。それが改善されるといいなと思う。同じCSSを両方に使えるようになるはずだし、そうなって欲しい。

紙のものをウェブの世界に持ってくるのはダメなんじゃないか？と思っている人もいるはずで、そういう人と議論したいのが今回の趣旨。

JLREQ¶

田島さん。JLREQをどこまで入れたいと村上さんは考えているのか？

村上さん。どういうロードマップかはまだないが、JLREQで実現されていないものも、技術的にすごく難しいものはそれほどないと思う。ブラウザの速度悪化影響や、使う人の数などで実現されないものもあるかもしれない。10年後か20年後か。JLREQが絶対というわけではない。要るのか要らないのか、という議論もあるし、JLREQにはないものでもこれから入れるべきものがあるかもしれない。

仕様作成に至る過程¶

田島さん。ウェブブラウザのCSSの勧告だと、独立した2つの実装が必要となっている。電子書籍だとどうなのか？KindleとKoboとかでもなるのか？

村上さん。CSSの仕様として認められるにはブラウザとして動くことが大切。EPUBリーダーはアプリだったり端末だったりするが、中身はウェブブラウザのエンジンを使って作られている。ブラウザが実装しないと電子書籍としても使えない。EPUBもCSSを参照していたりするし、そうなるべき。CSSの仕様が標準化が必要。そのためには最終的にブラウザの実装が必要になってくる。Polyfillでも認められるのか？今は、JSを使ってCSSをエミュレーションするCSSフーディニーという仕様が決められつつある。それもCSSの実装として認められるようになる可能性もある。

ブラウザの実装状況を表に入れた。ブラウザの実装が進むのを期待している。

JSREQとJIS X 4051¶

丸山さん。JIS X 4051を元にしてJSREQができた。JIS X 4051はそれまであった組版のルールをまとめたもの。ブラウザの実装ありきというと逆転現象ではないか？

村上さん。リコメンデーションになるのは実装が必要。仕様が先か実装が先か、というのは並行して進む。ワーキングドラフト、Candidate Recommendation。そこでブラウザへの実装が呼びかけられて、最終的に勧告になる。CR状況でも完成ではないが、使える状態。逆転現象はない、という印象。

丸山さん。JLREQは紙に特化したレイアウト・デザインの規格を踏襲している。それを今のウェブブラウザにも実装しようとしている。ウェブブラウザにノンブルとか柱はいるのか？どんな新しいこと、新しい表現があるはずだが、CSSの仕様と実装ありきだと、実験できない。新しいものは仕様から生まれない。

（参加者A）JLREQは禁則処理などの文字レベルのものと、レイアウトのものが混ざっている。これは分けて考えないといけない。ページはスクロールだといらない？

（参加者B）JLREQの成立の経緯は過去のものを記録して文書化する、という前提。新しい表現はそこからから生まれる。

（参加者C）JIS X 4051はドメスティックすぎるので英語で出すのが意義としてあった。

（参加者B）JIS X 4051は行頭禁則がすごく多い。実態に即してない。どこから来たのかわからない。JLREQはJIS X 4051を英訳するというスタートだったが、かなり整理している。第二版で4つのレベルに分離してもらった。

（参加者A）JLREQが絶対だと思っている人はたぶんいない。

村上さん。デフォルトの設定とかもきちんと使われ方を見て決められている。JLREQを改定していく時にいろいろ議論していきたい。レイアウトとテキストを分けたい。それはブラウザの実装者の人も乗ってくれそう。ページネーションがブラウザで必要かどうかは議論が必要。今はepubリーダーがいろいろ工夫してページの形に見せている。きちんと仕様があれば実装しやすくなるだろうし、ウェブページもスクロールよりもページの方が見やすいものもあるだろう。今はページネーションは手動でみんな個別に実装しているが、標準化されたらPCとモバイルできちんと使い分けたほうがいいかもしれない。スクロールよりもページのほうが理解が進むという研究もある。ユーザとしては両方できればいいので、ページネーションの機能があればいい。ノンブルがあって・・・というのに意味があるとは思わないが。

（参加者A）印刷したいというニーズもしばらくはなくならない。

村上さん。固定デザインもCSSでできるようになるようになったらいいな、と思っている。

（参加者D）実験がないと仕様にできない、というのはCSSフーディニー（Houdini）がまさに刈り取ろうとしているところ。JSのAPIを追加してページ情報の表示などができるようになる。それが実装として認められるようになるのか？

村田さん。JLREQを無視するのはカオスになる。

高瀬さん。JLREQは紙の出版社がこうしてきたというもの。今紙の出版社100社に聞けば100通りのルールが返ってくるはず。

（参加者E）各社のレイアウトを低コストでできる仕組みがあればいい。雑誌とか広告デザインは今はまったく相手にしていない。

村上さん。オーバーフローしたものを詰めるとかは入れていきたい。DTPに劣らない表現とか読みやすさとか、そこまでCSSも行けるはずだ。

村田さんから¶

村田さん。EPUBが勝手にやっていること。EPUBはHTMLページを複数をまとめている。複数ページを見開きでやる。中扉も独自でやってしまっている。電子書籍でユーザーが期待しているものをEPUBに入れたが、CSSはそれを知らない。普及もしていない。EPUBが紙なのかブラウザに近いのか。

村田さん。JLREQを参照するのが面倒。URLが欲しい。

高瀬さん。項目の中に複数要求があったりして参照しにくい。要求項目に個別にURLがあったらいい。

村上さん。今はgithubにあるので今後はいろいろみんなでできるようになる。みんなで盛り上げていけたら。

高瀬さん。JLREQの責任者は？

村上さん。リチャードなど。まずエラーなどで上がってきたものをまとめるのを今やっている。

試行錯誤について¶

田島さん。今のEPUBのビューアーがいろいろ突っ走っている。そういうのを吸い上げていけたらいいと思う。

村上さん。実際に使われている、というのが実装には力になる。

丸山さん。試行錯誤には淘汰も大事。

田島さん。iBookでは縦書きのときに全部縦にするというのが一瞬実装されたが、今なくなった。

Justify¶

質問。Jusitfyをしないで左詰めが今はウェブで標準。

丸山さん。InDesignは最後人間が必ず見る。Justifyは和洋混色だと空きすぎてひどい。人の目をみないとダメ。ウェブブラウザだと左揃えだとOpenTypeフォントのカーニングもきく。ウェブだとこっちが主流。行長計算が必要。可変ウインドウでのJusitfy自動は筋が悪い。

村上さん。今の実装もそれほど悪くはない。限界があるのは禁則処理がきちんとされきっていない、改行ができるはずのところでできていないなど、そいういところで問題が起きている。実装がよくなればもっとよくなる。一般の人にはある程度受け入れられる状況にはあると思うが、まだレイアウトに厳しい人にはダメだが、今後実装が進めばもっとよくなるはず。文節で改行とかあってもいい。

今はスマートニュースが形態要素解析をして改行を行っている。CSSに入れる？

高瀬さん。日本語を変えたほうが早い？

（参加者）文節を階段状にしたら読みやすくなる、という研究をやっている人もいる

丸山さん。これは見出しのレイアウト・デザインだが、標準に入れるべきものなのか？

（参加者）見出しと長文を分けて考えないといけない

まとめ¶

村上さん。文字、行、ページの組版（JLREQにはある）などをもっと活かしてければ

田島さん。これを題材に研究したい。

丸山さん。DTPで印刷するデータを作っている人たちの中でウェブブラウザダメといっている人はいない。ソフトにはできる、できないはある。できないものを見つけて「ダメだ」と見下すのは筋悪。紙の人が意識高いと誤解している人がいるかもしれないが、そんなことはない。