Closed xfq closed 2 years ago
English translation:
The glyphs in some system fonts do not match the recommended glyphs in our document. Do they need to be reflected in our gap analysis document?
Examples:
U+2E3A TWO-EM DASH[⸺]
and U+2026 HORIZONTAL ELLIPSIS […]
are not vertically centered in PingFang.U+2013 EN DASH [–]
is not vertically centered in Noto Sans CJK TC/SC.U+2013 EN DASH [–]
, U+2014 EM DASH [—]
, U+2E3A TWO-EM DASH[⸺]
, and U+2026 HORIZONTAL ELLIPSIS […]
are not vertically centered in Microsoft JhengHei and Microsoft YaHei.The width of interpuncts U+00B7 MIDDLE DOT [·]
is also problematic in some fonts.
The root cause of this problem is that some Chinese and Western punctuations share the same code points.
Unless we can persuade Unicode to de-unify these code points, IMHO most of these are unsolvable problems caused by Unicode’s decision to “unify” code points that should never have been unified because (as you’ve pointed out) “minimal pairs” can easily be found.
These incorrect unifications are actually causing a lot of headaches for English speakers.
I can add to this list the width and spacing of curly quote marks (“‘’”). These glyphs in simplified Chinese fonts behave completely differently than the same glyphs in other fonts.
U+2026 HORIZONTAL ELLIPSIS […] are not vertically centered
Chapter 6.2, pages 276-277 of v14 of the Unicode Standard suggests using ⋯ U+22EF MIDLINE HORIZONTAL ELLIPSIS instead of … U+2026 HORIZONTAL ELLIPSIS for CJK. There's probably a backlog of pages out there which use the ordinary ellipsis, so there's still a need for a font to correctly support the positioning, but perhaps clreq should also consider recommending the use of the midline ellipsis?
U+2026 HORIZONTAL ELLIPSIS […] are not vertically centered
Chapter 6.2, pages 276-277 of v14 of the Unicode Standard suggests using ⋯ U+22EF MIDLINE HORIZONTAL ELLIPSIS instead of … U+2026 HORIZONTAL ELLIPSIS for CJK. There's probably a backlog of pages out there which use the ordinary ellipsis, so there's still a need for a font to correctly support the positioning, but perhaps clreq should also consider recommending the use of the midline ellipsis?
Thanks for the hint. I have filed https://github.com/w3c/clreq/issues/432 to track this.
I filed this issue to discuss whether we need to file a gap analysis issue. After discussing with @r12a, I have filed a gap analysis issue (i.e., #430), so I would like to close this issue. Discussions about the content of the gap analysis issue or the larger Unicode issue can be discussed in #430 or in other new issues.
一些系统字体下的字形与我们文档里的推荐字形不符,是否需要体现到我们的差距分析文档里?
例子:
U+2E3A TWO-EM DASH[⸺]
和U+2026 HORIZONTAL ELLIPSIS […]
好像不垂直居中;U+2013 EN DASH [–]
好像不垂直居中(连接号是否有这个要求?);U+2013 EN DASH [–]
、U+2014 EM DASH [—]
、U+2E3A TWO-EM DASH[⸺]
、U+2026 HORIZONTAL ELLIPSIS […]
看起来不垂直居中。间隔号
U+00B7 MIDDLE DOT [·]
的字宽也有一些问题。