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

日本語組版処理の要件(JLREQ)改版に関するご意見募集のお願い

2019/04/25

 W3C文書「日本語組版処理の要件(JLREQ)」の改版作業が始まっています。JLREQは海外のシステム開発者などに向けて日本語組版を扱うシステムで対応するべき要件を伝える目的で作られた文書で、現在最新の第2版は2012年4月に発行されていますが、これをより正しく、使いやすい形に直してゆく作業です。

 この流れで私もW3CのJapanese Text Layout task force (jlreq)の会合で現場サイドとしての参考意見を述べることになりました。せっかくですので日本の組版関係者からの意見も集約したく思い、このブログを書いています。あくまで私が出版・組版関係の人の意見を聞くために個人としてやる聞き取りであって、W3C公式でもなんでもないのでお間違いなきよう。GitHubにissue立てるの慣れてる人はそちらが早いと思います。

 一応「日本語組版処理の要件(JLREQ)」がどういう性格の文書なのかということについて触れておきます。これはW3Cの正式な文書なのですが、「規格書(Specification)」とは異なり、「要件(Requirement)」になります。ざっくり言いますと「日本語組版で行うべき処理(=紙の本の組版作業において行われてきた処理)をそれを実現する技術的な方法には踏み込まずに記述したもの」です。書かれている処理には従来手作業で行われてきたものも多く含まれていますので、Webなど自動流し込み処理を前提とせざるを得ないシステムでは実現困難なものも多く入っています。従って、「日本語組版処理の要件(JLREQ)」に記述があるからといって、将来確実にWeb等で使えるようになる、という話では全くありません。ただし、新たに海外のシステム開発者が日本語組版に関連するシステムを作るような場合に真っ先に参照される文書であることも間違いなく、実際W3C仕様の中には日本語組版処理の要件を参照先としたリンクが多数既に入っています。次世代の組版ソフトが開発される際にも当然参考にされるでしょう。このことから、やはり将来日本語の表示環境に今回の改訂が大きな影響を及ぼしそうとは言えるかと思います。

 つまり、「これまで紙の本作りで行われてきた組版処理の方法を自動処理的にできるかどうかは考えずにひとまず記録しておいて、(日本人だけでなく)誰もが参照できるようにしようよ」という話なので、「日本語組版処理の要件」に目を通していただき、普段やっている組版処理とは違う記述が標準とされていて違和感があったら教えて欲しいですし、普段の仕事で普通にやっていることが項目ごと抜けていたら指摘していただければ有り難いです。それは改版に盛り込む価値のある情報の可能性があります。

 私も参加していますJAGAT XMLパブリッシング準研究会では、過去数年にわたってJLREQに沿ってCSSの実装状況を見てきており、それについての議事録はこのブログの過去エントリにまとまっています。以下にリンクをまとめて掲載します。

JLREQとCSS(1)
JLREQとCSS(2)
JLREQとCSS(3)
JLREQとCSS(4)
JLREQとCSS(5)
JLREQとCSS(6)
JLREQとCSS(7)
JLREQとCSS(8)
JLREQとCSS(9)

 こちらなども参考にしていただき、JLREQ改訂に関してのご意見をいただければと思います。これはどういった要望がありそうかについてのざっくりとした意見募集ですので、技術的な実現の難易度などは気にせず自由に意見を寄せていただいて大丈夫です。ご意見はこちらのブログのコメント欄に書き込んでいただいても構いませんし(コメント許可制のため表示反映までに時間がかかりますのでご了承ください)、Twitterで私のアカウント宛てにメンションを飛ばしていただいても構いません。その際はハッシュタグ「#jlreq」等を付けていただけますと後日拾い上げる際に漏れがなさそうかなと思います。

 出版・組版関係者の方、よろしくお願いいたします。

(2019.4.25)

Japanese Gap Analysisを読んでみる

2018/10/18

 JAGATのXMLパブリッシング準研究会の活動でここ数年、日本語組版処理の要件を扱っているのですが、その流れで先日(再度)作られたW3CのJapanese Layout Task Forceに協力することになりました。そもそもXMLパブリッシング準研究会での研究活動の最終的な目標のひとつはW3Cに何らかの形でフィードバックを行うことだったので、歓迎すべき流れです。これに従い、報告に当たっての要素の大項目分けに相当するJapanese Gap Analysisを読み込んでみました。かなり噛み砕いて日本語組版での用語に擦り合わせる作業が必要になり、ちょっと意味の取れない箇所もありました。お気づきの点は随時ご指摘いただければと思います。

