-
Notifications
You must be signed in to change notification settings - Fork 574
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
Issues and Suggestions for Sans TC #556
Comments
@Buernia The 丙 component in JP is intended and expected, Adobe-Japan1 has such differentiations by default. Only 陋 is incorrect for JP presumeable copied from Source Han Sans which has the same problem. For TC however, either form is acceptable. The JP dot form can be copied over to TC, or just edit the individual 丙 character. For 豕 component, the JP form is acceptable by TC communities and may be directly copied over for minimal difference between JP and TC (if intended) and more traditional printing form. This is however quite a big edit compared to the 示, and 羽 components listed in the first comment,. |
Considering most of 豕 components use the new form, It would be more appropriate to modify 蕤 only. |
囪部件未修改 |
IBM just took the TC fonts down. They had determined that the total file size for all the Plex fonts is too big for npm, so they are trying to work around the problem. However, you may still be able to download the fonts here, as I was able to find them when checking the commit history. They will put them back up shortly once they figure out a solution, and maybe the Simplified Chinese version can follow afterwards. EDIT: Just saw the exact reason why they took the fonts down and corrected my post. |
As per @BoldMonday's request, I am reposting a minor interpolation bug of 進 (U+9032) in the TC version here, for organization purposes. It is unfortunately inherited from the JP version. I suppose during the development of the TC font, it was simply overlooked. |
@cathree3 This was already mentioned earlier. Please read the previous posts carefully before posting a duplicate issue, unless you also want to talk about the uneven spacing between 𱼀 and 壬 in 望 (U+671B), which I find isn't a big deal.
You can also check to see if the character you want to report is already reported in the GitHub issue search bar, or use Ctrl+F. |
@BoldMonday @mjabbink may I ask what's the current status of Plex Sans TC? Will it be re-released in GitHub repo again soon? |
Would like to throw in my own 2¢ here regarding the 舌 component as mentioned here: 𠯑 (⿱ 氏口) gradually borrowed the 舌 form but retained the 丿 stroke at the top, whereas 舌 was originally horizontal at the top, but gradually used a slant stroke in handwriting. Modern HK and TW handwriting guidelines distinguish between the two, not from an arbitrary standpoint, but from a real lexicographical difference going back to the Shuowen Jiezi (small seal script), even if that distinction had become obscured over time. As the original comment said, Plex currently does indeed implement this inconsistently, but I disagree that it should be unified to LiHei’s forms, which takes more inspiration from vulgar forms and is contrary to the guiding principles Plex TC seems to be following. |
After a brief review of the TC font, there are a few additional issues I’ve found as of v1.000. I’ve categorized by them by order of urgency. Incorrect glyph shapes (beyond known variances in CN/JP/KR)
Major inconsistencies (immediately noticeable with forms unfamiliar to TC users)
Inconsistencies (compared to other glyphs sharing the same components, based on which component variant is used the most)
Miscellaneous changes
Suggested additions
|
Thank you all for the feedback. The Sandoll design team is addressing much of what is noted above. We have a new workstream that will address the consistency details, among others, and add new glyphs to meet new standards/requirements. |
FYI @Sandoll-DS |
As much as I love the traditional/conventional forms suggested here, wouldn’t you think it’s too much for a font foundry to follow? If there isn’t an established “traditional form” standard, I doubt IBM or Adobe would ever implement these requests as they cannot justify these design choices. I’d like to suggest to narrow this thread to apparent errors and standard non-conforming mistakes. |
@rschiang the suggestions raised are mainly because IBM Plex TC is expected to be used cross-regionally, and some of the current forms would be perceived by users as incorrect outside of Taiwan (mainly for 黃,善 and 辥). They are used in Taiwan too outside of educational system. The suggestion is also made only when it is easy to do so: most of the suggestions are to revert TC glyphs back to JP. The design choices have already been made in JP, and keeping TC partly consistent with JP is more maintainable than requiring separate glyphs for TC. Also noted that some suggestions are the representative glyphs used in Adobe-CNS1 that the font follows. |
Thank you for providing the TC community with such a great font! However, there are some significant issues and some personal suggestions that I hope Plex can resolve in the next release.
It seems that the character set of this font is based on Adobe-CNS1-7, so the CIDs are included for reference.
Glyph errors
CNS11643 error
The following are glyph errors from the CNS11643 standard that should be fixed immediately. The sample pictures are shown with IBM Plex Sans TC Bold (on top/left) and Source Han Sans Regular (on bottom/right). A copy of Unicode code charts is attached.
黃 component
黃 U+9EC3 and its related components are using the Taiwan MOE form with the center part using 田 with no protrusion, instead of 由 with a protrusion on top, which is not used in any Traditional Chinese communities before its introduction by Taiwan MOE. This form is more prone to be identified as incorrect especially for Traditional Chinese communities in Hong Kong SAR, Macau SAR, Singapore and Malaysia where the more popular form is 由. Some Taiwan font foundries also used 由 form.
For maximum cross-regional compatibility, 黃 U+9EC3 and its related components should be changed to use 由 with protrusion. Around half of the glyphs can be copied over from Plex Sans JP which has the correct form, and the rest just need slight modifications to pull the vertical stroke up.
List of characters:
嚝壙嫹廣彉懭撗擴斢曠橫潢瀇熿爌獚獷璜矌磺礦穔穬簧纊蘣蘳蟥趪鄺鷬黃黈黌
Shown below TC on top and JP on bottom.
Suggest to change handwritten components to existing printing orthography
祺 U+797A/CID+3753 has a different 示 radical shape than the rest of 示 radicals. It would be wise to unify them. My personal suggestion is to copy the JP traditional form used by 祺 U+797A over to the rest of TC (as explained in the next section).
餤 U+9924/CID+11519 has a different 飠 radical shape than the rest of 飠 radicals. It would be wise to unify them. My personal suggestion is to copy the JP traditional form used by 餤 U+9924 over to the rest of TC (as explained in the next section).
随 U+968F/CID+15326 and 遷 U+9077/CID+4683 only have a single dot for ⻍. 遷 U+9077 should also have a 㔾 instead of 己 copied from JP. It would be wise to unify them directly with 2 dots as 2 dots are in line with traditional printing orthography.
Other miscellaneous not unified components
Someone probably modified 邊 U+908A/CID+5593 wrongly. on the right shows a similar character in TC, and bottom are JP. 邊 U+908A can be reverted back to JP directly (shown bottom).
Same goes for 邋 U+908B/CID+5594. The middle should be 4 slanted dots, not 4 horizontal lines.
Also 邋 U+908B/CID+5594 and 鬣 U+9B23/CID+5968 should have a 㐅 inside, not 人.
Same goes for 益 U+76CA/CID+2370. The middle right should curve downwards, not upwards. This glyph can be reverted back to JP directly (shown on right). Additionally, 謚 U+8B1A/CID+11883, 鎰 U+93B0/CID+5446 and 鷁 U+9DC1/CID+13142 have disconnected middle strokes and should be unified to connected form similar to others.
薇 U+8587/CID+5218 has a different 微 compared to other components. Probably copied from JP.
籍 U+7C4D/CID+5676, 藉 U+85C9/CID+5407, 耥 U+8025/CID+18237, 耱 U+8031/CID+18239 and 耯 U+802F/CID+14228 have the same problem. The first stroke of 耒 on (bottom) left should curve up.
夅 U+5905/CID+17817. Bottom 㐄 should have a right-angle instead of slanted.
Suggestions
Orthography
The following are components that IBM Plex may consider to use for TC characters as they are more aesthetically pleasing, are still in prevalent modern uses, and fits the Grotesque design of the IBM Plex while maintaining the machinery features. All components below are with the hint of traditional orthography, and their design can be made to be more geometric and align with IBM Plex Sans.
These designs are also already in use in Sans JP, which most of them can be directly copied over into TC with minimal effort. I do recognise since the glyphs are already made, there will be some effort needed to redo them, but it will be very nice to have more printing forms in the font. I'm not sure about the contribution guidelines for this project, but if possible I can make the required glyphs for update.
示 radical may choose a two horizontal line + 3 (nearly) vertical line instead of a slanted stroke with white counter. This is already in use in TC 祺 U+797A and some of JP.
To adjust:
榊礻礼礽社礿祀祁祂祄祅祆祇祈祉祊祋祌祏祐祑祒祓祔祕祖祗祙祚祛祜祝神祠祢祣祤祥祧祩祪祫祰祱祲祳祴祹祺祼祽祾祿禂禃禆禇禈禊禋禍禎福禐禑禒禓禔禕禖禗禘禙禚禛禝禟禠禡禢禤禥禧禨禩禪禫禬禭禮禰禱禲禳禴禶禷視视䄂䄃䄄䄉䄎䔃𡁜𡅏𥘵𥙑𥚃𥚕𥛣𥛶𥜝𥜥
飠 radical may choose the bottom with two horizontal line instead of one with white counter. Same as possible to replace with JP.
To adjust:
籂蝕飠飢飣飥飦飩飪飫飭飯飲飴飵飶飹飼飽飾餀餂餃餅餇餉餌餎餑餒餓餔餕餖餗餘餙餚餛餜餞餟餡餤餧館餩餪餫餬餭餯餰餱餲餳餵餷餸餹餺餻餼餽餾餿饀饁饂饃饅饇饈饉饊饋饌饍饎饐饑饒饓饖饘饙饛饝饞饟饡饢䬬䬷𩜠𩜲𩟔
羽 radical may choose to have parallel strokes for the middle part. Same as possible to replace with JP.
To adjust:
傝僇剹勠嗡嘐噏噿嚁塌塕嫪嬥寥嵺嶍廖慴憀戮戳扇搧搨摎摺擢暡曜栩榻槢樛櫂歙毣毾溻滃漻潝濢濯瀚瀷煽熠熤燿珝璆璻瘳瞈矅磟祤禢禤穋籊糴糶繆羽羾羿翀翁翂翃翅翇翉翊翋翌翍翎翏翐翑習翔翕翗翛翜翝翞翟翠翡翢翣翥翦翧翨翩翪翫翬翭翮翯翰翱翲翳翴翵翷翸翹翺翻翼翽翾翿耀聬膠蓊蓼藋蘙螉蟉蠗蠮褟褶詡謆謬謵譾豂趐趯蹋躍轇遢鄝醪鎉鏐鑃闒闟雡霫頨顟飁飂騸騽鰨鰼鶲鷚鸐龮㮼䁯䎗䎚䐥䕜𡟸𢄪𢣷𣝦𥔱𥣞𦆲𦏵𦏸𦐂𦐐𦐑𦐒𦑊𦑩𦒄𦒈𦒉𦒍𦒘𧄍𧝁𧷜𨃩𨌺𨦫𨯪
For the additional HKSCS set in Adobe-CNS1, two particular characters are not unified with other TC characters: 娧 U+5A27/CID+15841 and 祱 U+7971/CID+16744. Considering that Hong Kong SAR users are more tending towards using 八-shaped 兌 than 丷-shaped 兑, maybe these 2 characters may be changed to use 八-shaped 兌 instead of following the HKSCS 丷-shape.
掰 U+63B0/CID+8526 and 搿 U+643F/CID+9902 could probably have the right hand hand 手 to not slant upwards, since it's not avoiding any components. No pressure for this though.
Character set expansion
It is definitely an impressive feat to complete the Adobe-CNS1. However, for daily Traditional Chinese usage, there are still lacking characters, particularly in Cantonese, (Taiwanese) Hokkien and Hakka. They have their own Chinese characters and additional transliteration script extensions.
For Cantonese, the 《常用香港外字表》(Common Supplementary Characters in Hong Kong) level 1 to 6 is a great Chinese character extension list on HKSCS that includes daily characters that are not in HKSCS.
For Hokkien and Hakka, the resource on 《本土語言外字表》(Native Language Extra Word List) lists additional Chinese characters that are used in the two scripts. Additionally, they also require support for two transliteration Latin scripts: 白話字 (Pe̍h-ōe-jī) and 臺灣閩南語羅馬字拼音方案 (Taiwanese Hokkien Romanization Solution/Tâi-uân Bân-lâm-gí Lô-má-jī Phing-im Hong-àn) for representing sounds in Hokkien and Hakka similar to hanyu pinyin for Mandarin Chinese.
These 3 scripts may also require additional bopomofo in the Bopomofo and Bopomofo Extended Unicode block for transcriptions, along with additional tones in Spacing Modifier Letters, particularly U+02EA ◌˪ and U+02EB ◌˫. These have been added into CNS11643 Amendment 1 in 2023 for correct support.
Character set removal
The glyphs from CID+14009 to CID+14048 are used in Big5 era for the IME 行列輸入法 (array input method), specifically the 40-key version. However, there are no use for these characters anymore in modern usage as array input method has since declined, and the remaining are using the more popular 30-key version that does not require additional special characters to type the character correctly. Thus, I would suggest IBM Plex Sans TC to remove these glyphs similar to Sans JP in skipping these CIDs altogether.
The text was updated successfully, but these errors were encountered: