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

Byeongsik Jeon bsjeon at hanmail.net
Mon Nov 5 04:23:42 CST 2018


On Mon, 5 Nov 2018 11:51:06 +0300, Dmitry Timoshkov <dmitry at baikal.ru>
wrote:
> Byeongsik Jeon <bsjeon at hanmail.net> wrote:
> 
>>> Shouldn't Freetype itself set appropriate interpreter version based on
>>> GASP flags instead?
>>>
>> At first, I thought this was a Freetype bug. But when I look at the
>> Freetype API design, it seems intentional. They know this mechanism and
>> they have been keeping this API design for a long time.
> 
> Why not ask Freetype developers to take into account gasp flags and
> appropriately tune the rendering especially if it's known to cause
> the rendering bugs?
>
I didn't ask because I didn't think it was a bug.
As you wrote below, how to use the gasp table information is an option.

Version 35 and Version 40 are interpreters of different properties with
different purposes.

Version 35 was intended to implement a bytecode interpreter. The
subpixel rendering through this is only adding the results of the gray
antialias to the subpixel. Version 40 is the implementation of the
*subpixel hinting*. This can be found to be similar to the DirectWrite
font rendering.

Version 38 seems to contains the tweaks to support both. But it's
growing code size and it looks dirty.

Of course, in the future version of the Freetype, something may change.
The Freetype document is marked the version38 as a feature to be
deleted. I'm going to pay attention to when version 38 is completely
removed.

Until then, I think this patch can help the Wine. I think it is a
problem that the text layout is very different from the same font.

Too much consideration makes this patch look dirty. In fact, the basics
are simple.

Interpreter_version = gasp_version ? 40: 35;

>> In short, the fonts can be created considering version 35 or version 40
>> or both. And record that information on the gasp table.
>>
>> When The program(or OS, etc) uses the fonts, it is optional to render
>> which interpreter version is applied. In this way, MS GDI and
>> DirectWrite rendering results may be different.
>>
>> In fact, because the Freetype implementation is different from
>> Microsoft, our choices are limited.
> 
> Obviously applications running under MacOS or Windows don't have such
> a problem, and application developers shouldn't even bother or try to
> accomodate for font renderers bugs.
> 
This is because the OS does it, or as a result, it plays such a role. So
the application developers does not have to worry about it.

In a sense, isn't Wine's position close to the OS?

If this problem is corrected in the future version of the Freetype, will
not it support the past version of the Freetype?

Is not the Wine-Bug #41639 a problem because it is not updated?




More information about the wine-devel mailing list