[Bug 41639] Wine with freetype 2.7 causes font rendering issues

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=41639

Logan Rathbone <poprocks at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |poprocks at gmail.com

--- Comment #15 from Logan Rathbone <poprocks at gmail.com> ---
I don't have a solution in terms of what, if anything, in WINE should be
patched or modified. But here is what I know and can add to this discussion.

For the record, I'm on Slackware-Current running WINE 3.0.1 as packaged on
winehq.org by Simone Giustetti (Oh, look at that - it was updated to 3.0.2
yesterday). But I've also noticed the issue on Fedora Core 28 with both
wine-staging 3.11 (as packaged in the official Fedora repos) and winehq-stable
as provided by winehq.org.

Freetype 2.7 added a new subpixel hinting mode that is different from the
previous "subpixel rendering" option that could be activated in freetype by
uncommenting "#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING" in
include/freetype/config/ftoption.h ("ftoption.h").

Prior to 2.7, most distros left this option commented due to patent issues from
Microsoft (NB: these are *different* from the *expired* patents that pertained
to the bytecode interpreter issue; that is separate and is not to be confused
with these MS patents).

On such distros, subpixel rendering would not have been available *at all*.
Enable it all you want, but the rendering will still be monochrome (see, eg, a
close-up of your fonts with xmag).

So enter 2.7. Hooray! We don't have to enable this patented code anymore to get
subpixel rendering, because we have TT_CONFIG_OPTION_SUBPIXEL_HINTING which
gets unpatented subpixel hinting enabled. Three modes are now possible,
depending on how freetype was compiled: 
FREETYPE_PROPERTIES="truetype:interpreter-version=X", where X is 35, 38 or 40.

35 is the classic hinting mode from Freetype 2.6.x and earlier.

38 is Infinality mode, which was never enabled by default, but I believe was
available in 2.6.x and below as a well-hidden option.

40 is the new unpatented subpixel hinting mode, and is the default in 2.7.x and
later.

So you can set FREETYPE_PROPERTIES="truetype:interpreter-version=35" and run
WINE, and get whatever you would have been getting prior to 2.7.

If in 2.7.x and later, you *don't* enable FT_CONFIG_OPTION_SUBPIXEL_RENDERING,
*in addition to* setting TT_CONFIG_OPTION_SUBPIXEL_HINTING to your preferred
configuration (I've not tried building 2.7+ without enabling
TT_CONFIG_OPTION_SUBPIXEL_HINTING at all), your fonts will be un-antialiased at
certain sizes no matter what you do, in accordance with their "gasp" tables.
Eg, Times New Roman, Arial, etc., all say "don't antialias me between sizes 8
and 12" (or whatever).

But the problem is, under the new subpixel hinting mode, unantialiased fonts
look like garbage. So if you force
FREETYPE_PROPERTIES="truetype:interpreter-version=35", your fonts will render
correctly, but they'll remain unantialiased. 

*If*, however, either under pre-2.7 *or* post-2.7 with
FT_CONFIG_OPTION_SUBPIXEL_RENDERING *enabled*, WINE will render your fonts
correctly, with antialiasing, subpixel rendering, the whole nine yards. They
will look very nice, if I may say so myself.

A prerequisite for this is also to have the appropriate FontSmoothing registry
entries enabled through your WINE prefix (via winetricks or otherwise).

So it seems that, with certain fonts at certain sizes in accordance with their
gasp tables, WINE *needs* the old subpixel rendering mode of Freetype to be
enabled; otherwise it will simply not cooperate and will not antialias the
fonts.

I think this needs to be reworked a bit, but I've no idea how to do it. WINE
should probably just find a way to antialias the fonts and let the system
decide how to do it rather than tapping so directly into freetype's old
subpixel rendering method, and just failing to antialias at all if that mode is
not available. I think WINE could probably get away with just antialiasing
everything being "good enough" if FontSmoothing is set to RGB (or whatever) and
the old subpixel rendering method is unavailable.

Problem is, if something is not done we're going to be stuck with absolutely
unreadable fonts in WINE for quite some time, as most distros are shipping 2.7+
now with the defaults being left alone.

Hope this helps!

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.