Re: gdi32: Specify the suitable hinting flags explicitly.

[Byeongsik Jeon]

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/tt...

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 bug 41639 is not 'WONTFIX', there is no solution other than how to
use v35( with FT_Property_Set). In my old patch, I used v35 selectively
using the gasp table version. Another solution is to decide by the
presence of the hdmx table. This seems to be a better way to determine
the problematic font in v40.

http://lists.nongnu.org/archive/html/freetype/2018-11/msg00012.html
Without FT_Property_Set, adding some flag to FT_Load_Glyph seems to be a
good solution. But it can't solve bug #41639.

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.

Please comment.

PS. The v35 can be misunderstood by its name, but it is a separate
hinting engine with different purposes.
http://lists.nongnu.org/archive/html/freetype/2017-09/msg00036.html

On Tue, 13 Nov 2018 15:01:57 -0600, Alexandre Julliard
 wrote:
> Module: wine
> Branch: master
> Commit: 7da7930a10f22cf186e9454fec2807d75f239fad
> URL:    https://source.winehq.org/git/wine.git/?a=commit;h=7da7930a10f22cf186e9454fe...
>
> Author: Byeongsik Jeon 
> Date:   Tue Nov 13 09:27:09 2018 +0000
>
> gdi32: Specify the suitable hinting flags explicitly.
>
> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41639
> Signed-off-by: Byeongsik Jeon 
> Signed-off-by: Huw Davies 
> Signed-off-by: Alexandre Julliard
>
> dlls/gdi32/freetype.c | 38 +++++++++++++++++++++++++++++++++-----
>  1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
> index b62288c..99b7d8c 100644
> --- a/dlls/gdi32/freetype.c
> +++ b/dlls/gdi32/freetype.c
> @@ -6801,6 +6801,37 @@ static unsigned int get_bezier_glyph_outline(FT_Outline *outline, unsigned int b
>      return needed;
>  }
>
> +static FT_Int get_load_flags( UINT format )
> +{
> - FT_Int load_flags = FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH;
> -
> - if (format & GGO_UNHINTED)
> -
>    return load_flags | FT_LOAD_NO_HINTING;
> -
> - switch (format & ~GGO_GLYPH_INDEX)
> - {
> - case GGO_BITMAP:
> -
>    load_flags |= FT_LOAD_TARGET_MONO;
> -
>    break;
> - case GGO_GRAY2_BITMAP:
> - case GGO_GRAY4_BITMAP:
> - case GGO_GRAY8_BITMAP:
> - case WINE_GGO_GRAY16_BITMAP:
> -
>    load_flags |= FT_LOAD_TARGET_NORMAL;
> -
>    break;
> - case WINE_GGO_HRGB_BITMAP:
> - case WINE_GGO_HBGR_BITMAP:
> -
>    load_flags |= FT_LOAD_TARGET_LCD;
> -
>    break;
> - case WINE_GGO_VRGB_BITMAP:
> - case WINE_GGO_VBGR_BITMAP:
> -
>    load_flags |= FT_LOAD_TARGET_LCD_V;
> -
>    break;
> - }
> -
> - return load_flags;
>
> +}
> -
>
> static const BYTE masks[8] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01};
>
> static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format,
> @@ -6820,7 +6851,7 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format,
>      FT_Vector adv;
>      INT origin_x = 0, origin_y = 0;
>      FT_Angle angle = 0;
> - FT_Int load_flags = FT_LOAD_DEFAULT | FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH;
> - FT_Int load_flags = get_load_flags(format);
> double widthRatio = 1.0;
> FT_Matrix transMat = identityMat;
> FT_Matrix transMatUnrotated;
>
> @@ -6859,10 +6890,7 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format,
>              tategaki = check_unicode_tategaki(glyph);
>      }
> - if(format & GGO_UNHINTED) {
> -
>    load_flags |= FT_LOAD_NO_HINTING;
> -
>    format &= ~GGO_UNHINTED;
> - }
> -
>
> format &= ~GGO_UNHINTED;
>
> if(original_index >= font->gmsize * GM_BLOCK_SIZE) {
> font->gmsize = (original_index / GM_BLOCK_SIZE + 1);

gdi32: Specify the suitable hinting flags explicitly.

[Huw Davies]

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/tt...
>
> 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.
> 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?

Huw.

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  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/tt...
> >
> > 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_gly...
---
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-tab...
---
'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.

gdi32: Specify the suitable hinting flags explicitly.

[Dmitry Timoshkov]

Byeongsik Jeon  wrote:
> > > 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?

[skipped]
> 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.

Is there a reason why freetype doesn't do what Microsoft documentation
implies to be a responsibility of the font rasterizer?

gdi32: Specify the suitable hinting flags explicitly.

[Byeongsik Jeon]

On Tue, 20 Nov 2018 22:35:58 +0300, Dmitry Timoshkov 
wrote:
> Byeongsik Jeon  wrote:
> > > > 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?
>
> [skipped]
> > 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.
>
> Is there a reason why freetype doesn't do what Microsoft documentation
> implies to be a responsibility of the font rasterizer?

It's v35.
http://lists.nongnu.org/archive/html/freetype/2017-09/msg00036.html

And, it is registered as an issue. But it has a low priority for
Freetype maintainer.
> http://lists.nongnu.org/archive/html/freetype/2018-11/msg00012.html
> Without FT_Property_Set, adding some flag to FT_Load_Glyph seems to be a
> good solution.

gdi32: Specify the suitable hinting flags explicitly.

[Dmitry Timoshkov]

Byeongsik Jeon  wrote:
> > > 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.
> >
> > Is there a reason why freetype doesn't do what Microsoft documentation
> > implies to be a responsibility of the font rasterizer?
>
> It's v35.
> http://lists.nongnu.org/archive/html/freetype/2017-09/msg00036.html
>
> And, it is registered as an issue. But it has a low priority for
> Freetype maintainer.

I'd suggest to either ask Werner to give a higher priority to that bug,
or find someone else able to fix it properly on Freetype side instead of
hacking Wine (or any other 3rd party project) with adding workarounds for
this bug.

gdi32: Specify the suitable hinting flags explicitly.

[Byeongsik Jeon]

On Tue, 20 Nov 2018 23:26:55 +0300, Dmitry Timoshkov 
wrote:
> I'd suggest to either ask Werner to give a higher priority to that bug,
> or find someone else able to fix it properly on Freetype side instead of
> hacking Wine (or any other 3rd party project) with adding workarounds for
> this bug.

OK. I'm not stick to the patch of wine on this issue.

Bug #41639 is 'WONTFIX'? In fact, unlike what Bug #41639 claims,
Freetype builds are much easier than Wine builds.

Freetype seems to be problematic because it has various build options
and various versions are being distributed. If Wine built in Freetype as
a submodule, it will be easier. But I'm not claiming this :)

Thank you for your comment.