-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 glyph issues for characters with “番” #214
Comments
@tamcy I am thinking to unify these forms for TW and HK, using the disjoint form of 番, so please send to me—or add to this issue—a comprehensive list of affected Big Five and HKSCS code points at your earliest convenience. It seems that most of these will be TW glyphs that need 釆 and 田 to be separated. For U+5E61 幡, the HK glyph will change identity to become the TW glyph, which will be shared by TW and HK. |
Sure. Here lists the characters with the 番 component, categorized into 5 tables. Actions would be needed for characters in Table A-C. Table D-E are fine, and are included for completeness. (Table A-D are all Big5 codepoints, characters in table E are in HKSCS) Table A (22 characters)In this table, different glyphs are used for HK and TW, but their only difference is whether the center vertical lines of 番 appears joined. For characters of this type, I believe your workflow would be renaming the HK glyphs to TW and have them shared among HK and TW.
Table B (9 characters)The TW glyphs in this table needs to be modified to have the vertical strokes disjointed. Possible additional actions are on the second column.
Table C (1 character)For this single character, CN glyph can be used for TW. The TW glyph can be removed.
Table D (3 characters)HK and TW are shared with other regions, no action needed.
Table E (5 characters)Characters in the last table are HKSCS characters. They only have glyphs dedicated to HK, so no action is neccessary.
That's all. |
@tamcy: Thank you. The action for Table C is now reflected in the table at the beginning of Issue #203. Tables D and E require no action, as you stated. I appreciate the completeness. I will record the actions for Tables A and B in the appropriate consolidated issues later today, then will close this issue. |
I just changed the action for the glyphs in Table A. The TW CMap will be changed so that the affected code points map to the HK glyph (see Issue #202), and it won't be until Version 3.000 that the HK glyphs will be renamed to become TW glyphs (see Issue #227), meaning that TW and HK will share the TW glyphs. In other words, the HK glyphs will be unused from the upcoming dot release. |
Similar to #213 , this one is about how strokes of the standard glyph is interpreted, and the characters reported points to a larger issue.
First, the following 5 characters needs attention:
The bottom right stroke of 釆 is different from CN. HK could use the glyphs from TW, but I also found it is intentional to use a separate glyph set for HK because of a design difference from TW:
Looks like the interpretation is that the center vertical stroke of 釆 in TW should be joined to the center vertical stroke of 田, as if they are one single stroke. HK, similar to JP/KR/CN, uses a disjoint version.
Seems the decision is based on TW’s standard document. In 宋體 and 方體 (No. 102651) masters, the center vertical strokes do look joined.
In this case, 5 new HK glyphs would be needed for the above characters.
But I’d argue that the disjoint version could also be used for TW, and it's a design but not standard difference:
I believe you are already aware about this, as Source Han Serif also uses a disjoint version.
There're also glyphs with disjoint version in Big5 and HKSCS range due to glyph sharing. For instance, U+52EB 勫, U+9131 鄱 and U+98DC 飜.
In contrast, TW glyph of U+7FFB 翻 (joined version) is used by HK.
Honestly the issue seems subtle to me. Personally I'd like to see it unified (such that the disjoint version is used). I can provide a comprehensive list of glyphs concerned if you are to take action on this issue.
The text was updated successfully, but these errors were encountered: