‘2018/02’ カテゴリーのアーカイブ

JLREQとCSS(9)

2018/02/28

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

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

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

JLREQ 4.2.1 注の種類

 以下の種類があると記述されている。

  1. 後注(こうちゅう):「縦組でも横組でも利用される形式で,段落の後ろ,項・節・章の後ろ又は本全体の本文の後ろに掲げる注」
  2. 頭注(縦組):「縦組において,基本版面の天側に掲げられる注」
  3. 脚注(横組):「脚注は,基本版面の地側に掲げられる注」
  4. 脚注(縦組):「縦組の脚注は,基本版面の設計段階であらかじめ注のための領域を基本版面の地側に確保し,そこに配置していく.頭注の形式に似ているが,注の配置位置を下部にした形式」
  5. 傍注(縦組):「縦組において,見開きを単位として,その範囲にある項目に関連した注を,見開きの左ページ(奇数ページ)の小口側に掲げる注
  6. 傍注(横組):「横組おける傍注は,サイドノートとよばれており,基本版面の設計段階であらかじめ注のための領域を小口側に確保し,ページを単位として,その範囲にある項目に関連した注をそこに配置していく」

※「縦組の傍注の使用例は少ないが,本文の流れを阻害しないで,かつ,関連項目の近くに注を掲げることができるので,もっと利用が増えてもよい形式である.」という文言があるが、執筆者の好みに過ぎず、自動処理的なハードルの高さからもこの文言を規格に入れるのはどうなのかという意見があった。
※「横組おける傍注」→「横組における傍注」と思う。まあ些末だけども。

 このほか、「上記に掲げた注の形式以外に,学習参考書や歴史の教科書などで人物や事項の簡単な説明,古典の現代文への翻訳などを行間に配置する例がある.」という記述もある。これは組版処理としては両側ルビ的な話になるだろうか。

JLREQ 4.2.2 注の番号

 「注は,本文の該当箇所との関連を示さないで,そのページにある項目に関連した注を配置する例もある.しかし,多くは本文の該当箇所との関連を示す注の番号を付け,関連を示す方法をとっている.」
 さまざまな注の番号の付け方を例示。

JLREQ 4.2.3 合印の処理

「1.文字サイズは,6ポイントくらいとする.」とあるが、本文のサイズが書かれていないのに合印のサイズだけが絶対値で出てきていてちょっと違和感がある。合印の本文に対しての相対サイズを書くべきなのではとの指摘があった。
 なお、電子書籍での注は現在、本文中の合印と段落末等に配置した注の説明文との間に相互リンクを貼って処理することが多い。この際にスマートフォン等での操作の都合上、合印のリンク面積を一定量確保する必要があり、必ずしも底本の体裁をそのまま保てない。今後の課題のひとつである。

JLREQ 4.2.4 縦組又は横組の後注処理

 「2.字下げは,基本版面の文字サイズの2倍くらいにする.後注の行長は,後注の文字サイズの整数倍にする.」という記述があるが、これは仕事として組版処理に従事していない規格策定者向けの文書の説明としてはだいぶわかりにくいのではないかと思う。補足はされているもののここだけいきなり組版者向けの業務指示的になってしまっている。もう少しかみ砕いた方がよいのではないか。

JLREQ 4.2.5 横組の脚注処理

 「多段組の場合,各段ごとに段の領域に脚注は配置する(図251 ).しかし,合印があるページの下端に全段を通して配置する方法も行われている(図252).」
 図252の方がよく見る感がある。組版自動処理の技術的難易度としては段抜きになっている分図252の方が難しそう。

JLREQ 4.2.6 縦組の傍注処理

  1. 「縦組の傍注は,その見開き内に付いている合印に対応する注を,奇数ページの左端にそろえて配置する.多段組では最下段の左端にそろえて配置する.」
  2. 「注の分量が多い場合は,偶数ページにはみ出してよい.多段組の場合は,上の段にはみ出してよい.」
  3. 「対応する傍注の全部又は一部が入りきらない場合には,入りきらない傍注部分を,直後の見開きにおける奇数ページ又は奇数ページの最下段に,次の見開きの合印に対応する傍注の前に挿入する.」

 などなど、Web等での自動組版処理を前提にした際、相当にハードルの高い処理のように思われる。技術的手段の記録としてはよいが、今後Webなどで規格やビューア実装の要望を出していく際にこれをこのまま持って行くのは難しそうと思う。ページ固定で手作業での調整が前提になっている部分が多い。

JLREQ 4.2.7 頭注(縦組)・脚注(縦組)・傍注(横組)の処理

 注の番号を付ける方法、記号などで示す方法、そのページ又は見開きにある項目に関係する並列注を掲げるが本文との対応を示さない方法など、様々な注と本文との対応を示す方法の例示。
※技術書などでは本文のエリアを削って注を入れるようなケースもあるという指摘があった。
※注の中だけ組方向が変わるパターンがあるのではないかという指摘があった。索引などでは逆丁はよく見る。

CSS:注
CSS Generated Content for Paged Media Moduleの中で規格化が検討されている。画面内にfootnoteのエリアを自動定義して生成し、表示するような形。

脚注の指定は例えば以下のような形。

このように指定すると、本文内の<span class="footnote">〜</span>で囲まれた範囲内のテキストを脚注として表示してくれるようになるはず。

