JLREQとCSS(8)

 こちらのエントリは、JAGAT XMLパブリッシング準研究会で今期の研究テーマとして、W3C文書「日本語組版処理の要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。

 間違い、補足などございましたらご意見いただければ幸いです。なお、当ブログはコメント許可制を取っているため、反映に時間がかかります。あらかじめご理解ください。
 方針としましてはW3C文書「日本語組版処理の要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。なお全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。

 なお、こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。また、電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。いずれ当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。

JLREQ 4.1.1 見出しの種類

 「見出しは,組版処理の方法で分けると,次の4つになる.
 a.中扉又は半扉
 b.別行見出し
 c.同行見出し
 d.窓見出し」
※同行見出しで見出しと本文との間がJLREQでは「全角」とあるが(図188)、必ずしも全角とは限らないのではないかという指摘があった。活版の時代のルールと思われる。

JLREQ 4.1.2 別行見出しの構成

 「別行見出しの構成については,JIS X 4051では大見出し,中見出し及び小見出しについて,それぞれラベル名,番号,見出し文字列及び副題で構成するとしている(図190).ただし,ラベル名,番号及び副題は,必須要素ではなく,省略してもよいとなっている.」
「なお,これ以外に見出しの前後に記号を付ける,あるいは罫線を見出しの前後に配置する,罫線で見出しを囲むなどといったことも行われている」
※このあたりの記述はデザインの話が入り込んでしまっており、規格文書の記述としてはいらないのではないかという指摘があった。

JLREQ 4.1.3 見出しにアクセントを付ける

 ここもほぼデザインの話。技術的にそう多くのオプションがなかった活版時代のデザインの典型例としては興味深いものがあるが、デザイン回りの話だけに異論も多く出そう。

JLREQ 4.1.4 改丁・改ページ・改段処理

 「大見出しなどでは,区切りを明確にするために新しいページから始める方法も行われている.」
 章扉などで見られるような必ず奇数ページから始める処理が改丁、奇数偶数ページにこだわらず、単にページを改めるのが改ページ。雑誌やムック本などで見られるように必ず偶数ページで始めて見開きで記事を読ませるパターンもある。

CSS:扉などの改ページ
CSS Fragmentation module Level3 3.1. Breaks Between Boxes: the break-before and break-after properties
break-after:autobreak-bofore:autoで通常の改ページ。
いわゆる改丁や見開き始まり指定はright/leftでできるようになるはず。
recto/versoは論理値なのでこれが使えれば縦書き横書き共通で改丁などを指定できる。
見開きの最初のページにするのがverso

 なお現状EPUB3では改丁/見開き始まりはOPFファイル内のspine項目で「properties=”page-spread-left”」のように指定する。ただしこれに対応しているEPUBビューアは現状あまりない(観測範囲ではhonto、kinoppyくらい。BOOK☆WALKERも対応しているという報告があった)。全体としてはリフロー型で、中途に見開きの図が挟まるような本で問題となりがち。

JLREQ 4.1.6 行取りの処理例

 「各ページで行を配置していく場合,基本版面で設定した行位置にそろった方が望ましい.そこで,行送り方向の見出しの占める領域は,基本版面で設定した行位置を基準にして設定する方法が行われている.このような設定方法を行取りという.」(4.1.3 dより)
 ここは4.1.3 dへの参照リンクが欲しい。

※ページ先頭に行取りの空改行が入った場合、欧文組版では(上側の)スペースを削除するのが普通で、CSSも現状そうなっている。和文の図201などの処理は行頭でも(右側の)アキを入れる点が違う、という指摘があった。

 図203のような本題と副題が2行の場合、泣き別れを防ぐにはbreak-inside:avoidの指定が必要。

 行取り含めて本文級数×行数で版面を決めて厳密にそれを守る日本語組版では基本となる処理を再現するために、現状議論中のCSS規格で一番近いのはLine-gridなどだが、まだこれも議論中でどうなりそうかはっきりしないとのこと。ここがどうにかならないと、行取りをCSSで指定するといったような話にもならないだろうと思われる。

JLREQ 4.1.7 行取り処理した見出しがページ末にきた場合の処理

 行末に入りきれなかった場合にはブロックごと次ページに。これは行取り処理した見出しに限らず、ページ末尾に見出しが来てしまった場合に次ページに送る処理は一般的に行われている(JLREQ 4.1.4 eの「なりゆき」の記述も参照)。
 なお、見出しと本文の泣き別れを防ぐのはbreak-inside:avoidなどを指定することで可能だが、ノド側に来た場合には見出しと本文との泣き別れを許容する(見開きで次ページの1行目に本文が来るため)ルールを採用しているケースもあるため、そこまでを自動で処理するのはかなり難しそうではある。

JLREQ 4.1.9 同行見出しの処理

 同行見出しはレイアウト的に本文と同一行内に見出しを配置するもののため、例えば

 <p><span class="midashi">見出し</span>本文本文本文本文</p>

 といったような形のマークアップが想起されるが、構造化文書として本来的には

 <hn>見出し</hn>
 <p>本文本文本文本文</p>

 といった形で本文と見出しを記述しておき、CSS指定で同行で見せる方が望ましい。

JLREQ 4.1.10 窓見出しの処理

 これも本来は上記のように<hn>タグと<p>タグを分けてマークアップするべきだが、まだRSの実装的に実際にweb等で再現するのは難しいかもしれない。詳しくは以下参照。

CSS:同行見出し/窓見出し
同行見出し、窓見出しもHTMLの構造としてはhnタグでマークアップした方がよいはず。
そのためのものとして display要素の拡張として Run-In Layout がドラフト規格として考案されている。
display: run-in;
のように指定。

CSS display level3ではdisplayプロパティでdisplay-outsidedisplay-insideを別に指定できるようになっているため、窓見出しの表現も可能になるはず。
display: run-in flow-root;
になるか。floatの指定も必要かもしれない。

JLREQ 4.1.11 段抜きの見出しの処理

 新聞や雑誌で多く見られる段組の複数の段をぶち抜く形の見出し。これはリフローで処理するのは相当負荷が大きそう。一応CSSではできなくはない。

CSS:段抜き見出し
CSS Multi-column Layout Modulecolumn-spanで指定できる。ただし、全段抜きか段抜きをしないかの2択。
なお、multi-column module Level2ではinteger(整数値)での指定も提案されてはいるとのこと。これがもし実用段階に入れば、例えば5段組のうち2段を使った段抜き見出しのようなレイアウトも可能になるだろう。
InDesignでは段落パレットの「段抜きと段分割」で指定できる。ただし、段抜きを行うためにはテキストフレームをひとつにしておかないとならないなどの制約はあり、現状どこまで実用されているかはわからない。

次回 JLREQ 4.2 注の処理 から

(2018.1.5)

タグ: , , , , , ,

コメント / トラックバック 2 件

  1. works014 より:

    「和文の図201などの処理」の件ですが、「3行取り」ならばあのようになります。ただ、「2行取り、かつ前1行アキ」などの場合には「前1行アキ」は「吸収処理」とする場合が多いでしょうね。ただ、この場合も左ページ先頭(ノド)に来た場合は「アキを残す」処理も考えられます(右頁末に1行アキがない場合)。※あくまでも私の経験では…

  2. Jun Tajima より:

    なるほど。参考になります。このあたりは出版社ごとのルールが相当細かく違う部分なんでしょうね。

コメントをどうぞ

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。

最近のコメント