全体的な位置づけの確認

 まず、文書の全体的な位置づけを確認しておきます。世界中の書字言語でどこまでCSS等での組版処理が実現できているかを示すマトリックスがこちらです。色分けされていますが、

  • 濃い は 「All needs covered (ie. OK), or not applicable」 → 全ての要望が実現できているか、あるいは(その言語では)適用する必要がない
  • 黄  緑 は 「Basic needs covered, but work needed for advance publishing」 → 基本的な要望はカバーできているが、より高度な要望のための作業が必要
  • オレンジ は 「Can create interoperable web pages, but work still needed for basic features」 → 運用可能なWebページを作成はできるが、まだ基本的な部分で対応しなければならない要素が残っている
  •  赤  は 「Something prevents interoperable or effective use of the language in webpages」 → 運用可能なWebページをこの言語で作成するに当たって阻害する要素が残っている

 という意味です。その他に「?」が随所にあり、これは状況の調査がまだ済んでいないということのよう。
 なおこの文書含めて何度も「Script」という単語が出てきますが、これはこの場合は「書字言語」、書き言葉の意味です。Languageだと話し言葉を含むもっと広い意味での言語の意味になるので峻別のために使っているのでしょう。

 マトリックスの列が項目分け、行が各国の言語です。
 この行の中の「Japanese」の文字をクリックすると(すぐ上のJavaneseは「ジャワ語」)、今回読んだJapanese Gap Analysisのページが出てきます。もちろん日本語だけではなく各国語向けに同様のページがあるようです。世界中の言語を網羅的に項目を作っているので、項目自体が日本語には必要の無い箇所も多々あるのですがこれはまあ仕方ないところ。今回W3Cが求めているGitHubへの意見のフィードバックはこの大項目に従い、各項目内にIssueを立てて行く形で行われていくと思われるので項目内容の把握は大事です。それでは見ていってみましょう。

Japanese Gap Analysisの各項目

2. Characters and phrases(文字とフレーズ)

2.1 Encoding considerations(エンコーディングに関する考慮事項)

OK

 OK扱いのためコメントはなし

2.2 Fonts(書体)

Needs Research

Do the standard fallback fonts used in browsers (eg. serif, sans-serif, cursive, etc.) match expectations? Are special font or OpenType features needed for this script that are not available?
   ↓
(明朝体、ゴシック体、筆記体などの)デバイス標準搭載フォントによる表示は適切ですか? あなたの言語の表示に必要な特別なフォントやOpenTypeの機能は利用できますか(Webフォントの使用などか)?

コメント:

  • 日本語では筆記体はほぼ考慮しなくてよいと思う。
  • 現状Firefoxではドキュメント側の指定フォントよりブラウザの設定項目でユーザーが設定したフォントが優先されて表示される模様。
  • 「font-feature-settings」などフォントの内部情報をCSSで呼び出して実現する表現もここに分類されるか。

2.3 Font styles(書体のスタイル)

Needs Research

Do italic fonts lean in the right direction? Is synthesised italicisation problematic?
   ↓
イタリック体は正しい方向に傾けて表示できていますか? イタリック体の合成表示に問題がありますか?

コメント:

  • 網羅的な調査はしていないが、縦書き文中に挿入された欧文部分でイタリック表示の処理に問題を持つRSはある。たとえば現状、Kindle等の縦書き時のイタリック体の表示は不適切。
  • Kinoppy等は適切に表示できている上、フォント側がイタリックのグリフを持っている場合にはそれを用いて表示しているように見える。本来はそれが望ましい。
  • Edge等は単純に文字をシアー変形処理で傾けて表示する。Kinoppy等はフォントがイタリックのグリフを持っている場合にはそれを呼び出して表示させる。欧文の部分の表示最適化の意味ではもちろん後者がよい。ただ、イタリック体の情報を持たない漢字などに対してイタリックが指定された場合に傾けて表示することが適切かどうかは議論が必要そう。
  • ひらがな、カタカナ、漢字などには本来はイタリック体の概念はなかったので本来的には当然イタリック体の合成も考慮する必要はないはず。最近モリサワなどから連綿体のフォントも出てきているが、また例外と考えてよいと思う。

2.4 Glyph control(字形のコントロール)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

2.5 Cursive text(筆記体)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

2.6 Quotations(引用)

Needs work for advanced level support

Are there any issues when dealing with quotations marks, especially when nested? Should block quotes be indented or handled specially?
   ↓
引用符を扱うときに、特にネストされたときに問題はありますか? 引用符をインデントしたり、特別に扱ったりするのは避けるべきですか?

 2.6.1〜2.6.3の子項目が立っているがこちらの守備範囲では無さそうなのでコメントはなし。HTMLのQタグを使った際に自動で付けられる引用符の挙動に関して言っているようなのだが、あまりそのあたりはなじみがない。論文などでの話だろうか。

