Meeting minutes
Go through the pull request list
https://
https://github.com/w3c/clreq/pull/441
[xfq introduces the PR]
xfq: Only the order is adjusted, not the content.
Eric: looks good to me
xfq: I'll merge it
https://github.com/w3c/clreq/pull/439
xfq: I only wrote the English name because I don't think there is official Chinese translation for this standard
Eric: looks good to me
xfq: I'll merge it
https://github.com/w3c/clreq/pull/438
[xfq introduces the PR]
Eric: looks good to me
… We can continue to maintain the 工作組編輯體例之簡繁體詞彙表 table in the future
https://github.com/w3c/clreq/pull/437
[Zhengyu joins]
xfq: Content was written by Bobby
… there's a typo in the English translation
… I'll fix it
… Richard thought the problem had more to do with font support than with OS support
… also, it may not actually be very relevant to mention its classification as mathematical
… since the Unicode Standard is clearly nowadays suggesting non-mathematical usage
[Discuss the current status of this character in the Unicode Standard]
Eric: Then let's delete the part after the word "However, "
xfq: OK, I'll update the PR
https://github.com/w3c/clreq/pull/436
xfq: this PR removes the Han-Western spaces in README.md
Eric: https://
[xfq introduces CSS issue #7050]
xfq: Are we satisfied with #7050?
Eric: OK
xfq: I'll merge this PR (#436)
https://github.com/w3c/csswg-drafts/issues/7055
xfq: Murakami-san proposed to change the default behavior of CSS text-spacing from 'allow-end' to 'trim-end'
… 'allow-end' sets fullwidth closing punctuation with half-width glyphs (flush) at the end of each line if it does not otherwise fit prior to justification; otherwise set the punctuation with full-width glyphs
… 'trim-end' sets fullwidth closing punctuation with half-width glyphs (flush) at the end of each line
"fullwidth closing punctuation"
xfq: 'trim-end' meets our standards in Mainland China, i.e., GB/T 15834—2011
… The third point is a subset of the fourth (in the clreq section), so I think the two points can be merged.
Eric: according to GB/T 15834—2011, 'trim-end' is a SHALL/MUST, not a MAY
… this is a hard requirement
xfq: in the current clreq text, it's "can be reduced to half a character width"
… should we change it to SHALL?
Eric: Taiwan does not have this requirement
… In Founder's typesetting software, the end of the line can only be half-width.
… in Adobe InDesign, it's customizable
Eric: We can add a note saying that this is required according to GB/T 15834—2011
… In Taiwan, both half-width glyphs and full-width glyphs at the end of line are fine
… If there is only one punctuation mark at the end of the line
… if you force this punctuation into a half-width, it will increase the tracking, which is not good-looking.
Zhengyu: there is another issue
… in Taiwan, punctuation marks are positioned in the vertical and horizontal center
… What will they look like when compressed into half-width?
Eric: In theory, the spacing before and after will be trimmed
https://
Eric: first quarter and last quarter
Zhengyu: The default value in CSS should be the safest rather than the most aesthetically pleasing
… I'm worried that 'trim-end' will cause some side effects
Eric: Murakami-san said that 'trim-end' is typographically better in most cases, and the processing is simpler
Zhengyu: But his proposal is mainly aimed at Japan and Mainland China
… if the browser does not implement "first quarter and last quarter trimming" in time
… there will be problems with the rendering of punctuation marks in Taiwan and Hong Kong
Eric: KATAKANA MIDDLE DOT (U+30FB) also needs "first quarter and last quarter trimming"
… but only one side is trimmed at the end of the line instead of both
… so it will become three quarters of the width of a kanji
… won't trim the first quarter
… JIS X 4051 says:
… 中点類が行末又は割注行末にきた場合は，中点類の前は四分アキを原則とし，中点類の後ろはベタ組とする。ただし，ベタ組とする代わりに，6.1.2備考2. の処理系定義によって四分アキを原則としてもよい。
… I believe the browsers will trim the punctuations correctly
… in Japanese they trim a quarter of the punctuation at the end of the line, but in Chinese it is rare.
Zhengyu: Whether it is trimmed depends on whether the punctuation is in the center
xfq: Should we comment on the CSS issue?
Zhengyu: I'm not in Taiwan, not a user of this kind of punctuation, it would be better if Bobby could give an opinion.
… this proposal is good for Mainland China, but it is not necessarily good for Taiwan.
xfq: I can file a clreq issue and ask Bobby if he has any thoughts.
Eric: The Guobiao SHALL issue can also be mentioned in the issue
https://github.com/w3c/clreq/pull/425
xfq: Zhengyu made some suggestions
Zhengyu: we can add a new section called 关于外语教材的非典型标点符号配置 (Atypical punctuation marks in foreign language textbooks)
Eric: there's a standard called 《CY/T 154—2017 中文出版物夹用英文的编辑规范》
… "Rules for editing Chinese publications interpolated with English"
… Chinese publications interpolated with English do not necessarily appear in textbooks, they also appear in foreign language academic research books and so on.
Zhengyu: besides 非典型的标点符号及其配置, we also need a section called 部分标点符号的非典型用法
xfq: There are other atypical punctuations, for example, tilde can represent a word in lexicography
… I'll close this PR, open a new issue, and we can discuss it there.
Zhengyu: OK
Eric: I'll look into atypical punctuations
https://github.com/w3c/clreq/pull/400
https://
xfq: Regarding @NightFurySL2001's most recent comment, I personally prefer not to indicate the incrementing direction
Eric: I don't think it's necessary
Zhengyu: I don't think we need to mention this or add a more detailed explanation of the logical direction.
Zhengyu: If we want to explain it, it should be explained when we describe the Chinese writing directions, not in the section of tables.
Eric: Now that we've reached consensus, I suggest we merge this.
https://github.com/w3c/clreq/issues/443
Eric: This problem is complicated. It was also discussed in Unicode many times.
Zhengyu: This problem is complicated, indeed.
[Eric introduces the background of the issue]
Eric: Is it necessary to mention this in clreq?
… we need to ask Bobby
… many people do not know the background and historical reasons in Unicode
… see also https://
Next teleconference time
April 8 (Friday), 19:00-20:00 (UTC+8)