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):

[jimmymasaru]

Is that character included in Plane 1 or 2 of CNS11643? If not, I believe a similar but not exact glyph is selected for that character. If yes, I think it's a bug.

[ShikiSuen]

I am not familiar with "planes", but what I saw among all other 全字庫標準 CNS11643 fonts supports my idea:

You could download 「全字庫正宋體」 and 「全字庫正楷體」 at this website: http://data.gov.tw/node/5961 They includes most commonly-used Simplified Chinese kanji glyphs (almost all of them, but I don't know the exact number).

[jimmymasaru]

As far as I know, Plane 1+2 ≈ Big5 which doesn't include any simplified characters. It seems to me that SHS TC satisfies the minimum requirement of CNS11643 while the fonts you listed support more glyphs.

[ShikiSuen]

But MOE really showed their standards in 「全字庫正宋體」 and 「全字庫正楷體」 regarding simplified kanji glyphs used in PRC and Japan.

Let we stop our discussions here and let Ken Lunde decides whether it's necessary to extended the SHS TW as what 「全字庫正宋體」 and 「全字庫正楷體」 do. If you think further discussion is necessary, please open a new issue as our discussion thread. Do not reply this message here.

[be5invis]

I found that two "王" radicals in "瑟琶" are asymmetric...

[tamcy]

芮 in JP - CN - TW

The weighting of 艹 and 內 doesn't look good in TW version.

[kenlunde]

Per this tweet, the CN glyph for U+5B4D (孍), uni5B4D-CN, has an incorrect left-side component (radical), which I just confirmed.

[orangeparanoid]

I would like to see the 口part to appear with the same height across characters with this component.

I mean the same height between the top margin and the top horizontal line of 口. See the screenshot.

[tamcy]

+1 to the above suggestion. Glad that I am not the only one who noticed this issue (that exceptionally high radical "口" in 啲 immediately caught my attention when I was reading a newspaper article on my Android phone. I hesitated to report it as it may sound subjective).

Also note that the placement of 口 is much more consistent in JP (second line in the screenshot). So this could be exclusive to CN/TW/HK glyphs.

[kenlunde]

Thank you for the comments on the placement of the 口 radical/component.

[ShikiSuen]

to @kenlunde & @orangeparanoid >

Such inconsistency is pretty common among all font products made by SinoType, which is one of the reason I look down on them. They never do placement unification on radical parts.

[kenlunde]

While I agree that some characters would benefit from such adjustment, in terms of the relative height and Y-axis position of the 口 radical/component, such inconsistency is not likely to be relevant in real-world text as characters that use the same component are not likely to appear together in strings of three or more (there are, of course, such two-character compounds). Still, this is worth bringing to SinoType's attention.

[orangeparanoid]

@kenlunde "such inconsistency is not likely to be relevant in real-world text as characters that use the same component are not likely to appear together in strings of three or more (there are, of course, such two-character compounds)"

These characters with the 口 component exist in the same utterance, in common real-world text. They are in Cantonese Chinese (not in Mandarin Chinese).

See the examples in a dictionary entitled "廣州方言詞典" published by 江蘇教育出版社 in 2003. (Maybe someone with the Cantonese Chinese background should help.)

[justinrleung]

@orangeparanoid I agree that the 口 radical is really common in Cantonese. Here's an example sentence: 你訂嗰啲嘢啱啱嚟咗，擺嗮喺嗰度喎。(The stuff you ordered just came, and [we] put them all there.)

[RyanChng]

With all due respect @kenlunde, I have to agree. In fact some write the 度 (location pronoun) as 喥, rendering the sentence as 你訂嗰啲嘢啱啱嚟咗，擺嗮喺嗰喥喎。

[RyanChng]

It’s more or less due to the fact that many Cantonese particles with unclear etymology are assigned phono-semantic characters with the right side indicating pronunciation and the left side standardising on the 口 radical.

[kenlunde]

Thank you, all, for this valuable information and details.

[orangeparanoid]

I don't know if the following issue with the shape of the upper part of 巴 in the characters 聲 and 絕 should be reported. In the screenshots below, you could compare the left and right squares or rectangles inside 巴 in the other two characters mentioned. 聲 and 絕 look odd because the squares or rectangles are not identical at font size 14 or small font sizes. At larger font sizes, they look as natural as the other characters. It is not easy to reproduce this issue. For your information,

[orangeparanoid]

To reproduce the issue of the character 絕:

[rschiang]

@orangeparanoid I believe it's more of Windows hinting problem. Take OS X for example:

They are rendered properly.

[kenlunde]

@rschiang is correct in that this is a rendering issue, not a glyph issue. Depending on the environment (OS or application), a different renderer may be used, and even if the same renderer is used, its settings may be different. This normally affects edge cases, meaning that if you look long enough, you'll find issues. That is the nature of fitting pixels to a grid, and it is not specific to Source Han Sans.

[orangeparanoid]

@kenlunde and @rschiang

On Windows, indeed, the characters of 絕 and 聲 look less odd, after (1) I changed the registry settings, (2) I disabled the ClearType option, and (3) I restarted the computer.

regedit:

HKEY_CURRENT_USER\Control Panel\Desktop

"FontSmoothingType" -> 0 "FontSmoothing" -> 0

Reference: http://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/disable-all-font-smoothing-in-windows-7-ie/f180e803-3317-4433-8fd2-63aadaecc2d2?auth=1

On Debian Linux, dpkg-reconfigure fontconfig-config Font tuning method for screen (system default): -> None Enable subpixel rendering for screen: -> Never Enable bitmapped fonts by default? -> No

I restarted the computer to get the desired display of the characters. Debian Linux displays these characters perfectly at any font size.

Reference: https://wiki.debian.org/Fonts

Maybe, it is good to list the information somewhere here:

Font installation instructions https://github.com/adobe-fonts/source-han-sans/blob/master/README.md

I couldn't figure it out without your advice. Thanks.

[kenlunde]

See Issue #120 for LE connection issues that affect some glyphs that use "⻐" or "⻠" as a component, such as 钮钵钯 and 饪. I looked at the master sources, and while the ExtraLight masters look okay, the Heavy ones have connections that are off by one or two units. This means that most of the five intermediate weights will exhibit this issue.

[hfhchan]

踎's 否 seems extremely compressed compared to other characters, expecially 鑽 who's phonetic component is more complicated. Also compare with 跨.

[cadaeic]

The glyph U+5C14 尔 is presented inconsistently. In Source Han Sans Simplified Chinese the glyph adopts the Japanese form as part of composite characters, contrary to prescribed practices in China. This is arguably a pressing issue as U+4F60 你 is a ubiquitous character in daily use, and the defect is highly visible (and jarring) with larger font sizes.

[kenlunde]

Thank you.

[orangeparanoid]

For 黃 ， 橫

In the table 通用规范汉字表

[jimmymasaru]

黄 黃 横 橫 They are encoded separately.

[kenlunde]

Thank you, @jimmymasaru. I was about to reply with the same information.