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

Byeongsik Jeon bsjeon at hanmail.net
Thu Feb 7 06:53:35 CST 2019

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.

More information about the wine-devel mailing list