Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remap suggestion for glyphs with TW and HK only to switch to HK for JP, KR, CN #443

Open
NightFurySL2001 opened this issue Jul 26, 2023 · 8 comments

Comments

@NightFurySL2001
Copy link

It might be better to map JP, KR and CN glyph of U+6779 杹 to HK instead of TW. Also there is a CN glyph in Serif, but seems to be removed in Sans.

image

@Marcus98T
Copy link

Marcus98T commented Jul 26, 2023

I think honestly it's much better to just restore the v1 JP glyph and map it to JP, KR and CN.

Screenshot 2023-07-26 at 23 42 39

Besides, this is a G3 character, not GB Extension, so while it's not part of the super basic standards, it may still be needed to ensure it follows PRC glyph conventions.
Screenshot 2023-07-26 at 23 44 21

Also, 沎 (U+6C8E) has this issue as well. G5 character. Likewise, restore the v1 JP glyph.

Screenshot 2023-07-26 at 23 51 54 Screenshot 2023-07-26 at 23 53 12 Screenshot 2023-07-26 at 23 56 18

@NightFurySL2001
Copy link
Author

U+6579 敹 can probably get a remap from TW to HK for JP, KR and CN too.
image

@NightFurySL2001 NightFurySL2001 changed the title Remap suggestion for U+6779 杹 Remap suggestion for glyphs with TW and HK only to switch to HK for JP, KR, CN Aug 6, 2023
@Marcus98T
Copy link

Marcus98T commented Aug 6, 2023

Well, as pointed out in the list of hanzi showing only TW forms, there’s even more that could be mapped to HK, given the scope of what this issue is about.

Here is the complete list of Hanzi which could be mapped to HK forms for JP, KR and CN, based on the link above. It only applies to Sans, but I have since made a separate issue in Serif with a mention of your issue in the section "CN glyphs showing TW/HK forms".

  • U+505D 偝 (G5 source)
  • U+50E0 僠 (GB Extension source) (Well there's another problem where TW is using the HK glyph and JP, KR and CN are using the TW glyph. Suggest to remove the TW glyph and restore the v1 JP glyph for the latter three locales.)
  • U+64EB 擫 (G5 source)
  • U+6579 敹 (G3 source)
  • U+6779 杹 (G3 source)
  • U+6820 栠 (G5 source)
  • U+6B76 歶 (GB Extension source)
  • U+6C8E 沎 (G5 source)
  • U+6FBF 澿 (G5 source)
  • U+7128 焨 (GB Extension source)
  • U+715F 煟 (G5 source, also a Tongyong character)
  • U+7181 熁 (G3 source)
  • U+7182 熂 (G3 source)
  • U+7203 爃 (G5 source)
  • U+72C5 狅 (G3 source)
  • U+7BFB 篻 (G3 source)
  • U+7CD0 糐 (GB Extension source)
  • U+815C 腜 (G3 source)
  • U+8215 舕 (G3 source)
Screenshot 2023-08-06 at 20 49 17 Screenshot 2023-08-06 at 20 49 24 Screenshot 2023-08-06 at 20 49 35 Screenshot 2023-08-06 at 20 49 45 Screenshot 2023-08-06 at 20 49 55

But seriously, as I said before, I would rather have Adobe restore the v1 JP/CN glyphs for all these characters (and whatever else is in the list which I linked above) to ensure that they follow PRC glyph conventions. Most of them are G3 or G5 characters, not so much GB Extension. Then this issue will be considered moot as there won’t be a need to use HK forms for JP, KR and CN.

But let’s say, in the worst case scenario, if Adobe deem those minor regional differences like the top 人 radical (and subsequently the left 金 radical), the top 竹 radical, 丷 (as in 豆, 羊, etc.), 子 and 戶 non-unifiable, and because of this, there's virtually no room for restoring the v1 JP/CN glyphs, then use the HK glyphs. But I do not want this kind of scenario.

I rest my case.

@NightFurySL2001
Copy link
Author

夗 although kind of out of scope, can map the TW glyph to JP/KR for the 夕 component.
image

@Marcus98T
Copy link

Marcus98T commented Sep 25, 2023

抇 (U+6287) should use the HK glyph for CN as the closest approximation of the Unicode reference. Does not apply to JP and KR.

Screenshot 2023-09-25 at 23 36 02 Screenshot 2023-09-25 at 23 36 11 Screenshot 2023-09-25 at 23 36 49

I also mentioned this in my Serif issue about CN glyphs showing JP/TW/HK forms under the section "CN glyphs showing TW/HK forms".

And finally, I request to adjust the 曰 component (make it slightly taller in proportion) in the HK glyph, so it doesn't look too weird. Applies to both Sans and Serif. I note that sometimes the reference typefaces in the Unicode charts may not look professional.

Likewise, I also noted there was no v1 JP glyph in Serif, but there is a JP glyph in Sans which looks better designed. Maybe in the next major version of Serif, a JP glyph can replace the TW glyph for JP, KR and TW.

EDIT: After feedback as seen in the reply below, see this issue.

@tamcy
Copy link

tamcy commented Oct 11, 2023

The height of the 曰 component in uni6287-HK looks fine to me (both serif and sans). For serif, the design of 抇 also rhymes well with 汩 (U+6C69. not 汨 U+6C68).

image

It is actually the 曰 component in Sans version's uni6C69-CN that looks a bit too tall.

image

Also, from the code chart, unlike U+6C68 and U+6C69, it looks like different components are chosen by different sources for U+6287.

comparewithlegend

VN: 扌日 for U+6287; 扌曰 for U+22A8F.
KR: 扌日 in U+6287 (i.e. the same as VN); does not include U+22A8F
TW: 扌曰 for U+6287;扌日 for U+22A8F (i.e. the opposite of VN).
HK: 扌曰 for U+6287 (i.e. the same as TW but with a different design for 曰); does not include U+22A8F.
CN: Not sure.

Thus, if there are really something that needs to be done, I'd suggest the followings be considered for Sans:

  1. The current uni6287-HK is modified from uni6287-JP. Technically 曰 should be a wider component compared to 日, so make 扌 narrower in width and make 曰 wider.
  2. Create uni6287-TW from the adjusted uni6287-HK, make the middle horizontal line in 曰 connected, and replace uni6287-JP.
  3. Modify uni6C69-CN and make the 曰 component shorter.

Sounds a bit complicated here, but the idea is to make Sans follow the setting of Serif.

sun

@NightFurySL2001
Copy link
Author

Related for uni6C69-TW: #454.

@Marcus98T
Copy link

Marcus98T commented Oct 11, 2023

I guess after the feedback from @tamcy, and not to mention having to update 汩 (U+6C69) for the new CNS standard, I have opened a separate issue regarding this design discrepancy as this issue is originally about remapping.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants