[PATCH v2 1/3] gdi32: Fix the truetype interpreter version problem.
Byeongsik Jeon
bsjeon at hanmail.net
Mon Nov 5 08:16:09 CST 2018
On Mon, 5 Nov 2018 14:06:32 +0000 (UTC), Hin-tak Leung
<hintak_leung at yahoo.co.uk> wrote:
> There is no need for application using freetype to change the
> interpreter version at compile time - you can do that at runtime by
> setting the FREETYPE_PROPERTIES environment variable. This was
> introduced in freetype 2.7/2.8-ish.
>
On Mon, 5 Nov 2018 14:08:50 +0900, Byeongsik Jeon <bsjeon at hanmail.net>
wrote:>
>
> 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.
>
When you fix the interpreter version, it does not satisfy both types of
the fonts together.
> On Monday, 5 November 2018, 21:53:48 GMT+8, Byeongsik Jeon
> <bsjeon at hanmail.net> wrote:
>
>
> On Mon, 5 Nov 2018 13:32:18 +0300, Dmitry Timoshkov <dmitry at baikal.ru
> <mailto:dmitry at baikal.ru>>
> wrote:
>> It's not reasonable to expect application developers to dive into this
>> kind of very specific and technical details. Developers just expect that
>> things work. This is how it works under Mac and Windows.
>>
> I'm not saying that all application developers should do this.
> Also, the developers does not need to do this on Mac or Windows. Because
> it works as they expected.
>
> This solution is a way to fit the definition of the gasp table.
> Unlike general application development, it is not a special technique in
> the development that directly accesses the fonts.
>
>>>
>>> Interpreter_version = gasp_version ? 40: 35;
>>
>> If that's this simple why freetype can't do that on its own?
>>
> It is an option to decide how to operate. Even if the Freetype does it
> automatically, the Freetype should be made selectable it. If the action
> is not matched to Windows, we will have to consider another solution.
>
> Is it a problem that it solve the problem using the API provided by the
> Freetype? It is a solution that can be widely applied to the Freetype
> already distributed, including MacOS XQuartz v2.7.11.
>
> This problem may be solved in some next version of the Freetype. Then we
> can add some patch. But the patch for the past versions will still need.
>
>
>>
>> There is nothing special in fonts handling that Wine does that other
> applications
>> don't or can't do.
>
>>
> A typical Linux application does not refer to the gasp table. But isn't
> the Wine already referring to it?
>
>
> I didn't think this solution would be a controversial issue. Maybe it's
> the result of my awkward English expression. In fact, I don’t think I’ve
> heard an answer that makes sense to why this solution is wrong.
>
> This can be solved by Wine, even if it is not a bug caused by Wine
> itself. Then the effect is more extensive.
> I am grateful for the comments.
>
>
>
>
More information about the wine-devel
mailing list