‘日本語組版’ タグのついている投稿

JLREQとCSS(6)

2017/11/08

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

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

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

JLREQ 3.5 段落整形,そろえ及び段落末尾処理

 JLREQ内の表記で段落の定義がちょっと整理されていない感がある(木枝さん)との感想があった。
 横組みで採用されていることがあるという説明文の図版の例は縦組みだったりもするようだ。
 なお、ちょっと気がついたのだが、段落先頭にカギ類が来た際の挙動の説明がここにはない。3.1.5で説明済みだからというのはわかるのだが、JLREQが海外の規格策定/ソフトウェア実装担当者の間で辞書的な使われ方をしている実態がある以上、参照リンク程度の配慮はあってもよいのではないかと思う。全部を読み通さないと全体像が見えないというのはこうした文書の性格上よくないと考える。

CSS:ぶら下がりインデント
CSS Text Module Level3 9.1. First Line Indentation: the text-indent property
CSS Text Module Level3でプロパティが多少変わっている。具体的にはhangingというプロパティが追加されており、従来はpaddingとtext-indentを組み合わせることでぶら下がりインデントのレイアウトを再現していたが、text-indent単独で出来るようになっている。また、each-lineは<br/>で強制改行をした後の処理の指定。each-lineを付けておくと<br/>改行の後もtext-indentの処理が行われる。
※試してみたところ、Chromeでは問題なく使えるものの、Firefox、Safariでダメ。まだまだ実際に使うのは難しい模様。

CSS Lists Module Level3
CSS Lists and Counter ModuleからエディターズドラフトでListsのみ分岐。
3.5. Positioning Markers: The list-style-position property
リストのマーカーをどこに置くかの指定。デフォルト(従来のリストの挙動)はoutsideで、ぶら下がりインデント的な組版になる。insideを指定すると普通に行の先頭にマーカーが配置される。insideを指定した上でぶら下がりインデントにするには別途text-indent等で指定が必要になる。

JLREQ 3.5.2 字下げと字上げ

 段落単位の字下げ、字上げについての解説。InDesignでは段落パレットで設定する部分。
※引用文を本文と区別するために字下げする例の解説がある。これは今日ではよりバリエーション豊かな表現が気軽に行えるようになったため、引用部分のフォントを変えるなどといった処理と併せて行われることが多いと思われる。

JLREQ 3.5.3 そろえの処理

 中央そろえ、行頭そろえ、行末そろえ、均等割りなど各行揃え指定の解説。

CSS:行揃え
CSS Text Module Level 3 7.1. Text Alignment: the text-align shorthand
行揃えはCSSではtext-alignで指定する。CSS Text Module Level 3からtext-alignはshorthand(略式プロパティ)となり、個別プロパティとしてtext-align-alltext-align-lastが策定された。text-align-allが段落全体の行揃えの挙動、text-align-lastが段落最終行の挙動。JLREQの図157の右下のような組版例(均等割り)はtext-align-last:justifyの指定で実現できるはず。この指定でChromeでは全行の均等配置の再現が確認できた。規格としてはtext-align:justify-allでも本来は同じ挙動になるはずだが、まだこれは実装されていない模様。
なおtext-alignのstart、end指定は日本語ではleft、rightと同じ挙動。アラビア語などで位置が入れ替わったりはする。justifyは最後の行以外が均等配置になる。

また、7.4. Justification Method: the text-justify propertyではjusify時にどこを空けて調整するかの指定ができる。日本語は通常わかち書きを行わないため、文字間を均等に空けてjusifyの挙動を実現することになる。これがinter-characterinter-wordは英語などで行われる語間スペース調整によるjusifyの挙動の指定。noneを指定するとjusifyを行わないことになるため、text-align:left指定と同様の組版になるはず。デフォルト値はautoで、言語によって適切と思われるjusifyの処理を行う。

JLREQ 3.5.4 段落末尾処理

 「段落の最終行の文字数が,ある文字数未満になることを避けるための処理のことである.ウィドウ(widow)処理ともいう.」
※「オーファン」という語もある。「参照:ウィドウは一行はみ出ること。オーファンは頭の1行目で改ページ(もしくは改段)になること」。

