Clreq Editors' Call

21 January 2022


Bobby, Eric, huijing, xfq, Zhengyu

Meeting minutes

[Bobby shares a screenshot]

Bobby: I dealt with the following situation recently
… When using text-emphasis to make emphasis
… the line spacing is obviously widened in Traditional Chinese, in WebKit
… I have set line-height: 2
… In Firefox, there is no such problem, I think the implementation is different
… Around 2012, when I checked the Chinese and Japanese emphasis dots
… I found that WebKit has this problem
… and interestingly, there is no problem for Japanese fonts
… I didn't pay much attention to it
… how is the situation in Simplified Chinese?

xfq: We can write a gap analysis issue

xfq: You can try the Chinese and Japanese versions of Noto Sans font for a comparison.

Go through the pull request list



xfq: @reekystive added a space between Chinese and English text

xfq: README.md was translated into Chinese by me


xfq: according to ^

xfq: "In principle, there is tracking or spacing between an adjacent Han character and a Western character of up to one quarter of a Han character width, except at the line start or end."

xfq: But in https://github.com/w3c/clreq/issues/14 we decided not to add spaces to the source code of the *main clreq document*
… and use CSS instead
… But CSS might not be supported in Markdown, so I added the spaces at the time of translation.
… There seems to be little progress in browser implementation of CSS text-spacing


Zhengyu: iOS, iPadOS, and macOS supports it via Core Text

Zhengyu: Adobe InDesign, Microsoft Word, and some other desktop publishing apps support it

Zhengyu: for HTML, it is possible to add Han-Western spacing using CSS + JavaScript

Zhengyu: but there may be performance issues

Zhengyu: This is actually a house style issue, and there is no standard answer.

Zhengyu: Regarding this specific issue, I suggest that we do the same as the clreq main document, i.e., not adding spaces.

Bobby: I agree

xfq: OK, then I'll reject @reekystive's PR and remove the spaces in README.md


[xfq introduces the PR]

xfq: Currently, the title of the document will not change after switching languages
… but there is one problem: the English title is relatively long
… I think it would be much better if it could be displayed in Chinese

Zhengyu: I agree with the changes in this PR, but it doesn't solve the problem with the English version.

Zhengyu: How about adding [clreq] before the English title?

xfq: there are two problems

xfq: first, W3C publication rules says "The document's title must be in the title element and in an h1 element"


xfq: second, names may conflict between different documents, like Georgian vs. Greek, or Japanese vs. Javanese

Zhengyu: are Requirements for Japanese and Javanese Text Layout using different repos?

xfq: yes, one in w3c/jlreq, one in w3c/sealreq
… "sea" means Southeast Asia
… Let me discuss this with Richard.


xfq: I think the English translation is not very smooth, so I did some changes

[Discuss the use of Western periods in Chinese]

Zhengyu: There are two kinds of Western periods, U+002E FULL STOP [.] and U+FF0E FULLWIDTH FULL STOP [.]

xfq: U+FF0E is also mentioned in clreq

[Discuss GB standards]

Zhengyu: I'll comment in the PR


xfq: can we merge this now?

All: agreed to merge


Zhengyu: see my comment in https://github.com/w3c/clreq/issues/369#issuecomment-997366347

[Discuss the usage of the terms 逻辑行/逻辑列]

xfq: I'll update the PR based on Zhengyu's comment


xfq: I have updated the PR

xfq: mentioned the difference between "loose setting" word and "tracking"

Eric: looks good to me

xfq: I'll merge it

Go through the issue list



Bobby: I added a comment

xfq: That's an implementation issue, not related to our requirements docs

Bobby: But if we recommend U+22EF, people may think it's clreq's problem because it's displayed as tofu
… We need to say "it is a mathematical symbol, but because of its centered nature, it can also be used as the ellipsis punctuation. However, it may not display correctly in some operating systems."

Zhengyu: We can list all possible code points
… but we don't say which is better than which, because which is better depends on the context.

Bobby: I think U+2026 is fine

xfq: It is not vertically centered in PingFang, Microsoft JhengHei, and Microsoft YaHei.

Bobby: I'll draft some text


xfq: similar to https://github.com/w3c/clreq/issues/391

Zhengyu: We should make a SC/TC word table
… We focus on Simplified and Traditional Chinese, not Chinese in different regions
… although our SC version is more focused on the usage in Mainland China
… and the TC version is more focused on the usage in Taiwan
… we should make the differences between SC and TC into a traceable rule

xfq: We can create a specific page to maintain this list

Zhengyu: Even in Mainland China, the words used in the articles of different people and different publishers are different.

Zhengyu: We need to define our house style and update it if needed

Bobby: I created https://github.com/w3c/clreq/wiki

xfq: The downside of GitHub wiki is that there might be spammers

xfq: another disadvantage is that it does not support pull requests

xfq: but we can try it first

xfq: if there are spammers, we can restrict editing permissions or convert the wiki page to a file in the Git repo

Eric: Should we distinguish between Simplified Chinese used in Mainland China, Malaysia and Singapore and Traditional Chinese used in Hong Kong, Macau and Taiwan?

Bobby: I don't think it's necessary

Eric: But Hongkongers may not want to be represented by Taiwanese, for example.

Bobby: They are welcome to join our work and discuss these issues with us.

Zhengyu: This table is an editorial choice of ours and does not represent the official opinion of Taiwan or Mainland China, or any language standard

Zhengyu: it's just because we maintain two Chinese versions of the document, and some word choices may be different.
… it's just our writing style

xfq: I can add a link to it in the "Links for editors 编辑用链接" section of README.md
… and reply to the issues

Eric: Our editorial work is becoming more and more standardized


Eric: sounds good to me

Zhengyu: agreed

xfq: The Unicode Standard. URL: https://www.unicode.org/versions/latest/
… I'll add it to the References section

Next teleconference time

February 18 (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).