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

HK & TW glyph issue for U+9ED5 黕 and U+9EE0 黠 #136

Closed
tamcy opened this issue Nov 20, 2021 · 6 comments
Closed

HK & TW glyph issue for U+9ED5 黕 and U+9EE0 黠 #136

tamcy opened this issue Nov 20, 2021 · 6 comments

Comments

@tamcy
Copy link

tamcy commented Nov 20, 2021

Version: 2.000

u9ED5,u9EE0

The circled region indicates a stroke type difference between CN and HK/TW.
For U+9ED5 黕, the JP glyph could be used.
For U+9EE0 黠, a new glyph would be needed.

@punchcutter
Copy link
Member

There is already a TW glyph for U+9EE0 that has been restored. There is also a TW glyph for U+9ED5, but it's not that much different from the JP which is why it was dropped.
9ED5-TW-JP
Here is TW on left and JP on right. I feel like the TW glyph looks better overall.

@tamcy
Copy link
Author

tamcy commented Nov 22, 2021

As I am not a typeface designer I am not in a good position to comment on this, but also I agree that the TW glyph looks better, mainly because of the placement of the four dots 灬. But it would still be fine to use the current JP glyph if the designer doesn't agree to replace it with the TW one. I say this because the stroke above that 灬 isn't consistent in JP, and it seems to me that the JP glyph designer tends to preserve the same flow of the four dots (灬) no matter which stroke type is used above that 灬:

jp

And it doesn't seem to worth allocating a new CID just for this difference 😄.

@punchcutter
Copy link
Member

Definitely not saying we should add both the TW and JP. Just using one is fine. Easiest right now is to map TW/HK to the existing JP.

@Marcus98T
Copy link

Marcus98T commented Dec 6, 2021

Sorry if I commented quite late, but I kinda felt the CN glyph for 黕 should have been the JP glyph, but adjust that 冘 component such that the last stroke 乚 is closer to 丿, like the other "JP" glyph, then afterwards can remap to JP, KR and CN. Anyway, unless I am wrong, I think there's nothing that says the 乚 must not touch the 丿 for CN/TW/HK.
Screenshot 2021-12-07 at 01 24 54

Then either no need to restore the v1 TW and map that current "JP" to TW/HK, or restore the other v1 TW form and drop the old "JP" glyph.

EDIT: While I admit this is going off track, I found out CN/TW/HK of 冘 in Sans is the same as the JP/KR version. If so drop the CN glyph of 黕 and map the JP version to all locales, for Sans.

Screenshot 2021-12-07 at 01 31 43

Then for Serif, for 冘, drop the CN version and map the JP to all locales.

Screenshot 2021-12-07 at 01 32 23

For both Sans and Serif, 沈 is the same for all regions. Then I found out, for Serif, the v1 JP version was somehow removed. I'd rather restore it, replace the CN glyph and map it to all locales.

Screenshot 2021-12-07 at 01 37 43

Since I went off track, this will be a whole new issue concerning 尢, 尤 and 冘, if I have time, I might open up a new one (on both Sans and Serif issue pages) within the coming week or two on what needs to be unified, what needs to be restored, and that IMO the JP aesthetic of 丿 and 乚 touching is preferable for all regions.

There is already a TW glyph for U+9EE0 that has been restored. There is also a TW glyph for U+9ED5, but it's not that much different from the JP which is why it was dropped. 9ED5-TW-JP Here is TW on left and JP on right. I feel like the TW glyph looks better overall.

And if the v1 TW glyph for 黕 should be restored (the left component also looks better), as I said before the 冘 should be adjusted to match the JP aesthetics.

@tamcy
Copy link
Author

tamcy commented Jan 27, 2022

Fix to U+9ED5 黕 and U+9EE0 黠 confirmed in v2.001 release, thanks!

@tamcy
Copy link
Author

tamcy commented Jan 28, 2022

I am closing this as @Marcus98T has his own issue about this in #148.

@tamcy tamcy closed this as completed Jan 28, 2022
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