w3c/jlreq

Text Layout Requirements for Japanese

Japanese Language Enablement (jlreq)（JLReq 日本語組版要件）

This is the place to explore gaps in support for the Japanese script on the Web and in eBooks, and to document requirements.

日本語をウェブや eBook で利用可能にするためのギャップ分析を行い、また要件を文書化するための場所です。

We aim to address the problem that local users don't know how to tell the W3C what problems exist for support of their language on the Web, and the W3C doesn't know how to contact people who can help when questions arise.

言語の利用者がウェブ上でその言語を利用できるようになるにはどのような問題があるかを W3C に伝える方法を知らないこと、また W3C で疑問が出たときに誰に聴けばよいかわからないという問題があり、それを解決しようとしています。

Topics for discussion are suggested by the gap-analysis template. This work feeds into the language matrix which provides a heat-map for language issues on the Web.

論点はギャップ分析のテンプレートにまとめられています。議論の結果はウェブでの言語に関する問題についてのヒートマップである言語マトリクスにも反映されます。

Key links (重要なリンク)

GitHub repo • Discussion threads (議論のリスト) • Issue tracker (論点追跡リスト) (with jlreq filter、jlreqでのフィルター) • Charter (活動憲章)

---

Help wanted! (助力募集中！)

We're looking for information about this writing system. Follow the link for specific questions.

この言語についての情報提供をお待ちしています。以下のリンクから質問を一覧できます。

Japanese (日本語についてのリスト)

---

Documents （文書）

• Japanese Gap Analysis （日本語ギャップ分析） • Editor's draft (編集草案) • Latest commits (直近の更新)
• Requirements for Japanese Text Layout (日本語組版処理の要件) • Editor's draft (編集草案) • Latest commits (直近の更新)
• Rules for Simple Placement of Japanese Ruby (ルビの簡便な配置ルール) • Editor's draft (編集草案) • Latest commits (直近の更新)
• Requirements for Japanese Digital Text Layout (日本語デジタルテキストの組版要件) • draft Table of Contents (目次案)

Discussions (議論項目)

• Japanese • Questions (質問) • Gap reports (ギャップ分析) • Other (その他) • Spec issues (仕様書についての議論)

Related documents (関連文書)

• Current Status of Japanese Typography Using Web Technologies
• Ready-made Counter Styles

Feedback (意見の提供)

Please use the GitHub issue list to report issues for language support, for discussions, and to send feedback about documents. (Learn how GitHub issues work.)

言語の機能についての問題報告、議論、文書への意見については、GitHub issue にお願いします。(GitHub issues の利用についての文書を参考ください。)

Note that the public-i18n-japanese mailing list is used to send notification digests & meeting minutes. It is not for technical discussion. (Some technical discussion takes place on that list for the Japanese language enablement, but it is strongly preferred to use GitHub issues whenever possible.)

注: public-i18n-japanese メールリストは要約通知や議事録の送信先です。技術的議論のためではありません。（多少の日本語組版に関する技術的議論が行われることはありますが、GitHub issuesを利用することが強く推奨されます。）

You may raise issues in Japanese, however any substantive discussions should be summarised in English at some point, so that non-Japanese speakers can follow the rationale and contribute comments.

GitHub issues での議論は日本語で構いません。ただし重要な議論が日本語で行われた場合は、日本語の判らないメンバーが議論を理解しコメントできるよう、適当な時点で英語での要約が必要です。

Participate (参加する方法)

You can participate in the work at various levels. In order of increasing commitment, these include List subscriber, Participant, Editor, and Chair. Explore the options.

この活動にはいくつかの立場で参加可能です。活動を活発にするために、リスト受信者、参加者、編者、議長の分類があります。参加方法についても参考にしてください。

To just follow the work: Rather than 'Watch' this repository, subscribe to the public-i18n-japanese mailing list. That list is notified (no more than once a day, and in digest form), about changes to issues in this repository, but also about other W3C Working Group issues related to the Japanese writing systems.

If you prefer to receive notifications of all discussions for Chinese, Japanese, and Korean languages, subscribe to the public-i18n-cjk mailing list.

