adobe-fonts / source-han-serif

Source Han Serif | 思源宋体 | 思源宋體 | 思源宋體 香港 | 源ノ明朝 | 본명조
https://adobe.ly/SourceHanSerif
Other
8.17k stars 644 forks source link

Consolidation of Mapping Change Suggestions #37

Open kenlunde opened 7 years ago

kenlunde commented 7 years ago

This issue is meant for tracking and submitting suggestions for mapping changes, meaning that a character might be better mapped to a different but existing glyph. Note that mapping changes, especially for ideographs, will trigger changes to GSUB features, such as the language-specific lookups of the 'locl' GSUB feature. Because tools are used to build the language-specific lookups of the 'locl' GSUB feature by using the CMap resources, such suggestions cannot be accepted as pull requests, and should instead be posted here. Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

Post Version 1.001 Mapping Changes:

hfhchan commented 7 years ago

image Though they are out of the scope for the TW subset, the JP glyphs for U+77D2 and U+61DC could be used for the TW locale, similar to Issue #26 and #32.

kenlunde commented 7 years ago

@hfhchan: Because this is easy to do, it shall be done.

tamcy commented 7 years ago

u 8019_803b_tw

Incorrect mapping for U+8019 耙 and U+803B 耻 in TW. Both should look the same as the JP/KR glyph.

kenlunde commented 7 years ago

@tamcy: Noted. Thanks! (Also, while U+803B is outside the scope of the TW coverage, the fix is easy and shall be done.)

tamcy commented 7 years ago

Seems that U+9EFD 黽 is incorrectly serving CN glyph (CID 48026) in JP font with language set to "zh-tw". The language specific version SHSerif-TW uses the correct glyph which is CID 48025. Looks like an issue similar to #43?

kenlunde commented 7 years ago

@tamcy: Yes, it is similar to #43, and the solution is to map U+2FCC ⿌ to uni9EFD-JP (CID+48025) in the TW CMap resource.

hfhchan commented 7 years ago

image

The TW glyph for U+5225 should use that of the JP glyph. It is customary for the bottom left component to be joined upwards in the Code Charts, and the overall shape of 11202 looks too wide for TW/HK customary use.

The TW glyph for U+8382 and U+3B6D could borrow the JP glyph as well, since the bottom left protrusion is considerably closer to conventions.

kenlunde commented 7 years ago

While these mapping changes are relatively easy to implement, you missed the deadline for the dot release, given the extraordinarily large number of moving parts that are involved. These will need to wait for a subsequent release.

kenlunde commented 7 years ago

@hfhchan: I am willing to map U+3B6D 㭭 and U+5225 別 to uni3B6D-JP and uni5225-JP, respectively, in the TW CMap resource, but not U+8382 莂, mainly due to the inappropriate radical shape, which is far more striking.

hfhchan commented 7 years ago

@kenlunde, isn't the JP glyph and CN glyph for U+8382 equally inappropriate for TW? Changing the fallback to JP glyph instead of CN would not introduce more inappropriateness, as far as I can tell...

kenlunde commented 7 years ago

@hfhchan: Exactly, which is why I suggest leaving the mapping as-is unless a significant number of people also support the change.

tamcy commented 7 years ago

Incorrect lookup data for U+90CE 郎 in JP and KR OTCs. When tagged in TW or CN, the font should substitute CID 41693 with CID 41694, but CID 41717 is incorrectly served as indicated in the jp2cn and jp2tw tables.

shserif-u90ce

kenlunde commented 7 years ago

@tamcy: I torpedoed my earlier reply, because the situation is quite complex, and involves KS X 1001 and GB 18030.

U+F92C 郎 (its canonical equivalent is U+90CE 郎) is a GB 18030 character, and its representative glyph is the same as uni90DE-CN, meaning with the extra stroke, so its code point maps to that CN glyph. U+F92C 郎 was a KS X 1001 character. Its K source was moved to U+FA2E 郞 with U+90DE 郞 being its canonical equivalent.

Because this will be addressed after the Version 1.001 update, I will give this some more thought. The work-around, especially if you're using the OTCs, is to explicitly select the CN font in the OTC.

hfhchan commented 7 years ago

Consider removing jp glyph for U+85F2:

image

kenlunde commented 7 years ago

The JP glyph for U+85F2 藲, uni85F2-JP, is already a candidate for removal.

Jstamz commented 3 years ago

Glyph001 I found 12 KR glyphs of version 1.001 which are quite different to those in common Korean fonts. (함초롬바탕/HCR Batang: The default font of Hangul word processor) (HY 신명조, HY 견명조: Those fonts are common serif fonts, bundled in MS Office/Hangul Office) (나눔고딕: Popular free sans serif font) (한양해서: Widely used Regular script font in Korea)

I suggest to remap 8 of 12 glyphs above: 咎(u+548e), 嗤(u+55e4), 憊(u+618a), 潤(u+6f64), 竇(u+7ac7), 續(u+7e8c), 讀(u+8b80), 隙(u+9699). (Reason: Those glyphs are minor variants in Korea)

(1) I think the mapping for this character is referring to an incorrect glyph (I didn't see any other fonts render 潤(⿰⺡閏) as ⿰⺡⿵⾨壬. Comparing 潤[⿰⺡⿵⾨壬] to 閏[⿵⾨王] in the font, one could easily find the difference.) 潤(u+6f64): KR -> JP (*I think the KR glyphs for U+6F64 is both incorrect in Source Han Sans and Source Han Serif)

(2) KR glyphs for these characters are rarely used in Korea; JP glyphs is more often, widely used and similar to the traditional glyph. (These characters are phono-semantic compounds; the common phonetic component is 𧶠, not 賣.) 竇(u+7ac7), 續(u+7e8c), 讀(u+8b80): KR -> JP

(3) These KR glyphs are not rare, but are minor variants. 咎(u+548e): KR -> JP 嗤(u+55e4): JP -> CN 憊(u+618a): KR -> JP 隙(u+9699): KR -> JP