I'm late. I'm sorry. Because of my personal situation, I had to be in a network-disconnected environment for the last few days.
Akihiro Sagawa wrote:
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,
- We can't get an Unicode code point when GetGlyphOutline function
called with GGO_GLYPH_INDEX flag.
It's a good point. This is the similar case as Tategaki. ---- In get_glyph_outline(),
TODO: Window also turns off tategaki for glyphs passed in by index if their unicode code points fall outside of the range that is rotated. ---- I assume the solution will be similar.
- There are ambiguous width characters. For instance, is U+20AC a
fullwidth character or a halfwidth one?
In my test, Type 'A', 'F' and 'W' of EastAsianWidth.txt were full-length characters. However, I have not yet examined the entire code area.
This may depend on Windows locale. Also, Unicode versions that are supported by each version of Windows may differ.
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.
This is not applicable. This is a special case for the 'ttc' font file.
Because Windows built-in fonts are well-adjusted fonts, it is difficult to figure out exactly what Windows is doing. I think we can test this with fonts that manipulate the AveCharWidth value.
Because of other issues, it would have to be delayed later to investigate this.
Thank you.