　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）