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

[Akihiro Sagawa]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_gulim.c
Type: application/octet-stream
Size: 1418 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190205/8e4d8879/attachment-0001.obj>