自動生成される注の表示記号に関しては、CSS Generated Content for Paged Media Module 2.5 footnote counterで、詳細に定義できるようにすることが検討されている。
footnote-callは本文の中で注を入れるための合印の場所を定義するための疑似要素。
footnote-markerは同じく注の側に付けるための疑似要素。
将来的には傍注や段で分かれるタイプの注(JLREQ 図251参照)、複数の種類の注も使えるようになる予定。(参考

2.8. Rendering footnotes and footnote policyは注の配置位置に関しての定義。
autoだと注が本文の該当項目の下に収まらない場合は成り行きで次ページに配置しようとする。
lineだと本文の側をその行で改ページさせて必ず本文と注を同じページに収めようとする。
blockだとlineと似ているが、段落単位で移動させる。
なお横組の脚注などは、float:left/float:rightで現状でもレイアウト的に似たようなことはできる。

JLREQ 4.3.1 図版配置の指定方法

 図版配置の2つの方針についての記述。

  1. 「あらかじめ本文のテキストについて指定の文字サイズ,字詰めや行間で組版し,文字の配置領域のサイズを分かるようにしておき,それを利用して,ページごとにレイアウトを行い,図版を配置する具体的なページと,そのページ内での詳細な配置位置を指定する方法.」
  2. 「図版と本文のテキストとの対応を指示し,ページ内での図版配置位置は原則のみを指定する方法.」

 1はDTPでの組版作業が必須な雑誌的なレイアウトのものか。2は読み物などでの流し込み。Web等での自動組版処理の場合は基本的に2に準じることになる。

JLREQ 4.3.2 図版配置の基本的な考え方

 図版の配置位置の指針。
 「図版と本文のテキストとの対応を指示し,ページ内での図版配置位置は原則のみを指定する場合,本文のテキストの説明と図版配置位置との関係は,同一ページのできるだけ近い位置が望ましい.」
 現状電子書籍では図版の配置位置をページ内のテキストの行数を勘案して前後にずらすような実装は望めないため、画像のサイズによって盛大に余白が生じたりする。特に縦組みで目立つ。将来的に自動で余白領域に連続するテキストを流し入れるような処理を望みたい。

JLREQ 4.3.3 縦組における図版配置の条件

 「本文のテキストを図版の周囲に配置する場合で,その配置領域の字詰め方向の長さが極端に短い場合(例えば基本版面で指定する1行の行長の1/4又は9字以下の場合)は,本文のテキストは配置しないで,空けておいた方がよい」
 これを自動処理でやるのは相当に負荷が高そう。常に表示文字数をカウントして表示を切り替えるような話になる。

4.3.4 横組における図版配置の条件

 段落間に図版を置く場合の画像前後のアキに関する記述がここには見当たらず、JLREQ 4.5.3 行送り方向の領域の調整処理に簡単な記述があった(図312)。こういうのはJLREQ内での内部参照リンクが欲しいところ。

 なおJLREQ 4.5.3は、箇条書きの項目立てが親項目と子項目の見かけがほとんど同じで、インデント等ではっきりわかる形にもなっていないため大変わかりにくい。修正を望みたい。

CSS:図の回り込み
CSS Page Floatsで規格化が進行中。

3.1. The float-reference property
float referenceでどこを基準としてfloatさせるかを選ぶ形に。今のfloatの挙動と同じなのがinline。加えて段落、ページなども選べるようになるはず。
3.2. The float property
これで top | bottom などを指定することでページ内上部、下部などの指定もできるように。top righttop leftなどの指定も検討されている。
なお現状のfloatの挙動は inline-startinline-end に相当する。

JLREQ 4.4.1 表の構成

 「表は,こま(小間,セル)内に数字や事項などを配置し,そのこまを縦及び横の列又は行として配置,一覧できるようにしたものである.」
 表は項目のセルだけ組み方向が変わったり、ページまたぎの要素があったりとかなり複雑な処理を必要とする組版処理である。InDesignでもページをまたぐ大きな表の作成では手動でセルを分割して調整をする必要があり、自動で流し込んで終わりというわけにはいかない。当然電子書籍でのTableタグを用いた表組みもビューアの側の対応が追いついていないケースはあり、また項目の数が多い表を画面サイズの小さなデバイスで表示する際などはどうしても表示が破綻してしまうケースはある。
 図293 見開きを単位として配置した表の例には、見開きの図表の場合にノドをまたいでキャプションが入る例が紹介されている。こちらなどは自動組版処理での対応は相当以上に難しいと考えざるを得ない。

CSS:表が複数ページになった場合にページ先頭にヘッダーを繰り返し表示する処理
CSS Repeated Headers and Footersで一応提案はされているが、まだドラフトにもなっていない。細かな挙動の制御ができることを目指している。
最低限の繰り返しの挙動の定義はこちら。ここまではドラフトになっている。
表の外側の罫線を分割した双方のページに表示させるかさせないかの制御はCSS Fragmentation Module Level 3のbox-decoration-breakで指定。

JLREQ 4.5.1 ルビなどが付いた場合の行間の処理

 「次のような例では,文字の大きさなどにより行間にはみ出して配置する場合がある.」とあり、例の中に「5.段落で指定された文字サイズより大きいサイズの文字列」の記述がある(図301)。この本文の文字のサイズに従って行間(line-heightの値)を固定する処理が現状Webや電子書籍ではできない。いくつかドラフトでの提案は行われている模様。
 「行間に配置する次のa~cを版面又は段の領域の先頭行に配置する場合は,先頭行に接する版面又は段の領域の外側に配置する」
 ここは現状Webや電書では難しい処理(Webのページレイアウトののボックスモデルの例外になるため)。ぶら下がりなども同様の理由で難しい。

 JLREQはこの後の部分は資料となるので、本文に当たるパートは今回で一応全て読み終えたことになる。次回以降、要望の優先順位の検討や電子書籍用RSの対応をチェックしていく予定。

(2018.3.2)

プロフィール
Jun Tajima

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

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