CSS:ウィドウ・オーファンの処理
CSS Fragmentation Module Level 3 3.3. Breaks Between Lines: orphans, widows
「[ orphans/widows ]プロパティは、ブロックコンテナ内の分断において,その[ 前/後 ]に[ 断片内に残さなければならない最小の行ボックス数 ]を指定する。 後述にて、これらを利用して分断を制御する例を与える。」
widows:2;
orphans:3;
のように指定する。
デフォルト値は2。

JLREQ 3.6 タブ処理

 タブはそもそもかなりの部分が表組みと共通する。もともとの技術的な起源が違うために項目が分かれているだけではないか。
 ただ、いわゆる目次でのリーダー後の同一行ノンブル文末揃えのような組版はタブを使わないと実現できない。これはCSS Generated Content Module Level 3 2.5.1 The leader() functionでできるようになるはず。リーダーを入れず、空白にすることもできる。
 また、タブは項目内での複数行配置を想定しておらず、1次元の配列が折り返していくところが表とは違うのではないかという意見も出た(村上さん)。
 なお図160の図はタブの例としてあまり良くないのではないかという意見もあった。もっと通常の表組みでは実現できない例が欲しい。

JLREQ 3.6.2 タブ処理で指定する配置位置にそろえる形式

 タブの揃え位置のバリエーション解説。左(上)そろえタブ、右(下)そろえタブ、中央そろえタブ、指定文字そろえタブ(小数点など)。InDesignのタブ揃えの実装もこれと同様のオプションがある。

CSS:テーブルの中での小数点揃え
CSS Text Module Level 4 9. Alignment and Justification
9.1. Character-based Alignment in a Table ColumnのExample8にあるように、
text-align: "." center;
のような指定でピリオド揃えのセンタリングができるようになる。
text-align: "." right;
なら右揃えで小数点の桁数が揃ってなくても揃えてくれるようになるはず。

JLREQ 3.7 その他の行組版処理

 添え字処理、振分け処理、字取り処理、等号類と演算記号の処理についてそれぞれ解説している。

JLREQ 3.7.1 添え字処理

 添え字処理。まずHTMLのタグとして<sup><sub>がある。いわゆる上付き下付き文字指定。
 複雑なものに関しては数式組版で対応することになる。MathMLなどへの対応が必要か。それでも数字などの細かい位置決めは難しい。Webでの数式組版は現状MathJaxを利用するのが一般的なようだが、これはJavaScriptを用いているため現状EPUB等ではほぼ使えない(電子ペーパー端末でのJavaScriptを用いたインタラクティブ表現の表示再現性の問題や、セキュリティの観点からJavaScriptを禁止しているビューアもある)。

CSS:上付き/下付き
CSS Inline Layout Level3 2.2. Transverse Box Alignment: the vertical-align property
行中での文字の表示位置指定。この項目はvertical-alignがshorthand扱いとなっており、個別プロパティとしてbaseline-shiftalignment-baselineが設定されてはいるが、実際にはshorthandのvertical-alignを使うことという注意書きがある。全体での整合性を取るためにこういった仕様にしたようだ。

alignment-baselineはどのベースラインを基準として上付き下付きにするかの指定。text-topとtop、text-bottomとbottomの挙動の違いはこちらを参照。text-topでは親要素へのline-height指定を継承するので、一見topが下に来たりbottomが上に来たりする挙動になったりするが、ベースラインシフトさせたい部分の文字のline-heightを適切に指定してやればきちんと字義どおりの挙動になるはず。

baseline-shiftはsub、superなどの指定で上付き下付きを指定できるほか、ベースラインシフトの量を絶対値や文字のシフト量をpxの数値やline-heightに対するパーセンテージで指定することができる(これはもうできる)。

今後Level3が勧告の段階に移れば、ベースラインの基準値(alignment-baseline)としてalphabeticideographiccentralmathematicalcenter が指定できるようになるほか、「vertical-align: top 10px」といった形で双方の値を組み合わせて指定できるようになる模様。

