On Mon, 5 Nov 2018 10:21:24 +0300, Nikolay Sivov nsivov@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@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#ge...
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_INT...
-- 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.