JLREQとCSS（3）
2017/08/04こちらのエントリは、JAGAT XMLパブリッシング準研究会で今期の研究テーマとして、W3C文書「日本語組版処理の要件」（JLREQ）と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。
間違い、補足などございましたらご意見いただければ幸いです。なお、当ブログはコメント許可制を取っているため、反映に時間がかかります。あらかじめご理解ください。
方針としましてはW3C文書「日本語組版処理の要件」（JLREQ）を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか（いないのか）、などについて見ています。なお全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。
なお、こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。また、電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。いずれ当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。
JLREQ 3.1.4 始め括弧類，終わり括弧類，読点類，句点類及び中点類が連続する場合の配置方法
例えば『」「』（閉じカギと開きカギが連続する場合）の間のスペースは前の文字に付くスペースなのか後ろの文字に付くスペースなのか。どちらに付くのかで例えば文字を拡大したときの挙動が変わる。
これに対して次のような意見が出た。
「どちらにつくものでもないので、（CSSの規格やRSの実装としては）前後の文字を二分モノと考えて、適宜スペースを挿入するという考え方もありではないか（小林さん）。」
「適宜スペースを挿入してゆくとどこまでも字間が開いてしまうので、最大値を定めるのもありかもしれない（木枝さん）。」
私個人の意見としては、現状「版面（というべきかどうか）のサイズを本文文字サイズの整数倍にする」というベタ組みの基本ルールが規格化されていないわけで、それを抜きにして個々の箇所のツメを厳密に決めてもほとんど意味がないと思っている。もし今後も当面ベタ組みの規格化が望めないのであれば、小林さんの案のようにスペースをある程度フレキシブルに伸縮できるものとするのがよいのではないか。その上で木枝さんの話のようにスペースによる調整量にリミットを設け、リミットを超過した場合には文字間を割って調整する形にするのがよさそう。
JLREQ 3.1.6 区切り約物及びハイフン類の配置方法
「文末にくる区切り約物（疑問符・感嘆符）の前はベタ組とし，区切り約物の後ろは全角アキとする（図73）．ただし，区切り約物の後ろに終わり括弧類がくる場合は，この字間はベタ組とし，終わり括弧類の後ろを二分アキにする」
！？の後のスペースが行頭に送られて字下げにならないように全角スペースのぶら下がりを許容するべきではないか、という意見が出ていた。
JLREQ 3.1.7 行頭禁則
JLREQ本文には「終わり括弧類，ハイフン類，区切り約物，中点類，句点類，読点類，繰返し記号，長音記号，小書きの仮名及び割注終わり括弧類を行頭に配置してはならない（行頭禁則）．これは体裁がよくないからである．」とあるが、注の表記内でさまざまなバリエーションを記述してある模様。
※ベタ組みの横のラインの保持を優先し、長音記号や小書きの仮名の行頭配置を許容する考え方もあるよう。これは歴史のある出版社に多く見られるルールのようだ。
CSS：禁則
CSS Text Module Level 3 5.3. Line Breaking Rules: the line-break property
禁則に関しての規定。autoでは本来は一行文字数に応じて徐々に緩い禁則になる実装が期待されるが、実際にはあまりそういった実装はされておらず、Normalとほぼ同義になっているものと思われる。
JLREQ 3.1.9 行末に配置する終わり括弧類，句点類，読点類及び中点類の配置方法
「行末に配置する終わり括弧類（cl-02），読点類（cl-07）及び句点類（cl-06）は，その後ろを原則として二分アキとする（図76 ）．」
「（活字組版時代は，次の考え方が主流であった（図78 ）．として）行長に過不足が発生し，行の調整処理で詰める処理の必要がある場合（3.8 行の調整処理を参照），優先的に句点類，読点類及び終わり括弧類の後ろの二分アキをベタ組にする．これは，行末でもあり，これらの後ろの二分アキがベタ組になってもほとんど問題にならないからである．なお，この二分アキを中間的な四分アキにするという方法は採用されていなかった．二分アキ又はベタ組のいずれかを選択する，ということである．また，行の調整処理で詰める処理が必要な場合，句点類，読点類及び終わり括弧類の後ろの二分アキより優先順位は低くなるが，中点類の前後の四分アキをベタ組にする．」
※「そもそも活字の時代には全角の中黒しかなかった」とのこと。必要に応じて削っていたそう。そういった対処が必要だったことが、ツメ処理の優先順位で中点類がカギ類などより後になっていることに影響しているのではないか。
※JLREQはあくまで活版ペースでの記述なので、長体平体の記述はない。おそらく写植起源のため。
「DTPなどでは，行末に配置する句点類，読点類及び終わり括弧類のすべての後ろをベタ組とする処理法も行われている（図79 ）．」
これに対応するCSS指定がtext-spacingの「trim-end」。なお、「no-compress」という指定もあるが、これは後日JLREQ 3.8.2に関連して触れる予定なのでここでは深掘りしない。
JLREQ 3.1.10 分割禁止
「次のような文字・記号が連続する場合は，その字間で2行に分割しない（分割禁止）．これは，それらの文字・記号を一体として扱いたいためである．」
※分離禁止とは違う用語なので注意。
JLREQでは二倍ダーシ、三点リーダ、アラビア数字の字間などの例が挙げられている。
※UnicodeでTWO-EM DASHという符合位置が規定されたのに対応して、2倍ダーシを独自グリフとして持っているフォントも出てきている（源ノ角ゴシックなど）。これは活版のグリフの再現と見ることもできそう。なお符合位置としてはTHREE-EM DASHも既にあるようだ。
※図84の123 4 のアキは位取りとのことだがほとんど見たことがない。用例はどのあたりだろうか？ また、ちょっとわかりにくく、誤植を疑ってしまったのでもう少し桁数を増やして欲しい。
CSS：分割禁止／許容
CSS Text Module Level 3 5.3. Breaking Rules for Letters: the ‘word-break’ property
・word-break:normal
一般的なルールに従って単語を分断する
・word-break:keep-all
単語の中での分断は禁止される。CJKの文字（漢字、かな、カナを含む）は分割されなくなる。
・word-break:break-all
normalでの分断可能部分に加えて、単語の中での分断も許容される。
今回はここまで。次回はJLREQ 3.1.10のgから。
（2017.8.7）
CSS Text Module Level 3のリンク参照先を10 August 2017のワーキングドラフトに変更しました。
（2017.9.4更新）
