[PATCH v2 7/7] gdi32: Improve the determine code whether the chracter is the fullwidth.

[Byeongsik Jeon]

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,
> 1. 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.

> 2. 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.