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.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.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.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.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.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の機能をローカルでうまく機能させるためにはどのような要件を解決する必要がありますか？