===================================================== html5j 電子出版部 勉強会「JLREQとCSS」参加レポート ===================================================== :日時: 2017/03/14 19:30〜 :場所: 日本マイクロソフト株式会社 :イベント告知: http://kokucheese.com/event/index/456623/ :参加した人: 渋川よしき Sphinxのアウトプットを魅力的にするためにも仲良くしたいCSS3の最新動向を聞きにきました。 .. raw:: html

今日はこの頃あと19:30から、html5j電子出版部の勉強会『JLREQとCSS』です。 #html5jpub pic.twitter.com/j03uB7AVrm

— Saki(さっくる) (@sakkuru) March 14, 2017
まとめ ======== 初めての参加で、客席?側の方の名前とか分からずすみません。 ドキュメントツールのSphinxのepub改善という立場でまとめると「改行してもいいよ」「ページを分けてもいいよ」という情報をhtml出力側が積極的に出してあげるとレイアウトエンジン(ブラウザ)に優しいHTMLになるんだろうなぁ、と思った。次のページにはゼロ幅スペースというのが説明されている。これをもっと使ってあげるといいのかも。 .. note:: スペースの種類   は半角スペースではないというお話 http://blog.fenrir-inc.com/jp/2011/06/post_51.html * 文字単位レイアウトに関してはSphinxとしてできることは今のところあまりない。Jusitfyの話はいま時点の現実解だと思うけど、Sphinxは今時点で特に凝ったことはしてなかった。唯一、長いURLがあるとレイアウトが酷いことになるので、改行可能な空白をURLの中の ``/`` の前か後に入れられるといいかなとは思った。 * 見出しのレイアウトも特にできることは少ないが、スマートニュースで導入しているという文節で長い見出しを区切れるように形態要素解析を導入、というのは日本語ならではだけどあり。 * ページ単位のレイアウトに関しても、節単位で改ページを挿入してあげてもいいのかも。今だとiBookで、ページを行き来すると表示位置が変わっている、みたいなことがよくある。積極的にページを分けていくことで、変なレイアウトが減るのでは?例えば、30ページ計算しないと段落の位置が決まらない、だとレイアウトエンジンはつらそう。 * 村田さんが言われていた、EPUBが先行して導入したが、あまり普及していないという要素は積極的に取り入れたい。もちろん、索引とかも。 ということをTwitterに書いたら、三廻部氏からフィードバックが。 ```` を使うと、改行が必要な時は改行になり、そうじゃないときはスペースも入らないというタグらしい。これはhtml5としても、xhtmlとしてもvalid。英単語でハイフンを入れたい場合は ``­`` 。なるほど。日本語だと、句読点の後は積極的に ```` を入れてあげるとかしても良さそう。漢字の熟語で、複数の熟語が合成されているものは途中に ``­`` かな。 .. raw:: html

@shibu_jp ゼロ幅スペースと、改行してもいいけどスペースじゃない、の間には微妙に溝がある気がしますねえ。後者をちゃんと満たそうとすると「スペース文字」を使わない、ということになるので、例えばHTMLだと<wbr>?

— Dai MIKURUBE (@dmikurube) March 14, 2017
メモ ======== リブセンスさん。転職ドラフトの紹介とビールのご提供。プロテイン一ヶ月分。 スポンサー枠。マイクロソフト社の物江さんから、BizSparkの紹介。起業サポート。Imagine。学生支援。 村田さんのお話 ----------------- JLREQは、日本語組版について、日本語が分からない人向けに説明したもの。英語以外の言語の説明が英語で書かれたのは初めて。日本ではあまり知られていないが、国際的には評価が高く、金字塔になっている。JLREQを手本にして、韓国語、中国語、インド、挙句の果てに英語自身まで書かれた。 EPUBが日本語対応含めて国際化できたのはJLREQのお陰。JLREQを参照して書かれている。日本語に対する要求がワーキンググループに入った。JLREQがなければEPUB3の国際化はなかったかもしれない。CSSワーキンググループの人もJLREQを調べるようになっている。 まだ足りないところがある。JLREQで書かれても、CSS3の中の優先度が上がらないこともある。半面(づら)。ページメディアの標準化はなかなか進まなかった。これを変えるために提出したのが今回の目的。優先順位をきちんとつける道筋を作りたい。 国際化ワーキンググループでも歓迎される提出だったと期待している。 村上さんのお話 --------------- JLREQでは要求が高いとされているが、まだCSS3では実現していないものについて説明。CSSの要件としてでてきたものが日本語の組版の要求とどれだけマッチしているのか分析した。 * JLREQLの分析: https://www.w3.org/Submission/2017/SUBM-CSJTUWT-20170102/jlreq-analysis.html * momdoさんによる日本語訳: https://momdo.github.io/TR-fragments/SUBM-CSJTUWT-20170102.html * CSSWGのドラフト一覧: https://drafts.csswg.org/ * JLREQ: https://w3c.github.io/jlreq/ja/ JLREQ Analysisは、機能、関連するCSSモジュールの情報と、それぞれのステータス(0-3)、あるなら関連するプロパティがまとまった表になっている。CSSステータスは0はまったく存在しない。1は初期のドラフト(未熟)。2は成熟している。3は完成もしくはほぼ実現手前。あとはブラウザのサポートも0-3で書いている。 細かい内容の前に結論を書くと、テキストレイアウトに関連する仕様、ページレイアウトに関する仕様がJLREQにはあるが、さらなる開発への要求が書かれている。 ボールドはCSSの仕様としては仕様としてはほぼいけるが、ブラウザの実装がいまいち、ということ。例えば、 * ルビは基本実装はされているが、もう少し実装の改善が必要。 * 禁則処理も。 * ページドメディアもCSSの仕様としてはほぼ完成されているが、ブラウザやEPUBリーダーには実装されていない。EPUBリーダーは工夫してなんとかページのように見せている状態。 * フラグメンテーション。改ページ、改段なども、CSS仕様にはあるが実装がまだ。 細字はまだ仕様としてもまだ。ウェブブラウザの実装もまだまだのもの * CSS Text Level4に入っているのは約物をきちんと詰めて配置 * 行グリッド(Rhythmic Sizing) * Page Floats(図版の配置)。CSSだと回り込みしかできないが、ページの上、下に配置した上で回り込みなど。 * Generated Content: ページの中でページ番号、進捗を柱に表示など。 Text 4はCSS Text Level 4、TextはText 3の意味。 紙のためのレイアウトのための仕様をまとめたものではあるが、これを生かしていくのが本当にいいのかどうか、も含めてこれから議論していきたい。 討議 ------- * 村上真雄さん * Vivliostyleの会長さん * 丸山邦朋さん * DTPとかフォントとか詳しい。SNSとかで生半可なことを書くと厳しく指導される。 * 田島淳さん * 印刷会社でDTP、電子の両方を同時にアウトプットするお仕事されている。 * 高瀬拓史さん(進行) * イーストさん 紙の組版 ~~~~~~~~~~ 丸山さん。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で印刷するデータを作っている人たちの中でウェブブラウザダメといっている人はいない。ソフトにはできる、できないはある。できないものを見つけて「ダメだ」と見下すのは筋悪。紙の人が意識高いと誤解している人がいるかもしれないが、そんなことはない。