You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-text-4] text-spacing needs to handle non-fullwidth punctuation also #6091
“京都(日本)” This doesn't collapse between the closing parens and the closing quote, but it really ought to. (Note that curly quotes are used in Chinese, and are rendered fullwidth even though they use the same codepoint.)
JLReq TF is currently discussing this class of issues. Font information is needed to augment the spacing rules of Unicode code points when the code point could be full-width or not depending on the font, and the collapse of extra space to achieve a zero-point is a necessary first step of correct glyph spacing adjustment (the second being to selectively restore some spacing).
The single and double curly quotation marks are explicitly called out in the spec already, because of their usage in Chinese. So this issue is focused on other punctuation such as non-fullwidth brackets and guillmots etc. E.g. {京都(日本)}
We've discussed this at the JLReq TF meeting and developed a note (in Japanese). In sum, when a proportional opening bracket is placed before a fullwidth opening bracket (cl-01 in JLReq), and when a proportional closing bracket is placed after a fullwidth closing bracket or a fullwidth fullstop & comma (cl-02/06/07), the extra space within the fullwidth character should be removed.
We've discussed this at the JLReq TF meeting and developed a note (in Japanese). In sum, when a proportional opening bracket is placed before a fullwidth opening bracket (cl-01 in JLReq), and when a proportional closing bracket is placed after a fullwidth closing bracket or a fullwidth fullstop & comma (cl-02/06/07), the extra space within the fullwidth character should be removed.
JL-TF finally agreed to update jlreq(-d) spacing property document (one defined using Unicode property is under development), based on above direction. This update will cover all of pairs between non-fullwidth punctuation (like in Latin script, and expanded to whole Unicode) and fullwidth punctuation (defined by EAW is F or W, and which were included in definition of JLreq), as:
adding corresponding character classes for non-wide width ones over defined classes, A/B/BA - adding Ap or something
expand existing table for omitting spacing, using newly added character classes, with copying conditions where appopriate
Added a commit that should handle non-CJK "proportional" bracketing punctuation: cc2ee4c
It does not handle non-CJK stops and commas like ). (full width closing parenthesis followed by ASCII period) or 」, (full width right corner bracket followed by ASCII comma), or equivalent things in other writing systems.
Should it? If so, how do we identify the relevant set(s) of characters?
It also doesn't handle ambiguous punctuation from the Pf / Pi categories (like ‘ ’ or « ») other than double curly quotes which are already special-cased due to Chinese. That's probably unavoidable though.
The CLReq TF discussed this issue and concluded that the spacing around non-fullwidth punctuations should not be changed in Chinese, because these are not part of Chinese punctuation and should be handled according to the rules of Western punctuations.
We'd be happy to continue discussing a possible solution with the JLReq TF and the CSSWG, for example, different behaviour depending on the language?
I understand that some Chinese fonts such as "Microsoft JhengHei" have fullwidth brackets center-aligned in the full width, and that cause problem if trimmed with adjacent non-fullwidth punctuation.
How about Korean text layout? In Korean texts, non-fullwidth punctuations are used primarily, and also fullwidth brackets are used occasionally. So I thought that the text-spacing handling of adjacent fullwidth and non-fullwidth punctuations might be important for Korean text.
I checked Korean Wikipedia articles that contain adjacent fullwidth and non-fullwidth punctuations.
… 로버트 듀발, 리처드 해리스 주연의 1993년 영화 《월터와 프랭크》(원제 《헤밍웨이와 레슬링하기》)는 플로리다의 해안 마을에서 은퇴한 두 친구의 우정을 다루었다. …
Hemingway, Ernest (2013). 《헤밍웨이 단편선(1~2 합본)》. 번역 김욱동. …
Hemingway, Ernest (2013) [1932]. 《오후의 죽음》. 번역 장왕록. …
These examples use 《 (U+300A LEFT DOUBLE ANGLE BRACKET) and 》 (U+300B RIGHT DOUBLE ANGLE BRACKET) which are East_Asian_Width=Wide, but interestingly these fullwidth brackets appear to be half width in my browser's default Korean font setting (Korean font: "Apple SD Gothic Neo").
Screenshots, with Korean font "Apple SD Gothic Neo":
If such Korean fonts are very common, text-spacing-trim would not be necessary for Korean text. However, I found that other Korean fonts, such as AppleGothic, AppleMyungjo, Noto Sans KR, or Source Han Sans K are not the case.
Screenshots, with Korean font "AppleGothic":
In these results, the spacing of adjacent fullwidth and non-fullwidth punctuations looks not very nice.
We will need to hear from Korean text layout experts.
The CLReq TF discussed this issue and concluded that the spacing around non-fullwidth punctuations should not be changed in Chinese, because these are not part of Chinese punctuation and should be handled according to the rules of Western punctuations.
We discussed this issue again during the I18N ⇔ CSS Call and another CLReq Editors' Call, and we're OK with trimming the spacing around non-fullwidth punctuations in Chinese (i.e., the current JLReq/CSSWG consensus).
Activity
xfq commentedon Mar 11, 2021
See clreq § 3.1.6.1 and § 3.1.6.2 for requirements for Chinese layout.
macnmm commentedon Mar 12, 2021
JLReq TF is currently discussing this class of issues. Font information is needed to augment the spacing rules of Unicode code points when the code point could be full-width or not depending on the font, and the collapse of extra space to achieve a zero-point is a necessary first step of correct glyph spacing adjustment (the second being to selectively restore some spacing).
fantasai commentedon Sep 12, 2022
The single and double curly quotation marks are explicitly called out in the spec already, because of their usage in Chinese. So this issue is focused on other punctuation such as non-fullwidth brackets and guillmots etc. E.g.
{京都(日本)}kidayasuo commentedon Sep 22, 2022
We've discussed this at the JLReq TF meeting and developed a note (in Japanese). In sum, when a proportional opening bracket is placed before a fullwidth opening bracket (cl-01 in JLReq), and when a proportional closing bracket is placed after a fullwidth closing bracket or a fullwidth fullstop & comma (cl-02/06/07), the extra space within the fullwidth character should be removed.
e.g. these cases
[「
」]
。]
himorin commentedon Nov 16, 2022
JL-TF finally agreed to update jlreq(-d) spacing property document (one defined using Unicode property is under development), based on above direction. This update will cover all of pairs between non-fullwidth punctuation (like in Latin script, and expanded to whole Unicode) and fullwidth punctuation (defined by EAW is F or W, and which were included in definition of JLreq), as:
for more, see e.g.: w3c/jlreq#340 (comment)
[css-text-4] Handle non full-width punctuation in text-spacing *-adja…
frivoal commentedon Jan 27, 2023
Added a commit that should handle non-CJK "proportional" bracketing punctuation: cc2ee4c
It does not handle non-CJK stops and commas like
).(full width closing parenthesis followed by ASCII period) or」,(full width right corner bracket followed by ASCII comma), or equivalent things in other writing systems.Should it? If so, how do we identify the relevant set(s) of characters?
It also doesn't handle ambiguous punctuation from the Pf / Pi categories (like ‘ ’ or « ») other than double curly quotes which are already special-cased due to Chinese. That's probably unavoidable though.
xfq commentedon Mar 2, 2023
The CLReq TF discussed this issue and concluded that the spacing around non-fullwidth punctuations should not be changed in Chinese, because these are not part of Chinese punctuation and should be handled according to the rules of Western punctuations.
We'd be happy to continue discussing a possible solution with the JLReq TF and the CSSWG, for example, different behaviour depending on the language?
MurakamiShinyu commentedon Mar 4, 2023
I understand that some Chinese fonts such as "Microsoft JhengHei" have fullwidth brackets center-aligned in the full width, and that cause problem if trimmed with adjacent non-fullwidth punctuation.
How about Korean text layout? In Korean texts, non-fullwidth punctuations are used primarily, and also fullwidth brackets are used occasionally. So I thought that the text-spacing handling of adjacent fullwidth and non-fullwidth punctuations might be important for Korean text.
I checked Korean Wikipedia articles that contain adjacent fullwidth and non-fullwidth punctuations.
sample1
sample2
These examples use
《(U+300A LEFT DOUBLE ANGLE BRACKET) and》(U+300B RIGHT DOUBLE ANGLE BRACKET) which are East_Asian_Width=Wide, but interestingly these fullwidth brackets appear to be half width in my browser's default Korean font setting (Korean font: "Apple SD Gothic Neo").Screenshots, with Korean font "Apple SD Gothic Neo":
If such Korean fonts are very common, text-spacing-trim would not be necessary for Korean text. However, I found that other Korean fonts, such as AppleGothic, AppleMyungjo, Noto Sans KR, or Source Han Sans K are not the case.
Screenshots, with Korean font "AppleGothic":
In these results, the spacing of adjacent fullwidth and non-fullwidth punctuations looks not very nice.
We will need to hear from Korean text layout experts.
MurakamiShinyu commentedon Mar 7, 2023
For the example case above,
text-spacing: trim-allmay be a better option:xfq commentedon Mar 29, 2023
We discussed this issue again during the I18N ⇔ CSS Call and another CLReq Editors' Call, and we're OK with trimming the spacing around non-fullwidth punctuations in Chinese (i.e., the current JLReq/CSSWG consensus).