Consolidation of Glyph Redesign Suggestions

[kenlunde]

This issue is meant for tracking and submitting suggestions for redesigning glyphs, meaning that the glyphs are technically correct in structure, but could benefit from adjustment in order to become more usable for more languages or regions, or simply for aesthetic reasons (see the note below).

Please do not use this issue to nitpick the typeface design. Keep in mind that there are 64K glyphs in this typeface, which provides a live's worth of nitpicking.

Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

• Adjusted the final stroke of the JP glyph for U+6C2B 氫, uni6C2B-JP, to be better balanced.
• Adjusted the right-most vertical stroke of the JP glyph for U+595C 奜, uni595C-JP.
• Adjusted the JP glyphs for U+3D93 㶓 and U+81F7 臷, uni3D93-JP and uni81F7-JP.
• Adjusted the JP glyphs for U+507D 偽 and U+70BA 為, uni507D-JP and uni70BA-JP, respectively, to be better balanced, and adjust the CN glyph for U+6E88 溈, uni6E88-CN, in the same way.
• Adjusted the TW glyphs for U+511A 儚, U+5922 夢, U+61F5 懵, U+750D 甍, U+858E 薎, U+85A8 薨, U+8609 蘉, and U+9138 鄸, uni511A-TW, uni5922-TW, uni61F5-TW, uni750D-TW, uni858E-TW, uni85A8-TW, uni8609-TW, and uni9138-TW, respectively so that their common Radical #140 component is more proportionate.
• Adjusted the TW glyph for U+7AC5 竅, uni7AC5-TW, so that the top and lower-left components are less wide.
• Adjusted the CN glyphs for U+596E 奮 and U+5957 套, uni596E-CN and uni5957-CN, respectively, so that at least the two middle horizontal strokes are the same length, though the top one may need to remain short.
• Adjusted the TW glyph for U+FF0C ，, uniFF0C-TW, by making its shape the same as the JP glyph, uniFF0C.
• Adjusted the CN glyph for U+FF1B ；, uniFF1B-CN, by making its comma component the same as that of the JP glyph, uniFF1B.

Post Version 1.001:

