[PATCH v3 1/3] gdi32: Specify the hinting algorithms to apply explicitly.

Huw Davies huw at codeweavers.com
Mon Nov 12 09:49:39 CST 2018


On Tue, Nov 06, 2018 at 04:08:06PM +0900, Byeongsik Jeon wrote:
> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41639
> Signed-off-by: Byeongsik Jeon <bsjeon at hanmail.net>
> ---
> 
> As a result of analyzing the native Tahoma font in the ftview, I realized 
> that the bug #41639 is a result of not specifying the appropriate hinting 
> algorithm.
> 
> https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_LOAD_XXX
> ---
> .. values to select a specific hinting algorithm for the hinter.
> ..
> You can use a hinting algorithm that doesn't correspond to the same 
> rendering mode. As an example, it is possible to use the ‘light’ 
> hinting algorithm and have the results rendered in horizontal LCD pixel 
> mode, with code like
> 
> FT_Load_Glyph( face, glyph_index, load_flags | FT_LOAD_TARGET_LIGHT );
> FT_Render_Glyph( face->glyph, FT_RENDER_MODE_LCD );
> ---
> 
> FT_LOAD_TARGET_NORMAL is 0.
> So, we have been applying FT_LOAD_TARGET_NORMAL to all load_flags.
> 
> ---
> FT_LOAD_TARGET_NORMAL :
> Default render mode; it corresponds to 8-bit anti-aliased bitmaps.
> FT_LOAD_TARGET_MONO :
> Strong hinting algorithm that should only be used for monochrome output.
> ---
> 
> We usually do not see this problem because we use the Wine's Tahoma with 
> the embeded bitmap.
> 
> MacOS XQuartz 2.7.11, Freetype 2.7:
>  - subpixel rendering disabled Freetype.
>  - MacOS builtined Tahoma.
> This bug appears because of the combination of two situations.
> 
> This is about the Freetype interpreter version 40.
> Version 40 is the default.
> 
>  dlls/gdi32/freetype.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
> index 07de6f2f6c..56d1e99873 100644
> --- a/dlls/gdi32/freetype.c
> +++ b/dlls/gdi32/freetype.c
> @@ -7001,6 +7001,30 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format,
>      if (needsTransform || format != GGO_BITMAP) load_flags |= FT_LOAD_NO_BITMAP;
>      if (vertical_metrics) load_flags |= FT_LOAD_VERTICAL_LAYOUT;
>  
> +    if (!(load_flags & FT_LOAD_NO_HINTING))
> +    {
> +        switch (format)
> +        {
> +        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;
> +        }
> +    }
> +

This seems worthwhile, however could you make this a helper function
(e.g. get_load_flags() and call it earlier on, right before where
GGO_UNHINTED is handled?  The helper would also return
FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH.

Huw.



More information about the wine-devel mailing list