gdi32: Specify the suitable hinting flags explicitly.

[Byeongsik Jeon]

Sorry, I'm late for another work.

On Tue, 20 Nov 2018 12:47:09 +0000, Huw Davies <huw at codeweavers.com> wrote:
> On Tue, Nov 20, 2018 at 11:40:45AM +0900, Byeongsik Jeon wrote:
>> Unfortunately, this patch can't solve bug #41639. FT_LOAD_TARGET_MONO
>> works correctly only in Freetype 2.8.1+, but bug #41639 is about
>> Freetype 2.7.
>> http://lists.nongnu.org/archive/html/freetype/2017-09/msg00032.html
>>
>> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttinterp.h#n312
>>
>> In Freetype's truetype interpreter version 40, The hdmx table and
>> modifications to phantom points are ignored. Only FT_LOAD_TARGET_MONO
>> applies v35 internally (Freetype 2.8.1+).
> 
> If it's only bad for versions between 2.7 and 2.8 I think we can leave it.
> The patch to fix it in between those versions was too ugly.
>
This problem is resolved by correcting the wrong advance problem
described below. Bug #41639 is a B/W rendering problem for the outline
that are not hinted horizontal direction.


>> Even if we do not consider bug # 41639, now Wine GDI has a problem using
>> the wrong advance value for MS legacy fonts( with hdmx table) at the v40.
> 
> Could you elaborate?
> 

1.
https://docs.microsoft.com/en-us/typography/opentype/spec/tt_instructing_glyphs#phantoms
---
Phantom points
The Microsoft rasterizer v.1.7 or later will always add four “phantom
points” to the end of every outline to allow either widths or heights to
be controlled (MS rasterizers earlier than v.1.7 only add two phantom
points, allowing only widths to be controlled).

If the entire set of contours for a glyph requires “n” points (i.e.,
contour points numbered from 0 to n-1), then the scaler will add points
n, n+1, n+2, and n+3. Point “n” will be placed at the character origin,
point “n+1” will be placed at the advance width point, point “n+2” will
be placed at the top origin, and point “n+3” will be placed at the
advance height point. For an illustration of how these phantom points
are placed, see Figure 2-1 (points 17, 18, 19, 20) and Figure 2-2
(points 27, 28, 29, and 30).

All four phantom points may be controlled by TrueType instructions, with
corresponding effects on the sidebearings, advance width, and advance
height (in the case of vertical positioning) of the instructed glyph.
The side bearings, advance width, and advance height are computed using
these phantom points and are called the device-specific widths and
heights (since they reflect the results of grid fitting the width or
height along with the glyph to the characteristics of the device). The
device-specific widths or heights can be different from or identical to
the linearly scaled widths or heights (obtained by simple scaling
operations), depending on the instructions applied to the phantom points.

Before applying a TrueType instruction on height related phantom points
(n+2 and n+3), use GETINFO[ ] to check that the rasterizer is a MS
rasterizer v.1.7 or later.
---

2.
https://docs.microsoft.com/en-us/typography/opentype/spec/recom#39hdmx39-table
---
'hdmx' Table
This table improves the performance of OpenType fonts with TrueType
outlines. This table is not necessary at all unless instructions are
used to control the "phantom points", and should be omitted if bits 2
and 4 of the flags field in the 'head' table are zero. (See the 'head'
table documentation in Chapter 2.) Microsoft recommends that this table
be included for fonts with one or more non-linearly scaled glyphs (i.e.,
bit 2 or 4 of the 'head' table flags field are set).
---

3.
https://docs.microsoft.com/en-us/typography/opentype/spec/head
---
uint16	flags

Bit 2: Instructions may depend on point size;
Bit 4: Instructions may alter advance width (the advance widths might
not scale linearly);
---

For example:

$ ttx -l tahoma.ttf | grep hdmx
    hdmx  0x40968415    106152     19188
$ ttx -t hdmx tahoma.ttf

ppem:   9  10  11  12  13  14
   t:   3   3   4   5   4   5

Tahoma 't' width=685 EM=2048. liear scaled advance=ROUND(ppem * 685 / 2048).
   t:   3   3   4   4   4   5

wordpad_tahoma_t_111213px.png shows the actual rendered image. We can
see the 5px advance applied in the ppem 12px 't'.

I used 't' as an example to show prominent differences, but it also
applies to other characters. This problem will cause a difference in
text layout between Wine and native Windows. Of course, it does not
appear in programs with their own layout engines, or programs using
DirectWrite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wordpad_tahoma_t_111213px.png
Type: image/png
Size: 2044 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20181121/7ec09dd8/attachment.png>