Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.
On 29.09.2015 10:27, Ken Thomases wrote:
If the client requests a bold typeface of a font which doesn't actually provide a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes italic by apply a shear transform.
These techniques work passably when antialiasing is in effect. However, when antialiasing is disabled at small sizes by the font's GASP table, the results are horrible. The glyphs have many spurs or appear furry.
On the theory that fonts disable antialiasing via the GASP table at small sizes because hinting should produce pixel-perfect results and that that rationale is voided by the application of procedural bolding or italicizing, we ignore the GASP table and always antialias for fake bold or italic fonts.
Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself.
There is a new registry setting to disable this and revert to the previous behavior:
[HKEY_CURRENT_USER\Software\Wine\Fonts] "AntialiasFakeBoldOrItalic"="n"
What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch?
Signed-off-by: Ken Thomases <ken(a)codeweavers.com>
On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps.
Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel.
There is a new registry setting to disable this and revert to the previous behavior:
[HKEY_CURRENT_USER\Software\Wine\Fonts] "AntialiasFakeBoldOrItalic"="n"
What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch?
No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting. -Ken
On 29.09.2015 12:40, Ken Thomases wrote:
On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps.
Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel.
Interesting, that could explain test results we have, where advances are adjusted by one pixel only.
There is a new registry setting to disable this and revert to the previous behavior:
[HKEY_CURRENT_USER\Software\Wine\Fonts] "AntialiasFakeBoldOrItalic"="n"
What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch?
No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting.
Ok.
-Ken
participants (2)
-
Ken Thomases -
Nikolay Sivov