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

Problem with Sans JP: 陋 U+964B is incorrect #571

Open
NightFurySL2001 opened this issue Apr 7, 2024 · 1 comment
Open

Problem with Sans JP: 陋 U+964B is incorrect #571

NightFurySL2001 opened this issue Apr 7, 2024 · 1 comment

Comments

@NightFurySL2001
Copy link

Reported in #556 (comment) but separated to prevent tracking TC and JP together in an issue.

陋 U+964B at Adobe-Japan1 CID+7094 is incorrect for JP presumeable copied from Source Han Sans which has the same problem.
image

Adobe-Japan1:
image

@NightFurySL2001 NightFurySL2001 changed the title Problem with JP: 陋 U+964B is incorrect Problem with Sans JP: 陋 U+964B is incorrect Apr 7, 2024
@SCLu17
Copy link

SCLu17 commented Apr 9, 2024

This seems to be a non-issue where Japan allows for design variances in terms of stroke directionality (Agency for Cultural Affairs, Jōyō Kanji Hyō, “Regarding Mincho Designs”, p. 3 and relevant example in “3 (5)”, p. 5). Comparing different Gothics, we can see the last stroke of the 丙 component isn’t standardized across different typefaces (glyphs which use the 丶 form are highlighted with a black dot underneath):
rect3
The Plex designers seem to be using Kozuka Gothic/Source Han Sans as a reference.
Even if the designers are following Adobe-Japan1 forms (which uses Kozuka Mincho for its representative glyphs), Adobe’s own documentation states that the glyphs are meant as references, not standards, i.e. there is no need to strictly adhere to the above forms, which brings me back to the Japanese government’s comment on typeface design variations.
As this is a permissible design variation, it would be excessive to label the design as “incorrect”. Consistency in the 丙 component (one form or the other) is optional and shouldn’t be prioritized.

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

2 participants