2.7 Numbers, dates, etc.(番号、日付その他)

OK

 OK扱いのためコメントはなし

2.8 Text boundaries & selection(テキスト境界と選択)

Needs Research

 When you double- or triple-click on the text, is the expected range of characters highlighted? When you move through the text with the cursor, or backspace, etc. do you see the expected behaviour? Are there issues when applying punctuation than could be fixed by the application? (Some of the answers to these questions may be addressed in other sections, such as line-breaking, or initial-letter styling.)
   ↓
 テキストをダブルクリックまたはトリプルクリックすると、予想される文字の範囲が強調表示されますか? カーソルやバックスペースなどでテキストを移動すると、予想される動作が見えますか? 句読点を適用する際に、アプリケーションによって修正される可能性のある問題はありますか?(これらの質問に対する回答の一部は、改行や頭文字のスタイリングなど、他のセクションで扱うことができます)。

コメント:

  • ブラウザの挙動に関する項目だろうか。

2.9 Transforming characters(字形変換)

Needs work for basic styling support

Does your script need special text transforms that are not supported? Does your script convert letters to uppercase, capitalised and lowercase alternatives according to your typographic needs? Do you need to to convert between half-width and full-width presentation forms?
   ↓
あなたの言語にはまだサポートされていない特別な文字の字形等の変換処理がありますか? あなたの言語は、すべて大文字、大文字と小文字の選択肢で文字を変換して表示することがありますか(欧文のキャピタライゼーション)? 半角と全角の字形を変換する必要がありますか?

コメント:

  • 字形の自動変換処理に関しての項目。日本語では縦書きと横書きで一部記号類の字形が変わるが、これは既にほぼサポートできている。
  • text-transform: full-width がGecko(Firefox)でのみ動作するとあるが、これは英数字の縦書き時全角変換を指したものだろう。確かにInDesign等でそういった処理はあるが、そこまで一般的なルールでもないので後回しでよいと思う。
  • Kindleは縦書きの際にダブルクォートをダブルミニュート(ノノカギとも言う)に強制自動変換して表示する実装を行っているが、これはどんな場合でもそうなるのが正しいというわけではないので明確な間違いである。コンテンツ制作者が選択すべき部分。

2.10 Inter-character spacing(文字間スペース)

Needs Research

Some scripts create emphasis or other effects by spacing out the letters or syllables in a word. Are there requirements for this script/language that are unsupported? (For justification related spacing, see below.)
   ↓
一部の言語では、単語内の文字または音節の間隔を開けて強調またはその他の効果を表します。あなたの言語に関してまだサポートされていない要件はありますか?(均等割付に関連する間隔の処理については、下記を参照してください。)

コメント:

  • いわゆる「分かち書き」に関係する部分。一般的には日本語では分かち書きは行われないが、カナモジカイに見られるように過去に事例自体はあった。また絵本や障がい者向けコンテンツでは分かち書きを行うことがあるようだ。
  • 日本語でもデザイン的な意味で見出しなどの文字の間隔を開けることはあり、これはletter-spacingで既に実現できている。

2.11 Ruby annotation(ルビ)

Needs work for basic styling support

The ruby spec currently specifies an initial subset of requirements for fine-tuning the typography of phonetic and semantic annotations of East Asian text, including furigana, pinyin and zhuyin fuhao systems. Is is adequate for what it sets out to do? What other controls will be needed in the future?
   ↓
ルビの規格は現在、ふりがな、ピンイン、(主に台湾で用いられる)注音符号のタイポグラフィの初期的なサブセットを規定しています。適切な規格化がなされていますか? 将来的に仕様の追加は必要ですか?

2.11.1 Tabular markup(表形式のマークアップ)

コメント:

  • いわゆる熟語ルビのマークアップに関する項目と思う。熟語ルビに関してはこちらを参照。
     現状ルビタグのマークアップは

     
    <ruby>親<rt>おや</rt></ruby><ruby>文<rt>も</rt></ruby><ruby>字<rt>じ</rt></ruby>

     
     のように行われるが、これを

     
    <ruby><rb>親</rb><rb>文</rb><rb>字</rb><rt>おや</rt><rt>も</rt><rt>じ</rt></ruby>

     
     のようにすることで、(過去に<rp>タグで行われていたような)ルビの表示が難しい環境でのふりがなの補完表示が可能になるということのようだ。また、通常のモノルビでのマークアップの場合の検索性の問題も指摘されている。

     
     「This also makes certain applications of double-sided ruby impossible when the ruby on each side of the base spans a different set of base characters.」がちょっと意味的にわからない。両側ルビで双方のルビが違うベース文字に対してかけられていた場合の問題ということだろうか?(超レアケースだと思います)

