W3C

– DRAFT –
Chinese Layout Task Force Teleconference

27 March 2024

Attendees

Present
Bobby, Eiso, Eric, xfq, Yijun, Zhengyu
Regrets
-
Chair
xfq
Scribe
xfq

Meeting minutes

Adjustment of adjacent punctuation marks

https://www.w3.org/TR/2024/WD-css-text-4-20240219/#example-eec02af5

xfq: CSS has adjacent-pairs trimming ^

https://www.w3.org/TR/clreq/#h-adjustment_of_adjacent_punctuation_marks

"In principle, any two adjacent punctuation marks that are 2 em wide should be reduced to 1.5 em. Following the same principle, they may be reduced to 1 em for certain typographic styles."

xfq: in clreq, we allow two adjacent punctuation marks to be reduced to 1 em for certain typographic styles ^

xfq: This is currently not supported in CSS. Do you think it is necessary to support it?

Eric: This also involves prohibition rules for line start and line end and full justification, and the issue of who takes precedence

[The group reviews CSS Text L4]

[Discuss the differences between print and the web]

Eric: The line length on the web is often uncontrollable
… I think this matter can be put aside for now because it is very complicated
… and it's currently only supported by Blink

Bobby: WebKit is likely to have the same behavior as iOS, and may not necessarily develop a new set of behaviors for the web.

Eric: but the behavior on iOS is not correct

Bobby: indeed

Eric: and fonts must have the OpenType `halt` or `chws`

Eric: Most fonts don’t have `chws`

xfq: indeed

Eric: `chws` is a relatively new feature

Eric: not in the initial version of Source Han Sans Chinese, for example
… supported by Hiragino, PingFang, and Source Han Sans
… not supported by Microsoft YaHei

[Discuss the current state of system fonts]

Eiso: Many font developers in Mainland China don’t know this feature, and they don’t even know many old OpenType features.

Bobby: same in Taiwan

Eiso: Mainland China, Hong Kong, Macau, and Taiwan may need to have local official guidance on fonts.

[Discuss the typeface companies in Mainland China and Taiwan]

Eric: Japanese fonts have a de facto standard, but Chinese font do not
… Chinese font developers usually only support the horizontal and vertical glyph conversion feature

Eiso: Many fonts don’t even support this, and these fonts are used in vertical writing mode. The rendered results are funny.

Bobby: Is it because font developers don’t know these features, so the new fonts don’t support them, or are too many people still using old fonts?

Eiso: Both.

Zhengyu: this is a chicken and egg problem
… First we need to make the system fonts support it
… like the Microsoft fonts

Eric: We should build powerful layout engines so that no matter how stupid the font is, they can render the glyphs correctly.
… Should we ask the people responsible for fonts at Microsoft to support halt/chws as a group or as individuals?
… they can update the Windows fonts

Bobby: who is in charge of maintaining Chinese fonts on Windows?

Eric: I don't know, they may need to ask for outside help
… it might be more difficult to make fonts from the Founder Group to support halt/chws
… but we can deal with the OS fonts first
… There are also problems with some Japanese fonts
… for example, the punctuation marks in Yu Gothic UI are incorrect
… Yu Gothic is correct
… because Microsoft modified the Yu Gothic font incorrectly
… fonts from Google and Apple have similar issues

[Discuss the punctuation width adjustment convention in Taiwan]

Yijun: in Taiwan, the width of periods should not be adjusted

Eric: in Simplified Chinese, the width of [。”] should be adjusted

xfq: The period can be seen as a hollow middle dot
… according to https://www.w3.org/TR/clreq/#h-punctuation_adjustment_space , period and middle dot are adjustable

Eric: 1/4 em before and after the character face

[Discuss how to do the punctuation width adjustment]

https://www.w3.org/TR/jlreq/#id160

xfq: requirements for Japanese ^

xfq: see also https://www.w3.org/TR/jlreq/#positioning_of_closing_brackets_full_stops_commas_and_middle_dots_at_line_end for middle dots at line end

Eric: This is different between Chinese and Japanese

xfq: in https://www.w3.org/TR/clreq/#h-adjustment_of_adjacent_punctuation_marks , should we change "adjustments should be made in principle" to "adjustments can/may be made"?

Yijun: I think the centered comma, period, secondary comma, colon, semicolon and interpuncts in https://www.w3.org/TR/clreq/#fig_punctuation_adjustment_space should be changed to "unadjustable".

Eric: Some people who don’t understand Chinese think this is kerning, but it’s not.

Eric: Because kerning is static

Eric: but this is dynamic

Eric: There is a big difference between the current CSS spec and real mojikumi. The advanced mojikumi algorithm is much more complex.

https://www.w3.org/TR/clreq/#id86

[Discuss the glyph of interpuncts in Simplified Chinese]

"The width of interpuncts varies in different regions. In principle, in Hong Kong and Taiwan, interpuncts should have the same dimensions as a Hanzi in both vertical writing mode and horizontal writing mode. In Mainland China, interpuncts take up half the space of a Hanzi."

Eric: 'text-spacing-trim: trim-all' can be used in some Chinese dictionaries

Yijun: indeed, and this is not kerning

[Discussing kerning in Chinese characters, Kana, and Hangul / Chosŏn'gŭl]

https://www.w3.org/TR/klreq/#fonts-kerning

Eric: there's kerning in フィー, for example

Bobby: I personally think there is no demand for adjustment of adjacent punctuation marks in Taiwan

Zhengyu: What are the publishing practices in Taiwan?

Bobby: no adjustment

Zhengyu: OK

Bobby: except the compression of punctuation marks at line start or line end

Zhengyu: There is another issue. I think when lang is a non-CJK language, text-spacing-trim should be space-all.

xfq: I'll create an issue to discuss https://www.w3.org/TR/clreq/#punctuation_width_adjustment for Taiwan

Go through the pull request list

https://github.com/w3c/clreq/pulls

w3c/clreq#596

All: OK to merge

w3c/clreq#603

[xfq introduces the discussions in the i18n WG meeting]

xfq: I also added a link to the Contributors section in the spec metadata section

Eric: looks good to me

Bobby: looks good to me

xfq: I'll update the PR

Next teleconference time

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

Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).