Clreq Editors' Call

04 March 2022


Eric, huijing, xfq, Zhengyu

Meeting minutes

Go through the pull request list



[xfq introduces the PR]

xfq: Only the order is adjusted, not the content.

Eric: looks good to me

xfq: I'll merge it


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


[xfq introduces the PR]

Eric: looks good to me
… We can continue to maintain the 工作組編輯體例之簡繁體詞彙表 table in the future


[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


xfq: this PR removes the Han-Western spaces in README.md

Eric: https://github.com/w3c/csswg-drafts/issues/7050

[xfq introduces CSS issue #7050]

xfq: Are we satisfied with #7050?

Eric: OK

xfq: I'll merge this PR (#436)


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"

Related section in clreq

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


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


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



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.


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://bobtung.medium.com/%E7%94%A8ruby-%E5%AF%AB%E5%8F%B0%E8%AA%9E-3a1e3ed9bf3c

Next teleconference time

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

Minutes manually created (not a transcript), formatted by scribe.perl version 188 (Sat Jan 8 18:27:23 2022 UTC).