2.11.2 Double-sided ruby(両側ルビ)

コメント:

  • 縦組みで左右、横組みで上下に違ったルビを表示するための項目。ルビをどちら側に付けるかを指定するためのプロパティ、ruby-positionを使うことになる。Firefoxで標準動作、Safari、Chromeではベンダープレフィックスがいるが動作する、とある。

2.11.3 Ruby aligment and other styling(ルビの整列、その他のスタイリング)

コメント:

  • いわゆる肩付きルビ、中付きルビなどの指定に用いるプロパティ、ruby-alignに関する項目。Firefoxでのみ動作するほか、Edgeでは独自の構文で動作する、とある(ベンダープレフィックスのこと?)。今電子書籍では一般的にルビは全て中付きになるため、肩付き、中付きを指定できるようになるのは確かに進化ではある。ただ絶対に必要とまでは言えないと思う。

2.12 Text decoration(テキストの装飾)

Needs Research

Some aspects related to the drawing of lines alongside or through text involve local typographic considerations. Do underlines need to be broken in special ways for this script? Do you need support for additional line shapes or widths? Does the distance or position of the lines relative to the text need to vary in ways that are not achievable? Are lines correctly drawn relative to vertical text?
   ↓
テキストに沿って描画される線(傍線)、もしくはテキストの上を通るような線(打ち消し線)の描画に関して、ローカルなタイポグラフィにおけるいくつかの側面を考慮しなければなりません。この言語では、下線を特別な方法で分割する必要がありますか? 線の形や線幅に関してさらなるサポートは必要ですか? テキストと線の距離や位置に関して、現状達成できていない点はありますか? 縦書きのテキストでの線の表現には問題がないですか?

コメント:

  • InDesign等の組版ソフトでは現状さまざまな種類の傍線、打ち消し線のバリエーションを選べるが、電子書籍ではそこまで種類を選べないのでギャップはある。波線などは使えるようになって欲しい。
  • 縦書き時にtext-decorationで指定した線がテキストのどちらの側に付くのかに関してEPUBのRS間で差異があった。このため、安全策としてtext-decorationではなくborderを使う方針としている例がある。
  • 傍線とテキストの間隔の調整などはtext-decorationでは指定できないがborderでpaddingを指定してやれば調整できる。text-decorationでも細かな調整ができるようになるべきなのかどうか。

2.13 Emphasis & highlights(強調表示とハイライト)

Needs work for advanced level support

Bold and italic are not always appropriate for expressing emphasis, and some scripts have their own unique ways of doing it, that are not in the Western tradition at all. Does this script require support for emphasising or highlighting text that cannot be achieved currently?
   ↓
太字やイタリック体は強調の表現に常に適切というわけではなく、一部の言語はそれぞれに西洋の伝統にはない独自の強調表現方法を持っています。日本語は、テキストを強調または強調するための現在達成できていない部分のサポートを必要としていますか?

コメント:

  • 日本語独自の強調表現としては圏点(傍点)があるが、これもEdgeなど一部を除けば基本的にほぼ使える状況にあるはず。ただ圏点の色指定や、特定の文字を指定しての圏点表示などは調査がいりそう。
  • 2.13.1 に追加要件としてルビと圏点が被った場合の表示についての記述がある。Firefoxは現在これを両方表示できる。Chrome、Safariは被った場合は圏点を表示しない。これはどちらが正しいのか議論が必要そう。

2.14 Bidirectional text(双方向テキスト)

Not applicable

コメント:

  • この項目はNot applicable(適用する必要がない)扱いで一般的な話としてはそれでよいと思うが、明治期などの日本語の横書きテキストには右→左の書字方向でに記述されているものがあるのでこれは考えないでよいだろうか?

2.15 Other inline features(その他のインライン項目)

Needs Research

Does the script have special ways of representing inline notes (such as wakiten or kumimoji in Japanese) or other inline features that need to be supported?
   ↓
あなたの言語には、インライン・ノート(日本語のwakitenやkumimojiなど)やサポートが必要なその他のインライン・フィーチャーを表す特別な方法がありますか?

コメント:

  • 「such as wakiten or kumimoji in Japanese」と例を上げてあるが、wakitenは傍点と同じでよいのだろうか。
  • 組み文字は「㍉」「㍾」のようなもののことのようで、これは既に表示できている。

3. Lines and Paragraphs(行と段落)

