NFSL2001
NFSL2001
It is ok in most (modern) cases. I'm looking forward to GitHub reintroducing `system-ui` and overridable font settings.
Is there any fix for this yet? Logging some of the paths will easily exceed the max buffer size.
I have provided a list of glyphs that were removed when going from 1.004 to 2.000 (hopefully it's correct) at https://github.com/adobe-fonts/source-han-sans/issues/259.
Here is the text file (also uploaded in #259). Some glyphs are either remapped, changed (such as 简 as mentioned in #293) or renamed that makes this task real hard,...
Related comment: https://github.com/adobe-fonts/source-han-sans/issues/329#issuecomment-1034082819, https://github.com/adobe-fonts/source-han-serif/issues/56#issuecomment-299300006 Note that the glyph removal consolidation at https://github.com/adobe-fonts/source-han-sans/issues/179 targeted the **_uni3D6E-CN_** glyph to be removed when upgrading to v2, not uni3D6E-JP.
U+535A (博) for CN should be mapped to CID+62034 as the 甫 does not have a hook. Also, the mentioned mapping is incorrect for KR. Current mapping: CID+11682 - JP,...
Not the full name, but the 7 weights (Extralight to Heavy) in VF as mentioned here (https://github.com/adobe-fonts/source-han-sans/issues/290#issuecomment-829505434), sorry for confusion. My main question is on the incomplete localized `name` table...
I am guessing something else is going on too since Word processor relies on Windows type engine. In Control Panel, SHS only show up with ExtraLight:  but Source Sans...
 *uni9399-CN* (\42110) and *uni9399-TW* (\42111) could be unified. Edit: similar issues are found with *uni6EAF-CN*/*uni6EAF-TW* (\24004, \24005) and *uni5851-CN*/*uni5851-TW* (\13702, \13703).
In Sans, TW is mapped to JP due to connected 夕. In Serif, TW can be mapped to CN as this different does not appear anymore. However, the 多 component...