[PATCH v2 1/3] gdi32: Fix the truetype interpreter version problem.

[Byeongsik Jeon]

On Mon, 5 Nov 2018 10:21:24 +0300, Nikolay Sivov
<nsivov at codeweavers.com> wrote:
> On 11/05/2018 08:08 AM, Byeongsik Jeon wrote:
> 
>> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41639
>> Signed-off-by: Byeongsik Jeon <bsjeon at hanmail.net>
>> ---
>> v2:
>> Fix the wine-tests build error at the debian9(Freetype v2.6.3).
>> Because the build-time check is meaningless, v2 has modified it to check
>> the supported interpreter version at the runtime.
>>
>> v1:
>> This is also a problem in Linux. It just seemed to stand out in
>> MacOS(Tahoma builtined) XQuartz2.7.11 Freetype2.7(subpixel turned off).
>>
>> The truetype bytecode interpreter of the Freetype appears to have the
>> following problems depending on the version.
>> - v35: MS cleartype font(ex. Consolas) rendering is ugly.
>> - v40: MS legacy font (ex. Tahoma) rendering is ugly. Some fonts return
>> the wrong values even for the glyph metrics.
>>
>> Is this a Freetype bug? Basically NOT.
> 
> I think this went away from original reported issue, and the patch is
> basically the same workaround suggested there.
> 
> The question is what changed in freetype 2.7 that caused broken
> rendering in wine's Tahoma, as an example that's easy to test.
> 
> Not that wine fonts don't use freetype instructions, so it's not obvious
> why interpreter mode could make a difference if we're still going to use
> embedded bitmaps for small sizes and original outline for the rest.
> 
>>
>> https://docs.microsoft.com/en-us/typography/opentype/spec/tt_instructions#get-information
>>
>>
>> The bytecode interptreter is a stack-based virtual maching the interprets
>> the truetype bytecode instructions. Ths bytecode program receives the
>> interpreter version information through the GETINFO instruction. GETINFO
>> also provided the information of the fontsmoothing, cleartype, etc.
>> The bytecode program actually changes the location of the glyph points
>> based on this information.
>>
>> So, what looks like a bug above is that the wrong version information was
>> delivered to the bytecode program. To determine this version value, this
>> patch use the gasp table version. This idea is inspired by the following
>> documentation.
>>
>> https://www.freetype.org/freetype2/docs/reference/ft2-properties.html#TT_INTERPRETER_VERSION_XXX
>>
>> -- 
>> Note that ‘Gray ClearType’ is essentially the same as v1.6's
>> grayscale rendering. However, the GETINFO instruction handles it
>> differently: v1.6 returns bit 12 (hinting for grayscale), while v2.1
>> returns bits 13 (hinting for ClearType), 18 (symmetrical smoothing), and
>> 19 (Gray ClearType). Also, this mode respects bits 2 and 3 for the
>> version 1 gasp table exclusively (like Color ClearType), while v1.6 only
>> respects the values of version 0 (bits 0 and 1).
>> -- 
>> I think the maximum value that can be applied to the gasp version 0 font
>> is the interpreter version 37.
>>
>> The Freetype interpreter version 38 includes tweaks based on the font
>> names. I was able to use the v38 by modifying the build option of the
>> Freetype.
>> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING     ( 1 | 2 )
>>
>> This allows the gasp version 0 fonts to be rendered more similar to the
>> Windows old cleartype in the subpixel rendering mode. However, this is
>> not applied because the build option must be modified and the Freetype
>> document is marked as a feature to be deleted.
>>
> 
> Have you actually tested older freetype versions? E.g. does ftview with
> wine's Tahoma show same corruption or not.
> 
> 

The problem arises in native Tahoma. MacOS has Tahoma builtin. and
Wine's Tahoma has a low priority.

In the Freetype interpreter version 40, the native Tahoma returns a
different glyph metrics than Windows GDI.