3.1 Line breaking(改行)

Needs Research

Does the browser capture the rules about the way text in your script wraps when it hits the end of a line? Does line-breaking wrap whole ‘words’ at a time, or characters, or something else (such as syllables in Tibetan and Javanese)? What characters should not appear at the end or start of a line, and what should be done to prevent that?
   ↓
ブラウザはあなたの言語のテキスト改行処理に関してどういう挙動を示していますか? 改行によって単語が分割されることは許可されますか? されませんか? あるいは(チベット語やジャワ語の音節区切りのような)独自の改行に関してのルールがありますか? 行末や行頭に来てはいけない文字はありますか、それを避けるためにどういう処理が行われますか?

コメント:

  • 改行の禁則処理に関しての項目。JLREQでは拗音、促音を行頭に置くことを禁止する、いわゆる「強い禁則」を日本語の基本ルールとしているが、過去の出版物を見る限りでは必ずしもそうとも言えない。歴史ある出版社はむしろ拗音、促音を行頭に置くことは許容していたりする。また、今後Webで日本語のテキストを表示する機会が増えることを考慮すると、画面の小さな端末で1行文字数が少なくても組版の破綻しにくい「弱い禁則」を基本とした方が良いのではないかという意見もある。

3.2 Hyphenation(ハイフネーション)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

3.3 Justification(均等割付)

Needs Research

When text in a paragraph needs to have flush lines down both sides, does it follow the rules for your script? Does the script need assistance to conform to a grid pattern? Does your script allow punctuation to hang outside the text box at the start or end of a line? Where adjustments are need to make a line flush, how is that done? Do you shrink/stretch space between words and/or letters? Are word baselines stretched, as in Arabic?
   ↓
段落のテキストの行末を一直線に揃えるように組版処理が行われることは、あなたの言語のルールに従っていますか? グリッドパターンに従うように組版処理を行うために補助は必要ですか? あなたの言語は句読点がテキストボックスの行頭もしくは行末にはみ出して表示されることを許容していますか? 行末ラインを一直線に揃えるために各行内のスペース調整が必要な場合、それはどのように行われますか? 文字や単語の間のスペースを伸縮させていますか? アラビア語のように単語のベースラインは伸びていますか?

コメント:

  • 均等割付(ジャスティファイ)に関する項目。日本語は一般的に均等割付処理が行われる言語で、また単語と単語の間にスペースを入れることは一般的には行われず、均等割付のためのスペース調整は文字と文字の間をツメる、アケるという形で行われる。行頭字下げ、行末字上げや行中の括弧類、句読点など前後のツメ・アケ処理に関連する現在規格策定中のプロパティ、text-spacingはここで議論されるべき項目だろう。
  • 伝統的な日本語書籍組版には「書字方向のテキストボックスのサイズを本文文字サイズの整数倍にする」というルールがある(いわゆるベタ組)。これもここの項目の範疇だろう。

3.4 Counters, lists, etc.(カウンター、リスト)

Needs work for basic styling support

The CSS Counter Styles specification describes a limited set of simple and complex styles for counters to be used in list numbering, chapter heading numbering, etc.The rules plus more counter styles (totalling around 120 for over 30 scripts) are listed in the document Ready-made Counter Styles. Do these cover your needs? Are the details correct? Are there other aspects related to counters and lists that need to be addressed?
   ↓
CSS Counter Stylesの仕様はリストや章見出しの番号などに用いられる限定されたシンプルな、あるいは複雑なスタイルを規定しています。追加されるカウンタースタイル(トータルで30の言語にまたがる120種類にもなる)は、Ready-made Counter Styles.にリストアップされています。これはあなたのニーズを満たしていますか? 細部は正しいですか? カウンターやリストに関して対処しなければならない別の側面の課題はありますか?

コメント:

  • リストや見出しの自動ナンバリングに関しての項目。現状<ol>タグで囲ったリストでは各項目先頭に自動でナンバリングされた数字やアルファベットを表示できるが、これの種類の拡張が検討されている。Ready-made Counter Styles.を覗いてみると、「甲・乙・丙・丁」や「子・丑・寅・卯・辰・巳」といったような項目も見える。また、縦書き時のリストナンバーにピリオド付き数字を使う例も挙げられている。li::marker { text-combine-upright: all; }の指定を使うようだが、これはまだ一般的には使用できないとのこと。
  • 電書協ガイドでは本文中にリスト構文を使うことを禁止しているが、セマンティクスやアクセシビリティの観点からは本来はリストはリスト構文で記述されることが望ましい。

3.5 Initial letter styling(段落先頭の文字のスタイル)