活動を追跡だけする場合: このレポジトリを 'Watch' するよりも、public-i18n-japanese メーリングリストに参加してください。このリストには、このレポジトリにある issue の更新のみでなく、他の W3C Working Group の日本語に関する issue についても送信されます (最大一日一度、ダイジェスト形式です)。

CJK(**語・日本語・韓国語)すべてについての通知を受け取りたい場合は、public-i18n-cjkメーリングリストに登録してください。

To contribute content: All contributors should read and agree with CONTRIBUTING.md.

文書に貢献するには: 全ての参加者は CONTRIBUTING.md を読み、それに同意する必要があります。

To become a participant, editor, or chair: contact Richard Ishida or 木田泰夫 (Yasuo Kida). We welcome participation requests.

参加者、編者、議長に興味がある方: Richard Ishida か 木田泰夫 (Yasuo Kida) に連絡してください。参加の申し込みを歓迎します。

To get an idea about what's involved, see Get involved with Language Enablement!.

どのような活動を行っているかについての詳細は、言語を利用可能にする活動に参加する！を参照ください。

Contacts（連絡先）

• Chair (議長): 木田泰夫 (Yasuo Kida)
• W3C staff: 下農淳司 (Atsushi Shimono), Richard Ishida
• Group participants (グループ参加者一覧)

Links to practical information (実用的な情報へのリンク)

• public-i18n-japanese mail archive (メールリストアーカイブ)
• public-i18n-cjk mail archive (メールリストアーカイブ)
• Writing i18n tests (国際化関連テストを作成するには)
• Practical tips for task forces (タスクフォースの実用的 tips) (See also the github and editorial guidelines below)
• Meeting info (定例会議情報)

Links to background information（W3C 国際化関連のリンク）

The following information describes work going on at the W3C to support languages on the Web.

下は W3C が web の国際化のために行なっている活動へのリンクです。

• Language support heatmap (matrix)
• Analysing support for text layout on the Web
• Overview of language enablement work in progress
• Get involved with Language Enablement
• Setting up a Gap Analysis Project
• Internationalization Sponsorship Program

Links for editors（ドキュメント編集のためのリンク）

If you end up creating a document, you should be familiar with and use the following:

W3C の文書を作成するために知っておくべきこと：

• Github guidelines for working with i18n documents
• Editorial guidelines for working with i18n documents

jlreq's Issues

Wrong Japanese section title §3.3.2

"3.3.2 Choice of Base Characters to be Annotated by Ruby ルビをどのような言葉に，どのように付けるかは各種の方法がある．"
https://w3c.github.io/jlreq/#choice-of-base-characters-to-be-annotated-by-ruby

https://github.com/w3c/jlreq/blob/314dd6a60d45b82b2ec400172524750da6451123/index.html#L3582-L3585

It seems a bug on English-Japanese merging. The original Japanese section title for §3.3.2 was "ルビの付け方".

Fig 43 (img_ad1_12) English version has Japanese character in its description

from https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0055.html

