Byeongsik Jeon bsjeon@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.
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.
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;
If that's this simple why freetype can't do that on its own?
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?
There is nothing special in fonts handling that Wine does that other applications don't or can't do.