[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