On Mon, 5 Nov 2018 14:06:32 +0000 (UTC), Hin-tak Leung hintak_leung@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@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@hanmail.net wrote:
On Mon, 5 Nov 2018 13:32:18 +0300, Dmitry Timoshkov <dmitry@baikal.ru mailto:dmitry@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.