IBM
Issues in Sans SC
Thank you for the hard work that goes into the IBM Plex Sans SC release. However, it has been disappointing given the bad quality of the Simplified Chinese glyphs (which warrant another issue @ #613). It is even worse with the following errors being present in the font showing the lack of QA on behalf of IBM Plex team. Reference glyphs on top are Source Han Sans/Serif.
The following characters have incorrect components, all (except the first) of them in 《通用规范汉字表》:
鿑𫐓遥𫵷𬀩崄
The following characters have incorrect strokes:
垚潖簠䶺
The component 廷 are all incorrect. According to 《通用规范汉字表》 and the latest GB 18030-2022, the middle stroke of 壬 should have been the longest, not the bottom stroke. IBM Plex Sans JP and TC had the correct form that can be applied in SC directly, but have been edited incorrectly.
《通用规范汉字表》(2013)
GB 18030-2022
Additioanlly, 21 characters (all from the Kangxi Radicals block) are missing in SC, meaning the font does not reach GB 18030-2022 coverage. These should probably be mapped directly from the Kangxi Radicals block (all 214 are present).
艸見貝車釆長門韋頁風飛馬鬥魚鹵麥黽齊齒龍龜
Additioanlly, 21 characters (all from the Kangxi Radicals block) are missing in SC, meaning the font does not reach GB 18030-2022 coverage. These should probably be mapped directly from the Kangxi Radicals block (all 214 are present).
艸見貝車釆長門韋頁風飛馬鬥魚鹵麥黽齊齒龍龜
Besides, the character U+9F9C "龜" in SC should be mapped to U+2EF1 "⻱" instead of U+2FD4 "⿔" .
Glyphs of U+9F90, U+9F95 and U+9F97 (龐龕龗) have the vertical stroke of 龍 component, which doesn’t follow the other glyphs with this component. The top should follow other glyphs with the 龍 component and be slanted at the top. Reference glyphs below are MiSans.
The component 廷 are all incorrect. According to 《通用规范汉字表》 and the latest GB 18030-2022, the middle stroke of 壬 should have been the longest, not the bottom stroke. IBM Plex Sans JP and TC had the correct form that can be applied in SC directly, but have been edited incorrectly.
It’s weird… in the Unicode documentation, the G source has the longest bottom stroke.
Yep, the actral standard of the characters in China Mainland is 《通用规范汉字表》 currently, which is not fully consistent with the Unicode chart.
Additioanlly, 21 characters (all from the Kangxi Radicals block) are missing in SC, meaning the font does not reach GB 18030-2022 coverage. These should probably be mapped directly from the Kangxi Radicals block (all 214 are present).
艸見貝車釆長門韋頁風飛馬鬥魚鹵麥黽齊齒龍龜
Well to clarify this part, the SC version is missing characters in these codepoints (currently mapped codepoint in italics): 艸 U+8278 (U+2F8B) 見 U+898B (U+2F92) 貝 U+8C9D (U+2F99) 車 U+8ECA (U+2F9E) 釆 U+91C6 (U+2FA4) 長 U+9577 (U+2FA7) 門 U+9580 (U+2FA8) 韋 U+97CB (U+2FB1) 頁 U+9801 (U+2FB4) 風 U+98A8 (U+2FB5) 飛 U+98DB (U+2FB6) 馬 U+99AC (U+2FBA) 鬥 U+9B25 (U+2FBE) 魚 U+9B5A (U+2FC2) 鹵 U+9E75 (U+2FC4) 麥 U+9EA5 (U+2FC6) 黽 U+9EFD (U+2FCC) 齊 U+9F4A (U+2FD1) 齒 U+9F52 (U+2FD2) 龍 U+9F8D (U+2FD3) 龜 U+9F9C (U+2FD4)
The appropriate glyphs are there, but currently only mapped to the Kangxi Radical blocks, so they should also be mapped to their regular codepoints.
The following characters have incorrect components, all (except the first) of them in 《通用规范汉字表》:
鿑𫐓遥𫵷𬀩崄
滫 and 吭 in 《通用规范汉字表》have incorrect component, too.
借楼 and here are my findings:
wat
should be like 邶 since unicode 5.2
dot of 龍
dot of 言
excessive size seems for many 卑
maybe small problem
winzip
the hook
bit of out of style?
does 勿 need some care? as for my impression, the convention is to let the two 丿evenly divide the bar, the latter leaving space between the 乛 turning.
and personally i think the contact point of 攵 (and 夂, or even 友犮, what about 䘠), especially when compressed hard horizontally (eg. 㜫䥩鿦), might be better to also follow the 人 style. i know there will be a lot of glyphs to change for this, though, just my wishes.
Please remain on-topic. Links to derivatives of Plex are not appreciated and will be removed.
燬 is incorrect in SC, bottom should be 工 not 土:
燾 has incorrect ordered point on Bold causing interpolation issues between Regular and Bold:
執 should follow the stroke length in the regular master, SC forget to change the other masters. Use the glyph in TC would work.
Too many glyph problems to be used by present... I have to even use Source Han Sans instead...
The OpenType ss02 feature is mapped to the wrong g glyph. In all other versions ss02 is mapped to single-storey g, but in SC it is mapped to the double-storey g that has a flatter tail version for diacritics mark.