W3C

– DRAFT –
CLReq Editors' Call

21 February 2023

Attendees

Present
Bobby, Eric, huijing, xfq__, Yijun, Zhengyu
Regrets
-
Chair
xfq
Scribe
xfq

Meeting minutes

W3C Calendar

xfq: W3C developed our own calendar system

xfq: we need to make sure that the meetings of our group appear in the W3C calendar system

https://www.w3.org/groups/tf/i18n-clreq/calendar

[Discuss the profile in https://www.w3.org/groups/tf/i18n-clreq/participants ]

[css-text-4] text-spacing needs to handle non-fullwidth punctuation also

https://github.com/w3c/csswg-drafts/issues/6091

xfq: this issue was mentioned in the i18n/CSS joint meeting today
… it's about non-fullwidth punctuations and text-spacing
… how should we handle those punctuations?

{京都(日本)}

Eric: this is a complex issue

Zhengyu: We can treat these punctuation marks as Western text

Eric: We should not change the spacing around these characters

Zhengyu: If these characters appear and are used correctly, then they must be in the context of Western text

https://github.com/w3c/jlreq-d/issues/24

xfq: see ^
… in some cases the jlreq folks do want to remove the extra spacing within the fullwidth character

[「

」]

。]

xfq: like ^

Bobby: But whether the same Chinese punctuation is in the center of the square space left for them or positioned in different directions is not certain, different fonts behave differently

Eric: In this case, if you want to reduce the spacing, it may make the text look worse
… might be wiser to not make any changes to the spacing
… In typesetting practice, if such a situation occurs, we will first change the Western punctuation into the correct Chinese one, and then handle it according to the Chinese rule to adjust the punctuation width

xfq: the jlreq folks have requested that the extra spacing need to be removed in some cases

Eric: but Chinese doesn’t need this

Eric: Are the parentheses in Taiwan all in the in the horizontal center of the square space?

Bobby: no, but Microsoft JhengHei is

Zhengyu: I think this is a separate issue

Zhengyu: Period and comma also have this problem, but it doesn't affect the punctuation width adjustment logic

Zhengyu: The issue we need to discuss is:

Zhengyu: If Western punctuation appears in Chinese or Japanese, should we incorporate it into the punctuation width adjustment logic?

Zhengyu: If so, then let's look at how to design algorithms and rules, as well as specific implementation methods

Bobby: 規格 [epub3]
… Should the square brackets above be considered part of Western text?
… if so, we should use the rule in https://w3c.github.io/clreq/#mixed_text_composition_in_horizontal_writing_mode

Zhengyu: Your case is clear and the square brackets should be treated as Western text, and 1/8 - 1/4 em spacing should be added

