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
https://github.com/w3c/clreq/issues/264
https://github.com/w3c/csswg-drafts/issues/4606
https://github.com/w3c/csswg-drafts/issues/4425
https://github.com/w3c/csswg-drafts/issues/4566
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?
… https://github.com/w3c/clreq/issues/264
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
https://github.com/w3c/clreq/pulls
https://github.com/w3c/clreq/pull/267
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
… https://github.com/w3c/clreq/pull/267#discussion_r387009331
… 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]
https://github.com/w3c/clreq/pull/266
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
https://github.com/w3c/clreq/pull/263
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
https://github.com/w3c/clreq/pull/258
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
https://github.com/w3c/clreq/pull/256
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
… https://github.com/w3c/clreq/pull/256#issuecomment-590825209
Eric: the English translation in jlreq ("fixed inter-character spacing") is strange
… https://w3c.github.io/jlreq/#h-note-4
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
https://github.com/w3c/clreq/pull/234
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
https://github.com/w3c/clreq/issues/220
https://github.com/w3c/clreq/issues/220#issuecomment-587405830
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
https://github.com/huijing/clreq-css
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)