Consolidation of Glyph Correction Suggestions (See Issue #178)

[kenlunde]

This Issue will be used to track glyph correction suggestions, and will consolidate existing Issues so that a single Issue can be used. Please report any future glyph correction suggestions to this Issue.

[kenlunde]

Issues #50, #61, #89, #90, #93 , and #96 are consolidated here.

[hfhchan]

In TWHK, the rooftop dots in a "two dots + horizontal stroke" (e.g. 首弟美 etc) may need be redesigned. Currently, the first dot touch but not join the horizontal stroke, while the second dot join the horizontal stroke.

According to the MOE Song glyphs, they should not touch nor join the horizontal stroke. In the commerical Chinese Song typefaces, the left dot does not touch the horizontal line while the right dot joins the horizontal line. This is because the shape of the left dot looks very "black", the shape of the right dot needs to be elongated to create a balance of blackness. However, since strokes are the same thickness in Heiti and balanced in blackness already, the right stroke need not be elongated and join the horizontal line.

I think that both strokes "join" suits Heiti fonts much better. An example is to compare the rooftop dots of 慈 versus 弟. My opinion is that joining looks better than one touch and one join, or two touch.

However, if sharing more glyphs are preferred, then having both strokes touch instead of joining horizontal line may be preferred. For the CN glyphs, Microsoft YaHei itself is not consistent about using "left touch, right join" or "left touch, right touch". So if the CN and TW glyphs used the "left touch, right touch", the same glyph can be shared across CN/TW/JP/KR.

[RyanChng]

@hfhchan: hmm, what about the two strokes in compounds like 立? If they both touch bottom and both don't touch top... might look weird. Also Taiwan standard says those strokes must touch bottom AND top...

[hfhchan]

@RyanChng agree with you that the strokes must touch top and bottom for TW's 立. I think this means that the glyphs for TW's 立, by itself and in elongated position (on the left or right) cannot continue to be shared with CN. Meanwhile, the top dot should at least touch if not join the first horizontal line too. So I think they should be disunified from the CN glyphs.

SHS TW is also inconsistent about the left dot touch/join when 立 is compressed at the top. Compare 音, 章 and 意. The style for 章 (two dots join at bottom) seems more appropriate to me, and is also the style used for Microsoft YaHei Bold when 立 is in this position. In this case, I think it is possible that SHS can get away by having the top of the two strokes touch the top stroke, and join the right stroke, for both CN and TW in this situation.

[hfhchan]

To better illustrate my point, here is a quick ugly mockup:

Red: Changed Glyphs / New Glyphs
Grey: Shared Glyphs with CN

[fatloong]

Inconsistent shape for 全(U+5168) in SC version

While 全 as a component of some glyphs, such as 铨, 诠, 佺, 醛, 荃, 痊 .etc, middle stroke "一" is longer than top stroke "一" of their component "王".

However, for the Simplified Chinese glyph for 全, the length of top stroke "一" and middle stroke "一" is almost equal of its under component "王". This is quite different from both the glyph for 全 as a component of other glyhps and original JP version.

Therefore, my suggestion is making the middle stroke "一" longer than the top stroke "一" of component "王" of the Simplified Chinese glyph for 全 as JP version. SC and JP version should share the same component "王" to keep consistency of the glyph for 全.

[RyanChng]

Hmm @fatloong I notice there's another difference between SC and JP, which is the intersection/meeting of the two strokes in 人. Wonder why that is so...

[RyanChng]

@kenlunde there are actually a lot of errors in TC I’ve noticed. The 禾 component in 透 and 誘 is wrong, the last stroke should curve downwards. Also for 稽, the 匕 component’s first stroke should be straight instead of curved... the Taiwan MOE standard is notoriously difficult, so should we open a separate issue for TW glyph correction? Haha

[fatloong]

@RyanChng Well I guess the reason for the difference of 人 between SC and JP may be the glyph should follow China and Japan standard relatively...

[RyanChng]

@fatloong yeah China standard seems to insist the two strokes meet differently, Japan standard shows them meeting at the same point. TW standard is a 入.

[kenlunde]

Please try to refrain from using this "issue" as a discussion thread. If a discussion is necessary, I suggest it be done elsewhere, and the results posted to this issue.

[RyanChng]

OK sorry @kenlunde, to summarise, known issues we have right now with TW are the strokes in 誘, 透 and 稽...

[kenlunde]

No worries. I simply want to minimize the volume of discussion, and instead to focus more on the end result of such discussions. This makes the "issue" much easier to navigate.

[tamcy]

The component 口 in 極 (U+6975, TW & CN), 避 (U+907F, CN) and 迵 (U+8FF5, TW & CN) are inconsistent with the other glyphs.

Also, I would like to suggest to improve the quality of TW version's 極 (look at the placement of 口). Actually this is not an isolated issue: when there is a need to adjust the look of the character for standard compliance, I found that KR version tends to just replace the unsuitable parts, preserving the original components as much as possible. However, the vendor tends to redraw the whole CN/TW glyph (Exceptions are like 鬱 and 留). Unfortunately, the quality of the redrawn glyph sometimes isn't quite to the standard of the original one (I suppose JP can be used as the reference base?).

(EDIT 1: added 迵 U+8FF5 to the list)
(EDIT 2: added 鴿 U+9D3F, 造 U+9020)

[justinrleung]

Although 國字標準字體研訂原則 doesn't specify how the corners of 口 should be, 口 only has protrusions on both bottom corners when 口 is exposed at the bottom of the character in the 國字標準字體方體母稿.

[RyanChng]

I think for 方体, we should follow the standard of "when 口 is at left or bottom left, no protrusion on bottom-right corner; when 口 is at the bottom or right or anywhere else, protrusions at the bottom."

[be5invis]

The bottom of glyph 鳖 should be aligned to glyph 吃:

[kenlunde]

Because ideographs are optically centered within the em-box, and do not rest on a static line, I will leave the judgment up to SinoType's designers. In other words, I will bring this issue to their attention. However, your screenshot shows a perhaps more serious problem with the glyph for 鳖 (uni9CD6-CN) in that the top portion of the protruding vertical stroke in its upper-left component has two thicknesses. I will also report this issue to SinoType for fixing.

[tamcy]

The issue of inconsistent thicknesses for the same stroke also occurs in other glyphs with 㡀 component (like 敝, 弊, 幣) in all locales. It seems to me that the designer intentionally reduced the thickness of the inner vertical line of 㡀 to give more space to accommodate the two inner "ten"s (点/點/､) for the heaviest weight. The fact that such behavior is also found in Kozuka Mincho and Kozuka Gothic seems to support my assumption. However, due to the interpolation nature of Source Han Sans, that thickness difference is also observed in intermediate weights (thin, normal, regular, medium and bold) where such an adjustment is unnecessary.

[hfhchan]

Not a correctness issue per se, but the character 為 is very oddly shaped. There seems to be visually too big a gap on the centre-left of the glyph. Most common fonts (e.g. Microsoft Yahei, Microsoft Jhenghei, SimHei) "deal" with this by starting the second downward left stroke about 1/3 from the left of the glyph, rather than 2/5 from the right.

[ShikiSuen]

Regarding the TW version of Source Han Sans, the glyph "恋" is supposed to be presented like the following:

But, it displays as following (in SHS 1.004R):

[acuteaccent]

Well, such implementations are just simply not catching up; they are just behind. In order to make (or force) such implementations catch up and to get rid of (or minimize) possible confusion, the ⿰鱼酒 glyph should definitely be mapped to U+4CA4 in the TC version as well.

[hfhchan]

A quick google returns nil meaningful results - either mojibaked documents or dictionary websites pulling data from Unihan. The character U+4CA4 is effectively unused on the web.

[acuteaccent]

The nominal forms of leading consonants (choseong) and trailing consonants (jongseong) of conjoining hangul jamo need to be distinguished, like those in Malgun Gothic, HCR Dotum/Batang LVT, and Source Han Serif.

[lapomme]

The Korean glyph for 寧 is incorrect. There is supposed to be a long horizontal stroke like in Chinese but it seems to share a glyph with the Japanese version. This issue is also present in Source Han Serif.

http://www.zdic.net/z/18/zy/5BE7.htm
http://hanja.naver.com/hanja?q=%E5%AF%A7

[hfhchan]

U+5064 TW glyph should not be same as CN glyph (second last stroke should not touch both sides)

[hfhchan]

Not exactly a bug, but the enlarged width of the 耳 component for TW and diminished width in CN is disorientating when put into blocks of text.

Compare with this, where the right-hand side component for the TW glyph is undersized.

A normal example.

[hfhchan]

CN glyph for U+4FB4 should be a 提.

[hfhchan]

The CN glyph for U+4FB9 is in error. The second stroke of the top right hand component should be the longest. The suggested correction will be different from the code charts but is consistent with China's 通用規範漢字表.

[hfhchan]

The CN glyph for U+5908 is in error. The last stroke should be DIAN, not NA

[acuteaccent]

uni11F5.tjmo04 needs to be shifted to the right. Compare with other similar final consonants:

↓ without lines

↓ with lines

[hfhchan]

Design Issue: U+5FB9

The middle and right hand component of the CN glyph is shifted too far right. The issue is more apparent in Black weight.

This is a Traditional Chinese character, thus generally unused by China, so it might not be worth the effort to fix anyway.

[hfhchan]

Design Issue: U+5D1D

The space between 山 and 青 is too large for CN. The main reason is, the second stroke in 青 has been shifted right and the bottom 月 component is too far to the right. The width of 山 is also slightly larger and thicker in the JP glyph than that of CN and TW.

[acuteaccent]

#99 (comment) continued:

comparing across all weights

[kenlunde]

@acuteaccent: Thank you. As I suspected, the issue is with the ExtraLight master, and is manifested in all weights except for Heavy, which is positioned correctly.

[hfhchan]

For those who are wondering, all the glyphs in my proofing charts are in the order CN, TW, JP, KR

[acuteaccent]

U+2035 REVERSED PRIME ‵ should have the mirror image of U+2032 PRIME ′. Well, I wonder why this is included in Source Han Sans to begin with.

[kenlunde]

@acuteaccent: The only reason why there is a mapping for U+2035 in Source Han Sans is for GB 18030 compatibility. Also, its glyph is full-width, not proportional, so the designs are necessarily different, and is double -mapped to the glyph for U+FF40.

[hfhchan]

The TW glyph for 釉 U+91C9 and 隉 U+9689 are in error:

Code Chart:

See also: adobe-fonts/source-han-serif#53 (comment)

[kenlunde]

@hfhchan: This belong in Issue #115, because new TW glyphs for U+91C9 釉 and U+9689 隉 need to be added. Looking at my Version 2.000 notes, my list of additional TW glyphs, which includes 40 characters, includes both of these characters.

[kenlunde]

Fix the CN glyphs for U+465B 䙛 and U+6E09 渉, uni465B-CN and uni6E09-CN, respectively per Source Han Serif Issue 55.

[acuteaccent]

U+31C3 ㇃ (CID+1822) needs be redesigned. The current glyph is essentially identical to that of U+31DF ㇟ (CID+1850).
Compare with Source Han Serif.

[kenlunde]

@acuteaccent: Although not recorded here, correcting the glyph for U+31C3 ㇃ was already among the list of glyphs that require attention.

[kenlunde]

Consolidated with Issue #178.