• Consider redesigning the glyphs for bopomofo per Issue #17
• Consider redesigning the TW glyphs that contain 辶 as a component per Issue #15.
• Consider adjusting CN glyphs for design consistency per Issue #29.
• Redesign the glyph for U+3025 〥, uni3025, to better match the glyphs for related characters, such as bopomofo.
• The counters of many CN and TW glyphs for ideographs are too wide.
• Adjust the 寺 component of the CN glyph for U+5D75 嵵, uni5D75-CN, so that its two parts do not connect.
• Adjust the TW glyph for U+FF0C ，, uniFF0C-TW, by shifting it slightly downward.
• Adjust the JP glyph for U+7B01 笁, uni7B01-JP, to have better balance and proportions between the top and bottom components.
• Adjust the TW glyph for U+85AA 薪, uni85AA-TW, so that the lower-right component is taller.
• Adjust the glyphs for U+3191 ㆑ through U+319F ㆟, uni3191 through uni319F, to be generic in terms of weight (see Noto CJK Issue #159)

[hfhchan]

Considering lengthening the last stroke of U+6C2B such that the character is better balanced. Original character on the left, demonstration on the right.

[hfhchan]

There is an hinting issue for 14249 which manifiests as uneven downward strokes at 27px, 42px, 47px, 55px, 60px, 76px etc.

The reason is likely because of an overlapping-but-subtly different alignment zone (in red):

The following is the glyph data extracted by otfccdump:

"stemH": [
    {"position":179,"width":30},
    {"position":443,"width":30},
    {"position":568,"width":29},
    {"position":690,"width":29},
    {"position":792,"width":32.5},
    {"position":794,"width":31}
],
"hintMasks": [
    {"contoursBefore":0,"pointsBefore":0,"maskH":[true,true,true,true,true,false],"maskV":[true,false,true]},
    {"contoursBefore":1,"pointsBefore":14,"maskH":[true,true,true,true,false,true],"maskV":[true,false,true]},
    {"contoursBefore":1,"pointsBefore":26,"maskH":[true,true,true,true,true,false],"maskV":[true,false,true]},
    {"contoursBefore":2,"pointsBefore":8,"maskH":[true,true,true,true,true,false],"maskV":[true,true,true]}
],

Corrected version:

"stemH": [
    {"position":179,"width":30},
    {"position":443,"width":30},
    {"position":568,"width":29},
    {"position":690,"width":29},
    {"position":792,"width":32.5}
],
"hintMasks": [
    {"contoursBefore":0,"pointsBefore":0,"maskH":[true,true,true,true,true],"maskV":[true,false,true]},
    {"contoursBefore":2,"pointsBefore":8,"maskH":[true,true,true,true,true],"maskV":[true,true,true]}
],

I also found very closely overlapping hstems on many glyphs, however they seemed not to cause any problems if the starting position was within 1 point. I also noticed that the starting shape for 豎撇 and 豎 were slightly different across glyphs. Lastly, the CN glyphs had the 豎 consistently 1 point higher than 豎撇, I do not know if this is some kind of compensation for an optical illusion or that SinoType was somehow aware of a hinting issue.

[kenlunde]

With regard to the JP glyph for U+595C 奜, uni595C-JP, it is targeted for removal in Version 2.000 to make way for HK glyphs, so this issue is likely to become moot. Still, I will mark this glyph to be inspected.

In any case, how hinting influences the pixels that are ultimately displayed depends on several factors, such as the rasterizer that is being used, and the pixel size of the glyph. This is no different than mainstream CJK fonts. Our fonts, including Source Han, are built using our auto-hinter, and is considered the best in the industry. Still, there will be cases where such behavior occurs.

Also, "alignment zones" has a special meaning, and for CJK glyphs, they are placed well above and well below the actual glyphs. They are useful only for Western-style glyphs whose letterforms are aligned to specific points along the Y axis, such as the baseline, x-height, and cap-height.

[hfhchan]

Last Dot for U+3D83 (㶃) can be a tad longer and ending more to the right so the character is better balanced.

[hfhchan]

U+3D93 JP glyph (CID 5118) is rather unbalanced compared to U+3D93 CN glyph (CID 5119) (a rare time where the JP glyph being the odd-ball instead of CN glyph).

U+81DF (CID 34062) for comparison.

Being ommitted from the regional-subsetted fonts, it seems that CID 5118 is a candidate for deletion in 2.000. However its source is from JA (Unified Japanese IT Vendors Contemporary Ideographs, 1993), which may warrant its inclusion, should there be enough space.

[hfhchan]

The last stroke for 34112 should be 提 instead of 橫.

Korea would benefit from this change, but the character is out of scope for SHS.

[kenlunde]

The JP glyphs for U+3D93 㶓 and U+81F7 臷, uni3D93-JP and uni81F7-JP, are candidates for removal in Version 2.000 because they're outside the scope of Adobe-Japan1-6. Still, I marked them for adjustment.

[KrasnayaPloshchad]

Consider adjusting CN glyphs for design consistency per Issue #29.

This comparison can be done via glyphdiff: https://www.v2ex.com/t/268649

[Explorer09]

Second ㇒ stroke in glyph 為 (U+70BA) (and related 偽 (U+507D), 溈 (U+6E88)) looks unbalanced and goes too right-hand side.

While Japanese people might get used to this style, Chinese and Taiwanese people do not. At least I would consider the "diving board" part of the third stroke (㇕) too long.

I would like to see the second (㇒) stroke be placed in a more balanced position, see SimSun's glyph, for example:

Strangely, the glyph of 媯 (U+5AAF) looks rather okay (for both Simplified Chinese and Traditional Chinese glyphs).

[kenlunde]

@Explorer09: Thank you. 為 U+70BA and 偽 U+507D have only JP glyphs that are shared with the other languages. 溈 U+6E88 has only a CN that is also shared with the other languages. I will ask the designer to tune these three glyphs so that are useful for more languages.

[Buernia]

Suzhou numerals for five〥(U+3025) needs to be redesigned, it don't have the same designs as others, seems to be smaller and thinner, likes the design of bopomofo.

[hfhchan]

The proportions the top of 28818 (U+77A2 TW) are rather unconventional; consider overwriting 28818 with the subpaths of 61705 (U+77A2 U+E0101 JP)

Edit:

8 other TW glyphs were identified which suffer from the same disproportionate "CJK RADICAL GRASS 3" component to varying degrees: U+511A, U+5922, U+61F5, U+750D, U+858E, U+85A8, U+8609 and U+9138.

[kenlunde]

@hfhchan The TW glyph for U+77A2 瞢 is best handled by removing it (see Issue #38), and by mapping U+77A2 瞢 in the TW CMap resource to uni77A2uE0101-JP (see Issue #37). The other eight TW glyphs are marked for adjustment.

[kenlunde]

@Buernia: Right. I agree that the glyph for U+3025 〥 is in desperate need for some typeface-designer love.

[hfhchan]

The top part of 30339 (U+7AC5 竅 TW glyph) is way too broad and the top of the left and right part 敫 is unaligned. The bottom left 方 is too broad (JP and CN glyphs are just right).

A general issue about 穴 being too broad exists in most of the TW glyphs, but U+7AC5 is a common character and the broadness is exceptionally out of place.

[Goodust]

I found some inappropriate or incorrect characters when I use "思源宋体“.

[kenlunde]

@Goodust: Thank you for the report.

For U+2CD9F 𬶟, that does look like a bug, especially because the Source Han Sans glyph matches that of HanaMinB and the Unicode code charts. I will confirm tomorrow by referencing 通用规范汉字表 (Tōngyòng Guīfàn Hànzìbiǎo), which is in my office (I am at home).

For U+2C7C1 𬟁, HanaMinB looks wrong.

For U+7808 砈, because it is a GE character and therefore not frequently used for Simplified Chinese, this will be deferred until Version 2.000, because an HK glyph will be added that can be also be used for CN (and TW).

[Goodust]

@kenlunde For U+2CD9F 𬶟,there's a screenshot of 通用规范汉字表 which you can refer to. For U+2C7C1 𬟁, I just mean the bottom of "鸟“ is too narrow so that the character looks uncoordinated. For U+7808 砈, I agree with your suggestion. Have a good Day~

[tamcy]

The last stroke of 承 (U+627F) in TW (19114) can be extended. In fact it should be ok to map to CID19113 so that four regions share the same glyph.

1. The left and right components in 承 and 丞 are the same historically.

2. As shown in MoE's stroke order learning website, the rightmost component of 承 consists of 2 strokes. It looks like a one-stroke component just because the last stroke is compressed.

3. Thus, the design of the component should be consistent with that of other similar glyphs. No need to use a separate deign for 承. The current design look unnatural.

[tamcy]

Horizontal strokes at the middle of 奮 and 套

The 隹 component in 奮 and 镸(upper part) in 套 have 4 horizontal strokes. When written, the length of these strokes would be: D > A > B = C.

In situations like 奪 and 套, A is shortened to accommodate to fit better with the last stroke of 大. However, current CN glyph tends to adjust the length so that A < B < C < D, resulting in a slope. This looks a bit weird.

I suggest to follow the design of JP/KR such that B and C are of the same length. A can also be widened to make it closer to B and C.

奮, which looks good for CN, is also included for comparison.

[hfhchan]

Figure: CN / TW / JP / JP-transplanted-on-TW

34952 (U+8388-TW) could have an instant facelift by transplanting the bottom part of the JP glyph (34950) right on top of it -- before 34950 is removed in version 2 ;).

[kenlunde]

@Goodust: I decided to add a CN glyph for U+7808 砈, uni7808-CN, which will be repurposed for HK in Version 2.000 (and in TW for the first dot-release). I am doing this to avoid not having to special-case a HK glyph for CN use (this is based on how my process works for building the CMap resources for each language).

[kenlunde]

@tamcy: About U+627F 承, its TW glyph, uni627F-TW, has been flagged for removal for Version 2.000, but U+627F 承 will map to uni627F-JP in the TW CMap resource for the dot-release.

[kenlunde]

@tamcy: The issue with the relative lengths of the horizontal strokes of 隹 and 镸 seems to be an explicit design decision on the part of SinoType to avoid horizontal stroke A from touching the last stroke of the 大 component.

[tamcy]

@kenlunde Yes, what I questioned is whether it is necessary to make B and C different in length. 套 in CN/TW looks strange because C is obviously longer than B. I would like to propose to follow the way in JP/KR glyphs, such that the equal length of B and C is always maintained.

[kenlunde]

@tamcy: I added a note for our designer to look at the CN glyphs for U+596E 奮 and U+5957 套, and to at least make the middle two horizontal strokes the same length.

[tamcy]

I would like to suggest some tweaks to the full-width comma (， U+FF0C) specific to TW region.

When viewed from a distance, the middle dot doesn't look smooth, and the right side looks as if it has been trimmed. I hesitated to report this as the design rhymes with the Latin half-width punctuation, even though it looks somewhat awkward in the Chinese-reading context (it could be just me though).

Interestingly, the JP/CN/KR version of the same glyph looks smoother, and more comfortable to read. Also, the full-width semi-colon, shared by four regions, is more alike to JP/CN/KR's full-width comma. This makes me think if similar changes could be done to TW's full-width comma. Thanks!

[kenlunde]

@tamcy: I agree, but mainly on the grounds that the comma component should be the same in full-width glyphs that include it. You missed the CN glyph for U+FF1B ；, uniFF1B-CN, which would require the same adjustment. I will consult with the designer today.

[kenlunde]

The image below includes the JP, CN, and TW ideographs that were redesigned (also included are those glyphs that were corrected):

[kenlunde]

Not shown above is the small number of adjustments and corrections to glyphs that correspond to Adobe-Japan1-6 kanji, six in total.

[tamcy]

I think the 日 of the 音 component in U+95C7 闇 looks a bit too fat.

[kenlunde]

@tamcy: U+95C7 闇 is lumped together with my The counters of many CN and TW glyphs for ideographs are too wide. note at the beginning of this issue.

[hfhchan]

I'm trying very hard to avoid reporting design issues, but the 犬 for the TW glyph of U+7A81 is definitely too "high":

P.S., the KR glyph seems a bit too "low" to me, but I may not be in a good position to judge.

[jimmymasaru]

嵵 does not comply with others. 土 and 寸 should not fully touch.

[jimmymasaru]

陟 (uni965F-CN) needs tweaking because the 豎 of 𣥂 is too far from the last 丿 and too close to the 止.

[jimmymasaru]

These glyphs are all mapped to CN. It seems like the component 名 does not conform to each other. Some characters have the 口 intruding 夕 while others don't.

[jimmymasaru]

角 (CN), especially when it's in a narrow form, are not consistent.

I can understand for some characters like 解 (uni89E3-CN), the left side is too narrow so that the last stroke 丨 has to give some space to 亅 and this design is pretty good. It seems to me that a threshold of the width of 角 is a key point of solving such inconsistencies. If we use the width of 角 in 解 as a threshold, other characters that have a narrower width of 角 should all adopt the design of 角 in 解.

I hope these issues are not nitpicking.

[tamcy]

The heaviest weight of 髓 (uni9AD3-TW) obviously needs some love.

[tamcy]

It's TW's comma glyph (uniFF0C-TW?) again (sorry for not raising this with my last report). It looks like the glyph is vertically aligned to the center mathematically, but optically it appears shifted upward, probably because the black dot is visually heavier. This also causes a less-optimal result when typesetting with English characters, as you can see with the following screenshot, when English word "Google" is followed by the full-width comma. Please consider shifting the glyph down (in horizontal typesetting). Thanks.

[1abcd]

在「數」下方的「女」的橫筆不需要上提，就跟「樓」底下的「女」一樣。 Horizontal stroke of 女 which is under the 數 doesn't need to be slanted. It is just like the same component under the 樓 keeping horizontal. The problem can be found in 思源黑體 TC and 思源宋體 TC.

I try to find other characters that contain 婁 component: 櫢籔擻藪䣚㪹鷜氀甊䫫 𨯃𤻺𠐍𡂡𧁾𡾄𣀟𩪵𧔅𥖻𩽋𪈜𡢺𡰍𠞭𣤋𩀮𢿙𢿘𧢃𤬏𡰓𡗆𩖅𣰟

[hfhchan]

Currently it is a horizontal slant upwards in the CNS11643 standards: http://cns11643.gov.tw/cgi-bin/ttf2png?page=1&number=6d30&face=sung&fontsize=480

However, it is a horizontal stroke in the MOE 國字標準字體宋體母稿: http://language.moe.gov.tw/001/Upload/files/SITE_CONTENT/M0001/SUNGTI/as16.htm

@kenlunde do you reckon I should inform TCA of this issue?

[kenlunde]

I have slightly more trust in the Taiwan MOE standards, so I'll mark the TW glyph for U+6578 數, uni6578-TW, to be fixed in both Source Han families. Also, the Kangxi dictionary uses a horizontal stroke.

@hfhchan: You can certainly inform TCA of this issue, but it's likely to be lost in the noise from all of the other outstanding issues in the CNS 11643 standard.

[hfhchan]

U+64FB, U+7C54 and U+85EA probably need similar treatment.

[kenlunde]

@hfhchan: The two relevant Taiwan MOE glyph standards agree:

[hfhchan]

This could be an inconsistency in MOE's original designs, as 魏 has a stroke upwards:

@hfhchan: You can certainly inform TCA of this issue, but it's likely to be lost in the noise from all of the other outstanding issues in the CNS 11643 standard.

@kenlunde Nevermind then ;)

[hfhchan]

The J-source glyph (needed for G-source) for U+7B01 could do with some love ;)

[tamcy]

ping @kenlunde for the TW glyph issue of 髓 reported earlier. It hasn't been listed so I'm afraid that it's missed. The last stroke of the 辶 component seems lengthened by mistake, it shouldn't be that long.

[kenlunde]

@tamcy: U+9AD3 髓 got lost in the noise, and was just added to Issue #39 as it is a genuine glyph error in the Heavy master, and is manifested in the intermediate weights.

[hfhchan]

The connection point of 龰 in 走 is not consistent in PRC's glyph forms (4th stroke immediately below 2nd stroke or shifted to the right), nor is the gap between 土 and 龰, especially between URO and Extension A:

The same issue also occurs in the JP glyph, but I do not know if that is the expected design.

It is suggested that the connection point style be unified across the same language and maybe across languages.

Given Source Han Serif's serifs being more horizontal than slanted, it may be better to omit the serif altogether. It is suggested that the form seen in Extension A be applied to all glyphs in URO.

[kenlunde]

We're well aware of this inconsistency, and it will be addressed, but likely as part of the Version 2.000 update as some of the issues will be addressed through glyph-sharing.