なお、化学記号などで上付き/下付きの文字を使う場合には親文字との分離禁止が課題になるが、文字の分離禁止にはいくつかの方法がある。現状無難なのは分割禁止部分をspanでくくってwhite-space:nowrap指定を行う方法。いずれwrap-after:avoid,wrap-before:avoidなどが実装されればそちらでもできるようになるはず(spanで括る必要がなくなる)。また、分割禁止文字を挿入する方法としてU+2060(WORD JOINER)を入れることでも同様の挙動になるはずだが、現状まだChromeではこれは動作しない。

今回はここまで。次回はJLREQ 3.7.2から。

(2017.11.9)

JLREQとCSS(5)

2017/10/19

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

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

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

JLREQ 3.3 ルビと圏点処理

JLREQ 3.3.1 ルビの使用

 ルビの組版処理の方法として、モノルビグループルビ熟語ルビの3種類がある。
 また、ルビの意味合いとしては、ひらがなのルビで漢字の読みを示すもの、カタカナのルビで意味を示す別な言葉を付けるもの、(「避難所」に「アジール」のルビなど)、親文字である欧文の単語の読み方又は意味を示す言葉をルビとして付けるもの、親文字であるひらがな等にルビとして漢字等を付ける(振り漢字)ものなどがある。
 また、熟語にルビを付ける際にまとめて訓読みのルビを付けるケースがある(「紫陽花」に「あじさい」など)。こういったケースを熟字訓と呼ぶ。

JLREQ 3.3.2 ルビの付け方

 出てくる漢字等のすべてにルビを付ける総ルビと、読み方がむずかしい一部の漢字等のみにルビを付けるパラルビがある。

JLREQ 3.3.3 ルビの文字サイズ

 「ルビの文字サイズは、原則として親文字の文字サイズの1/2とする」(児童書などでは3文字つける例もある)。
※ルビでの小書きの仮名(拗促音を本文同様に小書きで書くこと。活版の時代には技術的問題や可読性からルビでの仮名の拗促音小書き表記は使われていなかったが、現在では十分な可読性が維持できるため使われるようになってきている)について、過去にCSSドラフト仕様のText Transformで小書きの仮名を表示上大書きのものに変換するFull Size Kanaというプロパティがあったが、なくなってしまった模様(2011年のドラフトにはあった)。

JLREQ 3.3.4 親文字のどちら側にルビを付けるか

 両側ルビは社会科の教科書など教育系コンテンツで見られる。

CSS:ルビをつける位置(例えば縦組みで親文字の左右どちらにルビをつけるかの指定)
CSS Ruby Layout Module Level1 4.1. Ruby Positioning: the ruby-position propertyでルビ位置を規定している。プロパティとしてoverunderがある。デフォルトはover。inter-characterというプロパティもあるが、これは中国語のピンインに使うためのもの。
なお、ruby-position指定はブラウザベースでもまだ使えないケースが多い模様。使えてもベンダープリフィックスを付けることが必要だったり、古いドラフトの用語で指定する必要があったりする。

JLREQ 3.3.5 モノルビの親文字に対する配置位置

 縦組みで親文字1文字に付く平仮名のルビ文字が1字の場合の配置位置として、親文字の天地中央とルビ文字の天地中央をそろえて配置する中付きと、親文字の上端とルビ文字の上端をそろえて配置する肩付きがある。横組みでは肩付きでの配置は行われない。

CSS:ルビの親文字に対しての配置位置
CSS Ruby Layout Module Level1 4.3. Ruby Text Distribution: the ruby-align property
start:肩付きの指定。CSSとしては肩付きは縦書き専用という規約はない。
center:中付きの指定。
space-around:ルビ文字間にスペースを空けて中央配置。これはいわゆるJISの1-2-1ルール。
space-between:space-aroundに近いが、ルビ文字列の方が長いときの親文字の配置位置に違いがある。図参照。

なお、OpenTypeフォントが持っているルビ字形は、「font-feature-settings: “ruby” 1」の指定で明示的に呼び出すことができる。
参考として、InDesignは組版アプリなのでより詳細なルビのプロパティの指定が可能。ただし両側にルビは付けられない。Wordも中付き、肩付きの指定はできる模様。

JLREQ 3.3.6 グループルビの親文字に対する配置位置

 注に「親文字の文字列の長さに比べ,ルビ文字の文字列の長さが極端に短い場合」の規約がある。ただこれは機械処理でどうにかできるのか疑問。