Needs Research

Does the browser or ereader correctly handle special styling of the initial letter of a line or paragraph, such as for drop caps or similar? How about the size relationship between the large letter and the lines alongide? where does the large letter anchor relative to the lines alongside? is it normal to include initial quote marks in the large letter? is the large letter really a syllable? etc. Are all of these things working as expected?
   ↓
ブラウザやeリーダーは、ドロップキャップなどの行や段落の最初の文字の特殊なスタイルを正しく処理していますか? 大きな文字が入った際の行間のサイズ関係はどうですか? どこに大きな文字のアンカーは並んでいますか? 大きくした文字の最初に引用符を含める表示は正しいですか? 大きな文字は本当に音節ですか? これらのすべてが期待どおりに機能していますか?。

コメント:

  • ドロップキャップなど、段落の先頭文字に特殊な組版処理を行う例は日本語書籍ではあまり多くはないが、雑誌などを見るとそれなりの頻度では使われている。またこれは段落の最初に文字が来たときに限らないが、行中の一部の文字を大きくした際にline-heightがそれに引きずられて変わってしまい、レイアウトが崩れる例はずっとある。CSS Rhythmic Sizingでそのあたりが手当てされるはずなので普及を待ちたい。

3.6 Baselines & inline alignment(ベースラインとインラインの文字揃え)

Needs Research

Does the browser support requirements for baseline alignment between mixed scripts and in general?
   ↓
ブラウザは、多言語混植の場合と一般的な場合それぞれに対してベースライン位置揃えができていますか?

コメント:

  • 上付き、下付きなどで使われる行中の一部の文字の位置合わせの指定。上付き、下付き程度ならば現在もう使えるが、多言語の混植となるとちょっとわからない。

3.7 Other paragraph features(その他の段落の機能)

Needs Research

In your script, is the first line of text typically indented at the start of a paragraph? Are there other features of paragraph design that are peculiar to your script?
   ↓
あなたの言語では一般的に段落行頭のインデントが行われますか? あなたの言語に特有の段落デザインに関するそれ以外の機能はありますか?

コメント:

  • 日本語は一般的に段落行頭字下げを行う言語なのでここは相当する。

4. Layout & pages(レイアウトとページ)

4.1 Bidirectional layout(双方向レイアウト)

Not applicable

 Not applicable(適用する必要がない)扱いのためコメントはなし

4.2 Vertical text(縦書きテキスト)

Needs work for basic styling support

Are the script requirements for vertically oriented text met? What about if you mix vertical text with scripts that are normally only horizontal? Do you need a switch to use different characters in vertical vs. horizontal text? Does the browser support short runs of horizontal text in vertical lines (tate-chu-yoko in Japanese) as expected? Is the orientation of characters and the directional ordering of characters supported as needed?
   ↓
縦書きテキストの言語的要件は満たされていますか? 縦書きの文中に通常横書きでしか表記されない多言語が混ざった場合の表示はどうでしょうか? 縦書き、横書きで異なる文字を使用するためのスイッチがいるでしょうか? ブラウザは(日本語の縦中横のような)縦書きテキスト中にごく短く横書きが混じるようなケースをサポートできていますか? 必要に応じた縦書き中の文字の向きの指定はサポートできていますか?

コメント:

  • 和文中に英文が混じる程度の表記はほぼ表示が実現できているが、アラビア語のような右から左に書くような言語でどうなるかは調査してみないとちょっとわからない。
  • 縦横で文字の字形(句読点や括弧類など)を随時切り替える仕組みは既に動いている。
  • セマンティックス的には異なる言語が挟まる際には属性値langおよびxml:langで該当部分を指定し、それに準じてフォントが変わる形が良いように思う。

4.2.1 Vertical form controls(縦書き時のフォームのコントロール)

One major gap is handling of vertical text in forms. Only the Firefox desktop browser does a good job of this.
   ↓
大きなギャップの一つがフォーム内テキストの縦書き時の表示です。現状Firefoxだけがこれをうまく処理できています。

コメント:

  • これは日本語組版ではなく完全にWebサイト制作での話。ひとりのユーザーとしてはフォームは横書きでよい気はしている。ドロップダウンメニューなどはそのまま横倒しにして配置されてもちょっと違和感がある。

4.2.2 Upright text orientation(テキストの正立指定時の向き)

Another gap is the CSS text-orientation property. It is only supported as standard by Firefox. Safari has buggy support if you use the -webkit proprietary extension: it has a problem centering the letter in the vertical line.
   ↓
