Clreq Editors' Call

05 March 2020


Bobby, Eric, huijing, xfq

Meeting minutes

[Discuss the COVID-19 outbreak]

xfq: Have we discussed the layout of 花名册 (register of names)?

Eric: No, because the priority is not high. Punctuation is more important.

Bobby: It's also related to 示亡号 (symbol of death).

[Eric describes the layout of regiscter of names in Japanese, and jidori]

[Discuss CSS Table related issues]

Cursive & Kai





Eric: I don't think we need to mention the differences between Western cursive typefaces and Kai in clreq.

xfq: the purpose of the Western cursive fonts and Kai are different

Bobby: we have discussed this in TPAC Sapporo

xfq: Yes, in 2015.

Bobby: I discussed this with John Daggett
… tried to map the 'cursive' generic font family to Kai
… Chrome, Firefox, and Safari have implemented this now

xfq: the problem is that Chinese have multiple calligraphy styles, not just Kai

Eric: Cao (草書) is also cursive

Bobby: Agreed

Eric: So we have to decide whether we should map Kai to cursive or we need a new generic font family for Kai, like Fangsong

Bobby: if we have a registry for generic font families, I agree that we should add a new font family for Kai

xfq: Agreed.
… I think simply mapping Kai to cursive is not enough.
… it's oversimplified
… but since we don't have a registry for generic font families yet, mapping Kai to cursive is not a bad compromise.

Eric: Agreed
… remove the cursive-Kai mapping may also introduce compat issues

Bobby: 丸ゴシック (Maru Gothic) in Japanese and 圆体 (Yuan) in Chinese may be the same generic font family

xfq: https://‌github.com/‌w3c/‌csswg-drafts/‌issues/‌4606#issuecomment-591634518 also mentioned this

Bobby: back to cursive & Kai, I think the status quo is fine

Eric: we can add Kai if/when CSS introduces a registry for generic font families

Bobby: if we introduce a new generic font family for Kai, it won't map to cursive fonts if the text is Latin text, and that's a good thing
… we can bikeshed on the name of 丸ゴシック/圆体 generic font family too

Eric: but 丸ゴシック/圆体 is not one of the most commonly used typefaces (Song, Kai, Hei, Fangsong)
… Kai is used in official documents in Taiwan, and Fangsong is used in official documents in Mainland China

xfq: I will comment on the CSS issue
… what about the clreq issue?

Bobby: I will comment on the clreq issue

Eric: I think the differences between Western cursive typefaces and Kai is out of scope for clreq
… it's a CSS issue instead of a clreq issue

Go through the pull request list



xfq: I remove a translateme in § 1.1
… would you please check the TC text, Bobby?
… I'll remove the 'checkme' if there is no issue
… Richard made some suggestions
… he didn't seem to understand the implications in this paragraph
… we mentioned vertical SC and horizontal TC, but we didn't mention vertical TC

Eric: yes, we should mention vertical TC

xfq: but not in the "most publications" category

Bobby: 采用 should be 採用
… I suggest that we change 豎排 to 直排

Eric: I personally like 竖排 more, but not strong opinion, as long as it's consistent it's fine.

xfq: 直排 is used much more than 豎排 in this document

[Discussions on Chinese terms]


xfq: there's ambiguity in em dashes section
… so I submitted an issue and a pull request
… note that there's still a class="retranslateme" on TC text


xfq: I submitted a PR to remove some checkme in pinyin sections
… is capitalizing proper nouns rare, Eric?

Eric: no, it's common.

xfq: then the Chinese text needs fixing too.

Eric: I don't know why we wrote it that way.

xfq: Richard also asked a question in https://‌github.com/‌w3c/‌clreq/‌pull/‌263#issuecomment-590835009
… I don't quite understand what are the differences between 2 and 3.

Eric: I don't quite understand either
… is it because of the word spacing?

xfq: not sure
… I'll ask r12a

[ Discuss #3 in https://‌github.com/‌w3c/‌clreq/‌pull/‌263#issuecomment-590835009 ]

Eric: punctuation is optional in pinyin


xfq: this PR fixed a few minor issues in the Glossary
… and moved the csv file to others/ since we no longer use it now.
… I think we can merge this


xfq: The English translation of 疏排 is "loose setting" in https://‌w3c.github.io/‌clreq/#increased_inter_character_spacing
… and "Fixed inter-character spacing setting" in the Glossary
… in jlreq it's アキ組 in Japanese and "fixed inter-character spacing" in English
… Richard thinks we're defining "tracking"
… but I don't think so

Eric: the English translation in jlreq ("fixed inter-character spacing") is strange

xfq: 均等割り is "even inter-character spacing", which is also a little bit strange

Eric: I think "loose setting" is better than "fixed inter-character spacing"

xfq: and that's what I proposed in https://‌github.com/‌w3c/‌clreq/‌pull/‌256/‌commits/‌db6064ef3186ea4016cc5305546836bcfe91449a

Eric: unlike Japanese, Chinese almost never uses Tsumegumi (negative tracking)

Bobby: yes, especially in printed books

xfq: I can comment on the issue again
… 疏排 means the state when tracking is *greater* than zero


xfq: Huijing added an illustration
… I also added a comment: https://‌github.com/‌w3c/‌clreq/‌pull/‌234#discussion_r375840421
… huijing, would you please submit this PR in a seperate branch?

huijing: OK

xfq: it should not contain unrelated commits

Rewrite of Prohibition Rules for Line Start and Line End



xfq: I suggest that we map 基本处理 in clreq to 'normal' (instead of 'loose') in CSS line-break
… initial value of the CSS line-break property is 'auto' instead of 'normal'
… 'normal' is "the most common set of line-breaking rules"
… 'auto' may vary the restrictions based on the length of the line
… do we need a less restrictive set of line-breaking rules than 基本处理?

Eric: we can mention that the line breaking rules are styling issues, and each UA can choose or customize more restrictive or stringent rules that suit their own situation

Bobby: Taiwan has few line breaking rules

Eric: there's a "不处理" rule for that

Review corresponding CSS definition status


xfq: we have no time to discuss this issue today

huijing: we can add more detailed pages


Next telecon time

April 8 (Wednesday), 19:00-20:00 (UTC+8)

Minutes manually created (not a transcript), formatted by scribe.perl version 112 (Fri Feb 28 17:14:01 2020 UTC).