JLREQ 3.3.7 熟語ルビの親文字に対する配置位置

 熟語ルビは「熟語を構成するそれぞれの漢字等に付くルビ文字がそれぞれ2文字以下の場合,それぞれの親文字の漢字等とルビ文字を対応させ,3.3.5 モノルビの親文字に対する配置位置で述べた方法で配置する」「熟語を構成するそれぞれの漢字等の中で,1字でもそれに対応するルビ文字が3字以上のものがある場合,熟語全体とルビ文字の文字列を対応させて配置する」その上で「熟語ルビは,それぞれの漢字等とそれに対応するルビ文字を単位として2行に分割してもよい」という話になる。分割した場合はそれぞれがモノルビとして処理される。複雑な処理であり、InDesignもまだ熟語ルビには対応していない。
※図133 熟語ルビを2行に分割して配置した例 の図はちょっと行頭行末に親文字が付いていなくて気になる。

CSS:熟語ルビ
CSS Ruby Layout Module Level1 4.2. Sharing Annotation Space: the ruby-merge property
これはまだブラウザでの実装はない。
separate:熟語ルビのマークアップでもモノルビのように扱う。
collapse:熟語ルビのマークアップでもグループルビのように扱う。
auto:いわゆる熟語ルビの挙動になるように表示をユーザーエージェントにまかせる。

JLREQ 3.3.8 ルビが親文字よりはみ出した場合の処理

 ルビ文字の文字列が親文字の文字列より長い場合、前又は後ろにくる漢字にはルビをかけないようにし、平仮名、片仮名、長音記号又は小書きの仮名には最大でルビ文字サイズの全角までルビ文字を掛ける形で組版処理を行う。例外として、前後の文字にかかるルビ文字が繋がってしまう場合は、誤読を避ける意味で親文字の字間を空けて繋がらないようにする。またJIS X 4051では片仮名は漢字と同じ文字クラスに含まれているため、片仮名についてはルビ文字をかけないようにする。

CSS:ルビ文字列が親文字より長い場合
CSS Ruby Layout Module Level1 5.1. Overhanging Rubyに記述がある。また、5.2. Line-edge Alignmentに行頭行末処理の記述もあるが、どちらもJLREQを参照している。

JLREQ 3.3.9 圏点の処理

 「圏点(傍点ともいう)は,漢字等や平仮名などの文字列に付け,その文字列を強調する役割を果たす.」「慣行として,圏点は,句点類,読点類,始め括弧類,終わり括弧類などには付けない.」

CSS:圏点
CSS Text Decoration Module Level3 3. Emphasis Marksで圏点の規定がされている。dot/circle/double-circle/triangle/sesameのそれぞれに対してfilled(塗りつぶす)、open(塗りつぶさない)の指定ができる。また任意の記号の指定もできる。
InDesignでもこれと同じ種類の圏点を指定して付加することができる。
中国語では下に圏点を付けるのが標準であるため、ちょっとGitHubで議論になっている。

3.4. Emphasis Mark Position: the text-emphasis-position propertyで圏点を付ける位置を指定できる。CSS Text Decoration Module Level 3の Appendix Bに各言語ごとの付ける位置の参照情報、デフォルトスタイルシートがある。

なお、圏点、ルビともに日本語組版ではそれによって行間が変動したりはしない。
圏点、ルビを付けた場合の行間についてはCSS Ruby Module の 3.5 Line Spacingに規定がある。行間が十分に広ければ問題にならないが、行間が狭すぎた場合はその限りではなく、自動で行間を広げて処理する形になる。
余談だが同じline-height絡みの話では、現状Webには文字の一部のサイズを大きくした際に行間が広がってしまう挙動の問題があり、今後の課題となっている。

3.4 割注処理

 ここはまあCSS的に当面期待もできないので省略。

今回はここまで。次回はJLREQ 3.5から。

(2017.10.19)

JLREQとCSS(4)

2017/09/04

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

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

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