さらにCSSのtext-orientationプロパティにもギャップがあります。これはFirefoxのみでサポートされています。-webkitのベンダープリフィックスを使用している場合、Safariはバグのサポートを受けています。垂直に文字をセンタリングするときに問題があります。

コメント:

  • 縦書き中の文字の正立横転指定(text-orientation)は効かないRSがまだ多い。また、関連してまだUnicodeの標準的な縦書き時の文字の向きの基準に準拠できていないRSもあり、表示するRS次第で文字の向きが変わってしまうような現象も起きている。Kindleでのキリル文字、ギリシャ文字などがこれに相当する。
  • 1桁の英数字を正立で表示させたい場合に一般的に行われているTIPSとして「全角文字に打ち替える」というものはある。ただ困るのは必ずしも全角文字があるわけではない記号類なので早めのギャップ修正が望まれる。
  • EPUB制作では現状text-orientationがアテにできないため、代替としてtext-combine-uprightを使うということが行われている。

4.2.3 Tate-chu-yoko(縦中横)

The CSS text-combine-upright property works with the all value in all major browsers, although for Edge you need to use the proprietary property -ms-text-combine-horizontal.
With the digits value, it is only supported by Edge (with it’s proprietary property name), but Edge stretches single digits to fit the width of the (vertical) line. Tests:
   ↓
text-combine-upright:allは全てのメジャーなブラウザで動作しますが、Edgeではベンダープリフィックス付きの-ms-text-combine-horizontalを使う必要があります。
text-combine-upright:’digits’(指定テキスト内の何桁の数字までを縦中横表示するかを指定する自動縦中横の指定)は現在Edgeで(ベンダープリフィックス付きで)のみサポートされていますが、Edgeは数字の横幅を縦組みの行の横幅に引き延ばして表示してしまいます。

コメント:

  • 縦中横は動作する環境がほとんどだと思われるが、text-combineのみをサポートしていてtext-combine-upright(こちらが最新のプロパティ)のサポートが遅れているRSはあり、またまだベンダープリフィックスが必要なRSもある。
  • 縦中横の際の字形変化の挙動に関しても統一はされておらず、何桁あっても変形させて1emに入れようとするもの(これを1桁英数字の場合にも適用してしまうのがEdge)、変形はせずに横書きで表示し、文字数が多すぎると隣の行に重なる実装をしているものの2種に大別される。
  • 一部RSではフォント内のグリフ情報を呼び出して等幅3分字形、等幅4分字形などで表示するような実装も見られるようだ。

4.2.4 Lists(リスト)

 3.4で既出なので割愛

4.2.5 Table cells(表のセル)

If you place the writing-mode property with a value of vertical-rl on an individual table cell, you would expect the text in that cell to be displayed vertically. This works as expected in Edge, Internet Explorer and Gecko browsers. Blink and Webkit browsers, on the other hand, leave the text horizontal but rotate the characters to the left. Note, also, by the way that you have to set the height of the cell in these browsers for a span to be displayed vertically.
   ↓
表組みの個々のセルに対してwriting-mode:vertical-rlの指定をすると、そのセル内のテキストが縦組みで表示されます。これはEdge、Internet Explorer、およびGeckoのブラウザ(Firefox)では正常に動作します。一方、Blink(Chrome)とWebkit(Safari)のブラウザでは、テキストは水平のままで文字を左に回転させて表示してしまいます。いずれにせよ正しく表示させるために、これらのブラウザでセルの高さを設定する必要があることにも注意してください。

コメント:

  • 表組みの項目行のみ縦組みというのはかなり目にはするので実現できるようになることを期待したい。

4.2.6 Logical properties(論理的プロパティ指定)

A great deal of time and confusion can be saved by using ‘logical’ properties, rather than right, left, top and bottom, for things such as alignment.
CSS is developing the necessary keywords in the Logical Properties specification, which at the time of writing is still an editor’s draft. Some of the properties described there, however, are already supported by browsers.
Unfortunately, Microsoft Edge still doesn’t support the start and end values for text-align
   ↓
たとえば(padding、marginなどの)方向の指定のために上下左右ではなく「論理的」な値で指定することで、混乱を避け時間を大幅に削減できます。
CSSはLogical Properties仕様で論理的な指定のための値を決めていますが、これはまだ現在はエディターズドラフトの段階です。ただし、そこに記述されているプロパティの一部は、すでにブラウザでサポートされています。
残念ながら、Microsoft Edgeではtext-alignのstartとendの指定値はまだサポートされていません。

4.3 Notes, footnotes, etc.(注釈、脚注ほか)

Needs Research

Does your script have special requirements for notes, footnotes, endnotes or other necessary annotations of this kind in the way needed for your culture?
   ↓
