NFSL2001

@BobH-Official 1. The dot difference of 火 does not exists in printing fonts (eg songti/heiti) for Chinese. If you reference 《通用规范汉字表》, you will see that the left dot of 火...

Actually, referring to official document GB 3005-1999《印刷隶体字形规范》, the current 氐 in 䟡 is the correct one and the others are "wrong". In terms of relative placement, the dot should be...

This actually seem to be a "regression" from v1. From the glyph correction record in https://github.com/adobe-fonts/source-han-sans/issues/178#issue-231685634: > U+47E1 䟡 uni47E1-CN - The short diagonal stroke should not connect, and should...

1. I actually saw advertisement for JP version of this font on Twitter and there seem to be not much inquiries on the font so far, so if you think...

Thank you for the recommendations. For BASE tag i believed that it should be fully defined in this case as this is a rectangular font instead of a square font....

@aaronbell Just checking on the new metrics, the new values of 945/-235 are aligning the character face (814/-104)? Also no font name changes will be required?

> newHeight = font["head"].unitsPerEm > if font["vmtx"].metrics[i][0] == glyphHeight: I do not like this as this will still requires separately tracking the advance height and/or the starting point to deal...

For makeotf, setting the "wrong" OS/2 and then correct it is easier than mangling up 10k+ vmtx records. It should be noted that in makeotf, the program assumes sTypo to...

> Interesting. Which applications are these? It would be good to reach out to the developers to recommend separating internal ascender / descender values from sTypo values generated on export....

I've implemented most of the changes locally, will release the changes on 31/3 (hopefully, depends on the exact Aidilfitri date). Current build uploaded here for review: [WD-XL_GF_TTF.zip](https://github.com/user-attachments/files/19390167/WD-XL_GF_TTF.zip) Does the JP...