Fig 43 (https://w3c.github.io/jlreq/#fig_ad1_12) English version has Japanese character in its description.
'ポ' -> pt

Fig 170 (img2_7_1) contains wrong chemical formula

from https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0055.html

Fig 170 (https://w3c.github.io/jlreq/#fig2_7_1) contains wrong chemical formula in the bottom line. Both English and Japanese.
'OP' -> 'SO'

Inconsistency between English and Japanese version in section 4.4.2 note 1 and 2

link: note 1, note 2

Japanese text has links to example as "（Figure 285及びFigure 294）" (note 1) or "（Figure 286）" (note 2), but no such text in English version.

3.3.5 et al: No mention of Ruby and Kenten baseline positioning in the positioning description

In e.g. horizontal, Ruby and Kenten CJK embox bottoms should be positioned at the embox tops of the base text. This is shown in the illustrations, but only the left-right positioning (in the case of horizontal) is mentioned in the text. It is possible that implementors would be unclear about which baseline to align and where.

Typo in "There are to ways to carry out this." -> are two ways

Section 3.3.8, note 1.

Re: Merging en & ja jlreq glossary

I thought it would be easier to handle the remaining work related to this by opening an issue.

Fig. 4.9 heading indent mistake

[raised by Cedric Simon, 2016-03-18]

I stumbled across the following document https://www.w3.org/TR/jlreq/#processing_of_runin_heading and spotted a tiny mistake (I think).

The fig. 4.9 describes the third heading being indented by "9pt x 6" instead of "9pt x 8" as explained in the note (1) above:

"[...] For example, when the character size of main text is 9 point, the indent of a large heading is 9 point by 4 times, medium-heading is 9 point by 6 times, small-heading is 9 point by 8 times."

misprints in figures in section 4

from https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0017.html

figures 4.7 (191) https://w3c.github.io/jlreq/#fig_ad1_16, 4.51 (235), 4.52 (236) have misprints in their texts. Figures of both English and Japanese version need to be fixed.
Note, figure numbers in brackets are in the current ED version.

space between head and page number

It looks like 2.6.1 c "when arranging running heads and page numbers together on the same horizontal line, the space between the running head and the page number should be double or one and a half times the character size of the running head" contradicts Fig. 2.48(f) and Fig. 2.49(b), where the heads are centered. The "double or one and a half" rule should apply only when both the head and the page number are similarly aligned (e.g. both are left-aligned on the left page).

Where does underline go relative to ruby?

It would be useful if jlreq provided some guidance about where underlines should go if there is some ruby associated with base text that is underlined. This was discussed at https://www.w3.org/Mail/flatten/index?subject=Underline+position+for+Japanese+text+with+ruby&list=www-style

My understanding is that the consensus was that the underline should run between base characters and ruby.

However, there was an open question about how to fit it in without overlapping either the base or the ruby.

If you have contributions to make about this, please add them here, rather than in the original email thread.

Fig. 3.83 doesn't match its description

From: Kobayashi Toshi [email protected]
Date: Fri, Jan 30, 2015 at 10:08 AM

Xidorn Quan さん wrote

The text before Fig. 3.83 says:

There is another variation that allows ruby text to overhang any
ideographic characters (cl-19), hiragana (cl-15) or katakana (cl-16) up to
the full-width size of a ruby character (see Fig. 3.83)

However, in the figure, the ruby text only overhang up to half-width size
of a ruby character, even if the description says it can overhang more.
(See the "懐(ふところ)" in the figure)

I guess either the figure or the description should be changed.

The change of "Fig. 3.83" is unnecessary.

"full-width" of "note 3" is a mistake. "full-width" of "note 3" is "h
alf em".

How to do bunsetu-separated rendering

Makoto Murata is working on Accessibility Requirements on Japanese Typography.

He says the following about adding space between bunsetsu (word-like phrases in Japanese - see https://en.wikipedia.org/wiki/Japanese_grammar#Sentences,_phrases_and_words):

This is meant to help students with dyslexia. When Japan creates the next set of DAISY textbooks, we hope to use a single EPUB3 document for general-ruby/para-ruby/no-ruby rendering (総ルビ/パラルビ/ルビ無し）as well as space-separated-bunsetu rendering and normal-rendering (分かち書き/普通の表示). Moreover, since DAISY textbooks are for students, 分かち書き has to be perfect (the morphological analysis may provide an incorrect result).

I can also imagine that Mainland China and Taiwan also have students with dyslexia and that the same mechanism might be useful.

Normal Japanese/Chinese text does not, in itself, indicate break opportunities for bunsetsu separation. It will be necessary to provide a mechanism that allows bunsetsu separation to be applied to normal text.

I have a number of questions around the topic:

1. Murata-san, is bunsetsu-spacing a recognised and widely used technique in existing text? Or is this a new idea?

2. Will this mechanism will be different from the way line-breaking occurs in Japanese, since the grammatical particles are considered part of the bunsetsu unit.

3. Would we be looking at a new CSS property? Styling seems appropriate, since the intent appears to be to use the text as normal elsewhere, and to apply the accessibility changes to existing text (ruling out the possible use of spaces, zero-width or otherwise).

4. Given a new property for bunsetsu spacing, will it be necessary to change default line-breaking and justification behaviour, since presumably (?) the gaps will count as word separators.

Wrong description in section 3.3.8 note 3

https://w3c.github.io/jlreq/#h-note-127
section 3.3.8 note 3 says

There is another variation that allows ruby text to overhang any ideographic characters (cl-19), hiragana (cl-15) or katakana (cl-16) up to the full-width size of a ruby character (see Figure 139).

'up to the full-width size of a ruby character' shall be half-width (Japanese version is correct).

§3.9.2の分類名称Math symbols (cl-17)が適当でないと思います

§3.9.2の分類cl-17の英文名称は“Math symbols”となっていますが，例えば“Math relations”くらいがよいのではないかと思います．
“Math symbols”ではcl-18のMath operatorsを名称として排除できていないように見えてしまいます．

3.3.8 "c", 4.5.2, et al: Change "spaces" to "spacing".

The phrase "half-em spaces" is confusing, in that it implies extra characters being added to the model, not simply creating space in the layout of the existing text. I would argue that implementing mojikumi aki with actual "spaces" would violate the content vs presentation rules.

There are approximately 98 instances of the word "spaces" in the document, most of those are referring to mojikumi aki.

English text for '通用名称' in Appendix A tables

(Not adding errata label, rather rising a question to editors)
In Appendix A Character Classes tables, Japanese text '通用名称' is translated as 'Common name', but these seem actually to be Japanese name.
If this is correct, is it better to switch to 'Japanese name' for English tables?

Specifying the vertical positioning of the kihon-hanmen

From: Kobayashi Toshi [email protected]
Date: Tue, 21 Jan 2014 17:25:44 +0900

MURATA Makoto　様

　　　小林敏です

MURATA Makoto さん wrote

以下の質問ですが，とりあえず日本語でお答えいたします．

これは紙に印刷し，製本する作業とも関連してきます．

日本では，普通の紙の厚さの場合，一般に16ページ単位で折りたた
みます（3回折ることになります，折ったものは折丁（signature or
section）または折本といいます）．そして，印刷版の作成では，折
った場合にページが連続するように各ページを配置します（面付（im
position or image assembly）といいます）．

この際に，各ページのページの配置については，縦組と横組ともに
同じ方法をとります（ページそのものの上下関係は逆）．その結果
として，折り畳んだものについて，横組では上下を反対にします
（縦組と比べて）．それは，横組と縦組では本の開く方向が逆にな
るからです．

折り方を示した図を参考までに，私が以前使っていた講義用資料か
らの抜粋ですが，PDFを添付します．
　添付ファイル名：16ページの折り方 .pdf

このように折った結果で見ると，横組では，折り畳んだ袋状の部分が天側にきます．縦組では袋状の部分が地になります．

そこで，版面位置を決めるのに，この袋状の部分からの方が確実で
あり，縦組と横組で指定する方向が違ってくるのです．

ただし，見た目を重視するならば，縦組でも天からの指定の方がよ
いという考え方もあります．そのように指定されていた場合は，現
場では逆算するわけです．

この現場での逆算を避け，最初から確実な方法ということで，日本
では，縦組では，地の方から指定する，横組では天の方から指定す
るという考え方がでているのです．

要約すると，日本では，折丁（signature）にした場合，袋状にな
るのは縦組では地側になり（横組では天側），こちら側から基本版
面の位置を指定した方が確実で望ましい，ということです．

以上です．

みなさん、

James Clarkからの質問です。

村田 真

---------- Forwarded message ----------
From: James Clark [email protected]
Date: 2014/1/21
Subject: Specifying the vertical positioning of the kihon-hanmen
To: "CJK discussion ([email protected])" [email protected]

Before I ask my question, I just wanted to say thank you to everybody
involved in producing the "Requirements for Japanese Text Layout" note.
It is an extraordinarily interesting and helpful document.

The note says [1] that the vertical position of the kihon-hanmen relative
to the trim size is either centered or specified using the head (ie
top-margin), for horizontal mode, or foot (ie bottom margin) for vertical
writing mode.

I am puzzled by the vertical writing mode case. Given that the inline
progression direction is top-to-bottom, what is the logic for specifying
the bottom rather than the top margin in this case? Do you specify the
bottom margin even if you have horizontal rather than vertical running
heads/foots?

James

[1] http://www.w3.org/TR/jlreq/#procedure_for_defining_the_kihonhanmen at

Praying for the victims of the Japan Tohoku earthquake

Makoto

Fig. 3.63 nakatsuki-ruby and katatsuki-ruby

The top labels of Fig. 3.63 are wrong: nakatsuki-ruby and nakatsuki-ruby. This should be nakatsuki-ruby and katatsuki-ruby.

English wording in ruby section: change "ruby letter(s)" to "ruby character(s)"; change "go over" to "overhang"

related to fixes made for #15

jlreq pages links actually go to alreq

https://github.com/w3c/jlreq/blob/gh-pages/gap-analysis/index.html or https://w3c.github.io/jlreq/gap-analysis/ have links to the alreq instead of jlreq project.

'Appendix G' is shown as bare text in section 4.1.1 note 7

link: section 4.1.1 note 7
In English version of this note, an word 'Appendix' is shown as bare text: '"column spanning heading" in accordance with the terminology in Appendix G.'
Is it better to make this as link to the Appendix?

3.3.8 second paragraph: Fix English for inter-character spacing of ruby

Text says:

The following are the general rules (see Figure 135 and Figure 136). They were established especially in order to avoid misreading and to maintain the beauty of the layout. Noted that the detailed value of spaces between characters for cases of ruby letters hanging over the base characters is described in § B. Spacing between Characters 文字間の空き量 as Table 1 in accordance with § 3.9 About Character Classes 文字クラスについて .

the "spaces between characters" phrase is actually talking about "inter-character spacing".

§Aの通用名称“垂直”の字形，UCSコード，名称について

§A 文字クラス一において，“垂直”が次のように分類されています．
cl-17：

⊥,22A5,UP TACK,垂直

cl-27：

⊥,22A5,UP TACK,垂直,proportionally-spaced プロポーショナル

これらは，UCSコードとName UCSの組と通用名称がマッチしていないと思います．
通用名称“垂直”にマッチするのは次のものだと思います．

⟂,27C2,PERPENDICULAR

3.3.8, "f" English and Japanese do not seem to match

The wording of "f" says:

When the adjacent character is one of the closing brackets (cl-02), the ruby text may go over the base characters up to the full-width size of a ruby character. Note that the overhang must not go beyond the closing bracket itself.

後ろにくる終わり括弧類（cl-02）には，最大でルビ文字サイズの全角までルビ文字を掛けてもよい．この場合，終わり括弧類の後ろの空き量に掛けてはならない．

So, the Japanese says you cannot overhang the Aki, but the English says you cannot overhang the glyph? I think the Japanese in this case is incorrect, and the English could be made more clear.

Set editors of current editors draft to one of 2nd ed.

from https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0165.html

We agreed that we are updating this JLReq document to fix errata of 2nd edition, but not to make a new edition.
So, set editors of 2nd edition as 'Editors', and 1st edition as 'Former editors', from list in current published version.

§3.7.4 note 1の和文への未翻訳部分

§3.7.4のnote 1の後半（Also, the handling of...）に対応する和文が存在しないようです．

Do emphasis marks swap sides when JA is embedded in ZH?

This arises from https://www.w3.org/Mail/flatten/index?subject=Default+UA+stylesheet+for+emphasis+marks&list=www-style

Emphasis marks in horizontal japanese text go above the text, but in horizontal Chinese text they go below. What happens when japanese is embedded in chinese text, or vice versa?

Links to each requirement

It is not easy to reference specific requirements in JLREQ. Some requirements are represented by sub- or sub-sub-sections, while others are represented by itemized lists or sentences. Ideally, each requirement should be named and referencable by a fragment identifier.

But embedding names and anchors in JLREQ requires a big effort. One work around is to use EPUB publications (available as EPUB in GitHub epub-samples) and use EPUB canonical fragment identifiers. Then, everything becomes URI-referencable.

§3.7.4 note 2の記述に誤りがあります

§3.7.4 note 2の記述中，次の誤りがありました．
誤：and GREEK CAPITAL LETTER SIGMA "Σ"
正：and N-ARY SUMMATION "∑"

対応する和文部分も次のようになると思われます．
誤：直和記号（シグマ）なども
正：総和記号なども

3.3.8 "b" Note: English needs editing

Because ruby letter may go over the base characters and overhang to adjacent hiragana (cl-15) etc. up to the full-width size of a ruby letter, ruby letters from before and from after a base hiragana (cl-15) may be consecutive without space like Figure 137. Such cases are not recommended because of the possibility of misreading. It is recommended to insert one em space between former ruby letters and latter ruby letters. There are two ways to carry out this. One is to reduce the maximum size of overhang to the hiragana (cl-15) base character of before ruby letter and after ruby letter, and the other is to reduce the maximum size of overhang to the hiragana (cl-15) base character of after ruby letter. The latter case is carried over to differently set the limit of overhang from before and from after. Firstly, set the ruby letters from before as usual, i.e. ruby letter may overhang up to the full-width size of a ruby letter. Secondly, ruby letter from after shall be set with one em space before, namely, the ruby letter from after can not go over the base hiragana (cl-15) letter in between. Hence, appropriate size space shall be inserted between base characters themselves (see Figure 138).

This is a bit hard to understand. I volunteer to edit...

span class=index in japanese text is used?

While editing and updating for registered errata, I found there are many(?) span element with class=index and 8 character id which are mostly surrounding links to references etc. These are only in Japanese version of old format but not in English version. Also there is no internal link for these using id.
Are these used for document, or just leftovers from some editing software (or conversion software)?

Just filing as memo (or question for next F2F), not adding errata label.

How are underlines positioned in Japanese text?

CSS and browser implementers are looking for information about how to position underlines for various scripts, including Japanese scripts. Can we provide them with the information they need (and add it to the layout requirements doc)? See w3c/csswg-drafts#459 (comment)

Note below Fig 136: English version is hard to understand

Because ruby letter may go over the base characters and overhang to adjacent hiragana (cl-15) etc. up to the full-width size of a ruby letter, ruby letters from before and from after a base hiragana (cl-15) may be consecutive without space like Figure 137. Such cases are not recommended because of the possibility of misreading. It is recommended to insert one em space between former ruby letters and latter ruby letters. There are two ways to carry out this. One is to reduce the maximum size of overhang to the hiragana (cl-15) base character of before ruby letter and after ruby letter, and the other is to reduce the maximum size of overhang to the hiragana (cl-15) base character of after ruby letter. The latter case is carried over to differently set the limit of overhang from before and from after. Firstly, set the ruby letters from before as usual, i.e. ruby letter may overhang up to the full-width size of a ruby letter. Secondly, ruby letter from after shall be set with one em space before, namely, the ruby letter from after can not go over the base hiragana (cl-15) letter in between. Hence, appropriate size space shall be inserted between base characters themselves (see Figure 138).

This paragraph could use some editing. I volunteer...

Combining ruby and emphasis marks

There's a discussion at

https://www.w3.org/Mail/flatten/index?subject=Emphasis+mark+and+ruby&list=www-style

about expected behaviour when both ruby and emphasis marks are applied to the same piece of text. I think it would be useful to add some clear requirements to jlreq.

As i understand it, the conclusions were as follows:

[1] If emphasis marks are applied to a range of base text that includes ruby, the emphasis marks should by default be placed as close as possible to to the base text, resulting in something like the following:

[2] If text emphasis marks appear over a gap in a sequence of ruby, the emphasis mark should be at the same distance from the base as the adjacent emphasis marks, something like this:

[3] Occasionally a content author will want to hide either the emphasis marks or, less likely, the ruby text, when stacking ruby and marks is difficult, due to the narrow leading or the implementation costs. [The CSS spec shows you how to do that via styling.]

If anyone has additional comments to add, for or against this, please add them to this github issue, and not to the original mail thread.

Japanese translation of "Former editors"

The Japanese version of "former editors" is currently "編者（第２版）". IMHO it should be "元編者" or something similar.

See also c019201#r33461366

Missing condition in section 3.3.8, first "f."

Section 3.3.8, first set of a., b., c., etc.

f. When the adjacent character is one of the closing brackets (cl-02), the ruby text may...
...
h. Also, when the adjacent character is one of the opening brackets (cl-01) before the ruby object, the ruby text may...

f. fails to say this is only when the bracket is after the ruby object h. does indicate this corresponding restriction (before the ruby object)

So, at the very least, insert "after the ruby object" after "(cl-02)" in f.

Even better, I think that f, g and h can be combined:

When the preceding character is an opening bracket, or when the following character is a closing bracket, a comma or a full stop, the ruby text may go over these adjacent characters, up to the full-width size of a ruby character. Note that the overhang must not go beyond those adjacent characters.

KATAKANA MIDDLE DOT“・”の取り扱いについて

KATAKANA MIDDLE DOT“・”は§3.1.3 b noteにおいて，cl-24，cl-25，cl-27として用いる場合が言及されていますが，このnote自体不要と思われます．

In vertical writing mode, when KATAKANA MIDDLE DOT "・" is used as a member of unit symbols (cl-25) in unit symbols, grouped numerals (cl-24), and Western characters (cl-27) in mathematical and chemical formulae, before and after KATAKANA MIDDLE DOT "・" is set solid.

なお，横組において，中点[・] (KATAKANA MIDDLE DOT)を単位記号中の文字（cl-25）として単位記号の中で使用する場合，中点[・] (KATAKANA MIDDLE DOT)を連数字中の文字（cl-24）の中で使用する場合及び欧文用文字（cl-27）を用いた数式・化学式の中で使用する場合は，[・] (KATAKANA MIDDLE DOT)の前後はベタ組にする．

これらの場面で使用するのは22C5 DOT OPERATOR“⋅”ですので，KATAKANA MIDDLE DOT“・”に関連して言及する場面ではないと思います．
積を表すドットが日本語の文書ではKATAKANA MIDDLE DOTを用いることを要求するかのようにも読めてしまうのは，要件記述として適当でないとも思います．

また，§3.7.4 d note 2にもKATAKANA MIDDLE DOTに関する言及がありますが，KATAKANA MIDDLE DOTを言及対象にするのは適当でないと思われます．

このことに関連し，§A cl-25 にある

・,30FB,KATAKANA MIDDLE DOT,中点,half-width 字幅は半角

は削除し，§A cl-18に

⋅,22C5,DOT OPERATOR

を追加する方がよいかと思います．

List style type.

In css list style type property, it is possible to specify the use of cjk-ideographic, hiragana, hiragana-iroha, katakana, and katakana-iroha as ordered list marker. However, the result of these options as I see from Chrome browser is like this:

Which have normal western dot behind each characters. As I understand, this is not a common way to write this type of list in Japanese. Should it be specified in jlreq that this sort of lists usually use the symbol "、" instead? And perhaps also need to contact various browser vendors and such for this?

Sort the glossary by one language or another

Currently, the rows in the glossary are ordered by the English sort order. We should add JavaScript to make it possible to sort by Japanese too.

[gap-analysis/tests] List existing tests made by JAGAT/XML-publishing

For first, list existing tests made for testing EPUB viewers.

Some character samples in Appendix A tables are in full-width character

(Not adding errata label, rather rising a question to editors)
In Appendix A tables, characters are shown in table as samples for rows. Some row points UCS code points in U+00XX (half width signs) but have full-width equivalent for sample, like '（' (U+FF08) in third row of Appendix A.1 cl-01 for U+0028.
Do we need to show actual representatives for UCS codepoint, or it's fine since these are just showing shape?

Note, this is the same for 2nd WG Note at 3rd April 2012.

Incorrect interpretation in 2.5.2 Line Positioning based on the Kihon-hanmen Design

The item a (the first list item) of 2.5.2 Line Positioning based on the Kihon-hanmen Design says:

The former approach is used, whenever possible, to achieve inter-character spacing before and after illustrations or tables constant.

but as in the following figure 2.41, this is talking about "the same amount of gaps between text and illustrations."

Suggest to change "inter-character spacing" to "inter-object spacing", or just "spacing".

∪∩∧∨⊕⊗及び⊖の文字クラス分類

∧（2227 LOGICAL AND）∨（2228 LOGICAL OR）∩（2229 INTERSECTION）∪（222A UNION）⊕（2295 CIRCLED PLUS）⊖（2296 CIRCLED MINUS）⊗（2297 CIRCLED TIMES）はcl-18に分類されるべきだと思います．
現在，§Aおよび§3.9.2では，∧∨∩∪⊕⊗はcl-17に⊖はcl-19に（またcl-27にも）それぞれ分類するとされています．

∧∨∪∩⊕⊗に関しては，現在，§3.9.2 q note 2に次のように記述されています．

because these symbols are traditionally considered to behave in the same way as other Math symbols.

“∪∩∧∨⊕⊗”は，これまでの組版上の慣習的処理から等号類に含めている．

また，対応する部分は和文に未翻訳だと思われますが，§3.9.2 q note 2内で次のようにも言及されています．

From mathematical view point, "∪∩∧∨⊕⊗" are included in math operators (cl-18)...

∧∨∪∩⊕⊗を等号類として扱う処理を一部で慣習的に行なわれたことが事実であったと仮定しても，改めて要件とはしない方がよいと思います．

Orientation of emphasis marks in sideways text

CSS expects that emphasis marks such as sesame remain upright in vertically set text, ie. when using writing-mode:vertical-x.

What is the appropriate orientation when one of the sideways values is used? Should the marks retain the orientation they would have had in horizontal text, or be rotated so that they are vertical?

(This is likely to be a very edge case, because the sideways values are intended for scripts that are normally horizontal – CJK text is normally expected to use a vertical-x value.)

(See previous discussion at https://www.w3.org/Mail/flatten/index?subject=Orientation+of+emphasis+marks+for+sideways+text&list=www-style)

character tables has omitted letters

from https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0055.html

table_en[2-7] has omitted letters in 'cl-23 jukugo-ruby character comple' ('x' is missing)

Where should we store the image source files?

For background, see: https://lists.w3.org/Archives/Public/public-jlreq-admin/2019AprJun/0097.html

A lot of images source files are in .ai and .indd formats, we should figure out how to store them.

I'm not aware of any established practice in the W3C community. One possible approach is to track them with git-lfs (perhaps in a separate repo, to maintain a relatively fast cloning experience for the main jlreq repo).

Another possible way is using a file hosting service. The Publishing BG uses Google Drive (mostly for sharing documents, tho).

Just my 2 cents...

PS: IIRC most .ai and .indd files are under 2 megabytes, which doesn't seem to be that large.

[Editorial] wrong lines introduced by combining (and moving to respec) process

not all could be editorial, but putting all here to list ones introduced by combining (and moving to respec?) process at 2019/May. (sorry that this is not from detailed comparison, but just skim through...)
Note: have not checked link targets; not including inconsistent applied links to terms references; WIP - for sections 1-3 as for now

• Editors: 'Hiroyuki Chiba' is in both 1st and 2nd for before, marked as 2nd for after
• Editors: 'Tatsuo Kobayashi' is as 'JustSystems' for 1st and 'Invited Expert' for 2nd for before, in both 1st and 2nd as 'JustSystems' for after
• Editors: 'Felix Sasaki' is as 'University of Applied Sciences Potsdam' for 1st and 'DFKI GmbH' for 2nd for before, in both 1st and 2nd as 'DFKI GmbH' for after (Kanji name 'Felix 佐々木' is ok to be dropped?)
• section A.28 title has right angle bracket at the first character of Japanese text 'Warichu opening brackets (cl-28) >割注始め括弧類（cl-28）'
• section 2.2.4 note 1, section 2.2.5(a) note 1, section 3.2.5 note 1 : link in English text does not have section mark
• section 2.6.3(a), section 3.1.3(a) note 1, section 3.1.3(b) text (and many more??) : has term reference link with 'termref2nd' not 'termref' (both English and Japanese)
• section 3.3.5 paragraph 2: Japanese text is included into figure part
• section 3.3.7 paragraph 2, section 3.3.7 notes 2 and 3, section 3.4.2 note 2: a link to appendix in English text are linked with section mark
• Appendix F.4 paragraph 4 does not have its-locale-filter-list attribute

remove unrequired U+200B-s

sample from line 2246, this line has U+200B as below.

始め括弧類，終わり括弧類，読点類，句点類及び<200b>中点類が<200b>連続する<200b>場合の<200b>配置方法

are these really required for document? or just inserted by accident?
@kidayasuo do you have any information on their history?

用語集が読みづらいです。

日本語での仕様作成ありがとうございます。

用語集
ものすごく些細なことで申し訳ございませんが、
用語集のテーブルの「用語」「よみ」の列幅が狭くなっており、読みづらくなっています。
もし、可能でしたら幅の調整を行っていただけたらと思います。
よろしくお願いします。