JLREQ 3.1.10 g 分割禁止

 改行による泣き別れを抑止する文字についての記述。
 gは「ルビ」について。ルビ文字と親文字はバラさない。モノルビは親文字単位ではバラしてよい。グループルビは全体を分割禁止する。ルビ自体に関しては後で詳しくやるのでここではこれまで。
 i 添え字。これも添え字と親字の分割は禁止。
 j 注の合印の分離禁止。HTML的にはa要素で合印を囲む形になるか。CSSでwhite-space:nowrapで合印内を分割禁止にできる。

 また、「○○(1)」のようなパターンでCSSを用いて合印とその直前の文字との間を分割禁止にするには、CSS Text Module Level4で論議中のwrap-before:avoidが使えるようになれば可能になるはず。

 あるいは現状で使える方法として、ノーブレークスペース(&#xA0;)を入れてもよい。また、U+2060(Word Joiner)も同様の効果を持つはずだが、こちらは一般的な日本語フォントにはコードポイントの割り当てがないようだ。

JLREQ 3.1.11 行の調整処理で​字間を​空ける処理に​使用しない箇所

 文字のアケ処理について書いてある項目。空けすぎてはいけない部分などに関しての記述がある。「行の調整処理の際に,字間を空けて処理する場合,次の字間には空き量を入れることは避ける(分離禁止ともいう)」とある。分割禁止分離禁止の用語の違いに注意。
 「規定された調整処理では処理できない場合に限り,欧字の単語の字間を空けることを許容する考え方もある」とあるが、欧文組版では組版調整に単語の字間を真っ先に使うのが普通。ここは昔ながらの欧文の字間は3分アキとしてきた日本の活版の慣習が残っている部分か。

 「b. 上記以外では,次も行の調整処理で字間を空ける箇所としては避ける. 1. 始め括弧類(cl-01)及び終わり括弧類(cl-02)の前及び後ろ.」
 ここは表記がちょっと不明瞭か。始め括弧類の後、終わり括弧類の前、ではないか。直後の注で補足してあるが。

JLREQ 3.1.12 行の調整処理例

 ツメ処理、アケ処理の具体的な適用例の記述がある。
 なお、CSS Text Module Level4で議論中の「text-spacing」「no-compress」を指定すると、justificationでのツメ処理をしない。これを指定しないと文字ツメ処理が行われる。
 このあと3.8で文字ツメに関してはより詳しくやるのでここではここまで。

JLREQ 3.2.1 和文と欧文との混植

 日本語の文章内に欧文の文字を入れる際のバリエーションに関する記述がある。大別すると全角の文字を使っての正立表示、欧文の文字をそのまま入れて横転表示、数字などで使われる縦中横の3種類がある。

JLREQ 3.2.2 横組の和欧文混植に用いる文字

 「なお,欧文間隔は,三分アキを原則とする.」との記述があるのだが、ここは本来はそれぞれ欧文フォントが持つスペースのプロポーショナルな幅に従うべきとの意見が出た。この記述自体は古い日本の活版のルールが起源だと思われる。伝統的なルールの記録という意味でJLREQにこの記述があることは間違っていないが、現時点でそれに盲従すべきでもないと考える。

CSS:数字の字形の種類の指定
 font-variant-numericは数字の字形の指定項目。Old-StyleTabuler(等幅)Lining(高さが揃う)などが指定できる。ただし、もちろんフォント側がそのバリエーションを持っている必要はある。minionやGaramond Proなど新しいフォントは情報を持っているはず。例えばCentury OldStyleなどは作られた時期が古いため、こういったバリエーションは持っていない。

JLREQ 3.2.3 縦組の和欧文混植に用いる文字

 「プロポーショナルな文字を用い,全角のスペースに正常な向きにして配置する方法もある.」との記述があるが、「正常な向きにして」はちょっと表現的にどうだろうか。「正立させて」あたりが順当だと思う。雑感だが何を持って正常とするのかという宗教論争に発展しかねないと思う。

CSS:文字の正立/横転
 text-orientationで指定できる。uprightで正立、sidewaysで横転。段落全体に対して指定もできる。なお、関連する話として、UTR#50で論議されてきた縦書き時の文字の向きの既定値の話がある。これは最近Unicode10.0.0に正式に規格として入った。今後Webブラウザではこれをベースに何も指定しなかった際の文字の正立/横転の向きが決められるものと思われる。ただし、InDesignやWordなど、既存のアプリとの文字の向きの差異はずっと残ると思われる(過去のデータの互換性を考えると簡単に変更はできない)。

CSS:縦中横
 EPUB3策定前後でプロパティ名が目まぐるしく変わった項目。今の正式プロパティはtext-combine-uprightだが、昔はtext-combineでそのあとtext-combine-horizontalになっている。多くのRSでは古いプロパティでも縦中横になるが、今後はtext-combine-uprightを指定しておくのがもちろん正しいと思う。
 なお、text-combine-uprightでは単純に指定範囲を縦中横にする指定、「text-combine-upright:all」以外に、いわゆる自動縦中横の対応として「text-combine-upright: digits 2」といったような指定も可能になっている。ただしまだ数字の縦中横のみが想定されており、アルファベットや小数点はは範囲外。今後の提案と拡張が必要と思われる部分か。

JLREQ 3.2.4 全角のモノスペースの欧字及び​全角の​モノスペースの​アラビア数字の​配置方法

 図100に関連して「全角のモノスペースのアラビア数字の途中に小数点として中点[・] (KATAKANA MIDDLE DOT)を用いる場合は,漢数字の場合と同様に,原則としてその前後をベタ組とする.」とある。これは組版調整ありきで固定された版面をつくるための方法を記録したJLREQの記述としては良くわかるのだが、Webや電子書籍など組版調整が難しい分野でその中点が小数点なのかそうでないのかを自動判別して処理するのは難しそうである。「二、三点」などの場合に用いられる読点のベタ処理も同様。InDesignにはここの処理のために「連数字処理」というチェック項目があるが、組版処理的な弊害もあるため一律に使っておけば良いというものでもなく、難しそう。

JLREQ 3.2.5 縦中横の処理

 Opentypeのフォントは等幅半角字形、等幅3分字形、等幅4分字形などの情報を持っている。これらは縦中横組版の際に綺麗に1文字の幅に数字やアルファベットを収めるために作られたと思われるもので、InDesignでは字形パレットを通じて文字種を切り替えることができる。CSSではまだ十分に整備はされていないが、font-feature-settingsでOpenTypeのプロパティを直接指定すれば切り替わるかもしれない。等幅半角字形のプロパティは「hwid」、等幅3分字形は「twid」、等幅4分字形は「qwid」。ただし表示フォント側がそれに対応する字形の情報を持っていなければ当然適用はされない。ちょっと見てみた感じでは、一般的なAdobe-Japan1規格の日本語フォントでは、数字は等幅4分字形までの情報を持ち、英文字は等幅半角字形までの情報を持っているようだ。その他かな/カナも等幅半角字形にすることができそう。

CSS:縦中横でたくさん文字が入った場合の圧縮ルール
CSS Writing Modes Level 3に 「9.1.3 Compression Rule」として、縦中横でたくさん文字が入った場合の圧縮ルールの規定がある。それによれば、CSSでは全体で1emに収めることを規定している。ここはJLREQとは違うが、後から手動で組版調整ができないWebの特質を考慮すれば妥当と思う。また、表示フォント側にhwid、twid、qwidの情報がある場合はそれを使うことというような規定もある。なければ変形してどうにか1emに押し込む、という方針のようだ。

JLREQ 3.2.6 プロポーショナルな​欧字を用いた​和欧文混植処理

 「b.追込み処理で字間を詰める場合,その処理対象として欧文間隔を優先的に使用し,追出し処理で字間を空ける場合も,その処理対象として欧文間隔を優先的に使用する.」
 ここでは和欧間のスペースは3分という前提なら多少ツメてもよいだろうが、JIS X 4051の規定では和欧間のスペースは4分であるため、それを踏襲するのであれば4分よりもツメるのはツメすぎではないか、という意見が出た。なお現状Webや電子書籍などでは和欧間は自動で空かないが、将来的にはCSSでtext-spacingで自動でアキが入ることが期待される。

 今回はここまで。次回はJLREQ 3.3から

(2017.9.5)

プロフィール
Jun Tajima

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

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

最近のコメント