[PATCH v2 7/7] gdi32: Improve the determine code whether the chracter is the fullwidth.
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.
>> 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
> 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.
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
More information about the wine-devel