On Sat, 2 Feb 2019 05:11:58 +0900, Byeongsik Jeon wrote:
I looked at the behavior on Windows with a test font that manipulated the OS/2 table(Panose, AvgCharWidth). It didn't work as I thought. IMO, Windows seems to be doing something related to the following document. Surprisingly, Wine already has the scripts needed for conversion, so I can work easily.
https://www.unicode.org/Public/11.0/udd/EasasianWidth.txt
This is a temporary patch. Please review if possible. It is also good to post more improved patch directly.
I agree with that Windows uses some sort of fullwidth character table, but I'm not sure about EasAsianWidth.txt. At least, there are two issues, 1. We can't get an Unicode code point when GetGlyphOutline function called with GGO_GLYPH_INDEX flag. 2. There are ambiguous width characters. For instance, is U+20AC a fullwidth character or a halfwidth one?
By the way, when I tested with Gulim on Windows, I got 19 px as gmCellIncX value at 19 ppem for U+C640 (see attachment for details). Gulium shares the embedded bitmap with GuliumChe. So, why don't you fix up base_advance when using embedded bitmaps? By doing so, the advance will be 19 (not 18) before calculating fixed_pitch_full. And, we don't have to update the formula.
Akihiro Sagawa