[Discuss the issue of the curly quotation marks as in https://github.com/w3c/csswg-drafts/issues/6091#issue-827125720 ]

xfq: The single and double curly quotation marks are explicitly called out in the spec already, because of their usage in Chinese.

xfq: see https://www.w3.org/TR/css-text-4/#text-spacing-classes , they are classified as fullwidth opening/closing punctuations

xfq: the issue is, if our consensus is that we shouldn't remove the spacing in those cases, there are at least two possible directions:

xfq: 1. ask the CSSWG to handle Chinese and Japanese differently

xfq: 2. convince CSSWG and/or jlreq not to handle this case

Yijun: in CSS, do we have one switch for all punctuation marks, or can we handle it more granularly, i.e., just handle a certain pair of punctuation marks or like the line-break 'loose', 'normal', and 'strict'?

xfq: currently, CSS has no way to achieve fine control, the only way is to add a span element to the pair of punctuation marks you want to control the behavior

xfq: IIUC this is about the default behavior of 'text-spacing: trim-adjacent'

xfq: CSSWG is redesigning text-spacing to a shorthand, but it's still not possible to handle it more granularly even in the new design

Eric: I agree with redesigning it into several longhands

Yijun: I think CSS should be like Adobe InDesign, to be able to change the spacing of a certain pair of punctuation marks

Yijun: We shouldn't be too smart to deal with these Western punctuations

Bobby: This may happen in programming books, unauthorized modification of spacing is not correct typography

Eric: the height and baseline of the proportional and fullwidth brackets are different

Eric: So I think we should not modify the spacing here

Bobby: for the '規格 [epub3]' example, ideally we shouldn't need a space character (U+0020) between '規格' and '[epub3]'

Bobby: the browser should see it as Chinese and Western mixed text and add the gap automatically

[Discuss the extra spacing Chinese and Western mixed text]

xfq: But the extra spacing Chinese and Western mixed text may not be applicable to all Western punctuation marks

xfq: For example, if it is a slash, a comma, or an asterisk, do we need to add the extra spacing?

Eric: We didn't categorize the characters like jlreq did

Eric: If we want to discuss the behaviour of these characters, we first need to classify all the characters

[Discuss the methodology of classification]

Zhengyu: There are many types of punctuation

Zhengyu: the logic in jlreq is based on character classes rather than scripts

Eric: https://www.w3.org/TR/jlreq/tables/table_ja2.pdf
… Our classification may be different from theirs, and the classification for Simplified and Traditional Chinese may also be different

Zhengyu: it seems that the jlreq folks want to treat some Western brackets as Japanese punctuation marks

Zhengyu: but I hope we can classify them as Western punctuation

Yijun: I agree with Zhengyu
… except the single and double curly quotation marks
… Ken Lunde wrote a proposal for fullwidth punctuation many years ago

Bobby: is it https://www.unicode.org/L2/L2017/17436r-sv-eastsian-punct.pdf ?

Yijun: probably

Zhengyu: it uses variation sequences

Yijun: If this proposal moves forward, we can also deal with the curly quotation marks in this way

Eric: But it is impossible to require all old web pages and files to add this variation sequence

Yijun: but we can use it for future documents

Yijun: I didn't hear any progress for this proposal, though

Eric: Source Han supports this feature, but it may be the only font that supports it

Bobby: yeah

Eric: so how should we reply to fantasai?

Bobby: for '規格[epub3]', i.e., Western characters appear in Chinese text, and there are brackets on both sides of the Western characters, the browser should add the extra spacing like 'text-spacing: ideograph-alpha'

Bobby: for other cases, like a proportional opening bracket before a fullwidth opening bracket, we don't remove the spacing

xfq: That is to say, our consensus is different from the jlreq TF, right?

xfq: should we ask the CSSWG to handle Chinese and Japanese differently

Eric: I think we should

Bobby: agreed, I don't want the spacing to be affected in this case

Yijun: I think CSS should handle this differently depending on the language, ja, zh-Hant, zh-Hans, etc.

xfq: I'll bring this to CSSWG and see what they say

Vertical Writing Support in QTI 3

https://lists.w3.org/Archives/Public/public-i18n-japanese/2023JanMar/0022.html

xfq: Murata-san asked us to have a look at "Vertical Writing Support in QTI 3" and make comments on it

https://qti.amp-up.io/testrunner/test/16

Zhengyu: What specific issues do they need us to discuss?

xfq: I'm not sure about the specific issues

Eric: in 3, the position of the dot should be on the right instead of on the left

Eric: in theory, it should use 読点(、)

Bobby: 2 is perfect

Zhengyu: I still don't understand what they're asking for

Zhengyu: they made a proprietary implementation, do they want this to be a standard?

https://docs.google.com/document/d/1I4Ik9jRgrjyBemUTsFhrlsf_cHxGN5EMNs5gjcQPi8g/edit#heading=h.v966kfbe0x2j

Bobby: They didn't use HTML forms, they did it their own way

Eric: no comments from me

Yijun: I think it's good, but there's one problem

Yijun: in 16, the ✔️ in the select menu should be above the kanji characters

Yijun: in 17, if you select the leftmost menu in a narrow viewport it doesn't work well

Zhengyu: it's like https://github.com/w3c/clreq/issues/500 , the requirements, specs, and the implementations are not ready

Bobby: and https://github.com/w3c/clreq/issues/232

xfq: I can ask them what exactly they want us to comment on

Go through the pull request list

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

https://github.com/w3c/clreq/pull/515

xfq: looks good to me

All: OK to merge

https://github.com/w3c/clreq/pull/513

[xfq goes through the changes]

Bobby: re accessibility, please ask Roy Ran whether he has any idea

xfq: OK

All: OK to merge

https://github.com/w3c/clreq/pull/501

All: OK to merge

https://github.com/w3c/clreq/pull/492

https://github.com/w3c/clreq/pull/492#discussion_r1048383077

xfq: I discussed this with Richard. He suggested that we use "Latin, Greek, and Cyrillic" directly, or use a phrase like "simple alphabetic text" with a definition in the document.

[xfq talks about the background]

Zhengyu: I think neither of these two meets our requirements. If Richard objects to the word "European", let's change it back to "Western".

Eric: I agree with Zhengyu

Zhengyu: I'll update the PR

https://w3c.github.io/jlreq/#composition_of_japanese_and_western_mixed_texts

Eric: "Western and/or Greek letters" in jlreq ^

Go through the issue list

https://github.com/w3c/clreq/issues/514

Eric: please send your comments

Next teleconference time

March 21 (Tuesday), 19:00-20:00 (UTC+8)

Minutes manually created (not a transcript), formatted by scribe.perl version 197 (Tue Nov 8 15:42:48 2022 UTC).