あなたの言語には注釈、脚注、後注などに対して何らかの特別な文化的要望がありますか?

コメント:

  • 注に関する項目。日本語書籍での注の表示のひとつに「割注」があり、これはJLREQにも記述があるのだが、アルゴリズム的にはWebやEPUBでの実現は難しそう。個人的意見としては電子では必要ないのではないかと思う。紙の本の割注も決して読みやすいわけではない。また、これは項目的には3の「Lines and Paragraphs」の中に項目を立てるべきかもしれない。
  • EPUBで画面を分割して脚注を表示するのはコンテンツによってはニーズがありそうだがまだ一般的なブラウザでの実現はできていない。また、epub:type=”footnote”の指定による脚注のポップアップ表示は現在iBooksおよびKoboのiOS版、EdgeのEPUB表示(脚注のテキストが同一のXHTML内にある場合のみ)で実現できている。

4.4 Page numbering, running headers, etc.(ノンブル、柱文字その他)

Needs Research

Are there special conventions for page numbering, or the way that running headers and the like are handled?
   ↓
ノンブルや柱文字の扱いに関して特別な規則がありますか?

コメント:

  • ノンブルや柱文字に関する項目。現状EPUBではOPFに記述された書名が柱に表示される実装を行っているRSが多いが、一部のRSではXHTMLのTITLEタグに記述されたテキストを表示するようだ。いずれにせよRS側の独自処理であり、制作側がCSS等で指定できるわけではない。

4.5 Other page layout & pagination features(その他ページレイアウトと改ページ機能に関するもの)

Needs Research

Some cultures define page areas and page progression direction very differently from those in the West (eg. kihon hanmen in Japanese). Is this an issue for you? Are widows and orphans relevant? In what order do pages progress, RTL or LTR?
   ↓
いくつかの文化では、ページ領域とページ進行方向を西洋のそれとは非常に異なる形で定義しています(例:日本語の基本版面)。ここに何かしらの問題はありますか? ウィドウ、オーファン(孤立行)などについてはどうですか? ページ進行方向は右→左ですか、あるいは左→右でしょうか?

コメント:

  • EPUBでのページ番号に関する話として、実ページリンクの話題がある。これは電子教科書方面でのニーズから策定された規格のようで、リフロー型EPUBのXHTMLの中に紙の本での各ページ開始位置をタグとして記述しておき、RS側の処理でページ番号を表示させるものだ。iBooksでかなり前から使えるほか(参照)、最近はAmazon Kindleもパブリッシングガイドラインで対応を表明した(サーバ側処理が必要なため表示未確認)。専門書などでは底本内にとても多くのページ番号に基づく参照情報があり、その中には外部の他の本に対する参照情報も当然多数含まれる。一方でEPUBには現状外部の他のEPUBパッケージ内の特定の箇所にリンクを貼る手段がない。このため、おそらく専門書のリフローでの電子化を今後進めていくには実ページリンクを広く使っていく必要が出てくるのではないかと考えている(あるいはフィックス型で電子化するかだが・・・)。

5. Other(その他)

5.1 Culture-specific features(文化特有の機能)

Needs Research

Sometimes a script or language does things that are not common outside of its sphere of influence. This is a loose bag of additional items that weren’t previously mentioned. This section may also be relevant for observations related to locale formats (such as number, date, currency, format support).
   ↓
言語は時に、その影響の圏外では通用しないことをすることもあります。これは以前には言及されていなかった追加項目に対応するための項目です。このセクションは、ロケールフォーマット(番号、日付、通貨、規格のサポートなど)に関連する項目にも関係します。

5.2 What else?(何か他にありますか?)

Needs Research

There are many other CSS modules which may need review for script-specific requirements, not to mention the SVG, HTML, Speech, MathML and other specifications. What else is likely to cause problems for worldwide deployment of the Web, and what requirements need to be addressed to make the Web function well locally?
   ↓
SVG、HTML、Speech、MathML、その他の仕様はもちろんのこと、スクリプト固有の要件のレビューが必要な他の多くのCSSモジュールがあります。Webの世界的な展開にあたって何かしらの問題が発生する可能性がある要素は他にありますか? Webの機能をローカルでうまく機能させるためにはどのような要件を解決する必要がありますか?

 以上です。推測して用語を補足せざるを得なかった箇所もありますし、自分的にスコープ外の部分は流してもいます。全文の忠実な翻訳ではないことにご留意ください。意図の取り違え、単純な間違いなどありましたらご指摘いただけると助かります。

(2018.10.19)

 4.4 に関して肩文字→柱文字に訳語を修正しました。

(2018.11.5)

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

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