GNOME Bugzilla – Bug 756204
xsettings: Change font hinting to default to 'slight'
Last modified: 2015-12-11 09:51:58 UTC
In https://bugzilla.gnome.org/show_bug.cgi?id=724190 and during irc discussions on #gnome-design, I keep hearing that 'slight' hinting would be a much more sane default than our current 'medium'. Let's switch this around early this cycle and see how it works out for 3.20; as I understand it, Cantarell needs a few fixes to work well with 'slight', but madigens and jimmac are already working on fixing those issues. Hopefully changing the default early in the cycle gives us enough time to iron out any larger problems with our default fonts if anything should come up.
Created attachment 312854 [details] [review] xsettings: Change font hinting to default to 'slight' Our resident font experts, madigens and jimmac suggest that the autohinter == hintslight is a better global default than our current default to do medium hinting. This commit changes it around and switches to 'slight' as the default. "hintmedium is an awkward no-mans-land that is equal to hintfull for .otfs and something slightly hinted but slightly no for .ttfs"
works for me if that works for Jakub ;-)
(This change came about after I complained about this year-old default and because the DE ignored my fontconfig settings and I had to manually fudge the configuration) Slight/medium/full are coarse descriptions that mean different things to different font formats. 1. OpenType/CFF (.otf) fonts: medium == full == snapping glyphs to the y-axis only. By design, this tries to preserve outline fidelity. 2. TrueType (.ttf) fonts: Full currently (FreeType 2.6.1) snaps to x-and-y-axis and FT doesn't fully handle ClearType yet (so no y-only-snapping like on Windows). Medium is similar to full, but seems to be less aggressive on the x-axis. Both sacrifice outline fidelity and "harmoniousness" for absolute sharpness with varying success. 3. Postscript fonts: not sure, but the native hinter produces sub-optimal results anyway. 4. Slight invokes the autohinter regardless of font format. Like for .otfs, it snaps to the y-axis only. The problem is nicely visible when you go medium or full and mix font formats. A default installation of Fedora will have Cantarell in OpenType/CFF format in the UI and DejaVu (.ttf) on the console. Cantarell is y-snapped and slightly emboldened due to a feature in the CFF engine, DejaVu x-and-y. The difference is jarring. Doing "Slight" by default will lead to similar rendering across the board at the expense of absolute sharpness. Ubuntu does it globally by default. The actual solution to this problem would be for GTK/cairo/whatever to defer font configuration completely to fontconfig and not interfere and change defaults in upstream fontconfig, locally, system-wide or distro-wide as needed.
https://bugs.freedesktop.org/show_bug.cgi?id=11838 may be related to this discussion.
Review of attachment 312854 [details] [review]: Can you please include more technical details, as listed in comment 3, as well as using people's real names in the commit message?
Created attachment 314537 [details] [review] Better rationale and description I just edited the patch from kalev, hope it applies cleanly ;)
Created attachment 314538 [details] [review] Better rationale and description, fixed omission
Created attachment 314549 [details] [review] Mention in description that slight ignores native hinting within the font and generates hints algorithmically.
Review of attachment 314549 [details] [review]: > Ideally, GNOME defers this to fontconfig so that both the CFF > engine for OpenType/CFF fonts and the slight autohinter for everything > else can be enabled. I've removed this bit before committing. This isn't helpful in this context, because I'd want to know: - is fontconfig already using those configuration options you describe as a default? - if not, why not? do we have a bugzilla to track this? If the upstream fontconfig doesn't do the "right thing" right now, we can't expect distributors to plug the holes behind us in this case.
Committed to master and gnome-3-18
And we can follow on the discussion about the fontconfig defaults in https://bugzilla.gnome.org/show_bug.cgi?id=757521
Thanks Basten! Not sure it's right for gnome-3-18 though; it's a pretty big change in how the whole desktop looks.
(In reply to Kalev Lember from comment #12) > Thanks Basten! Not sure it's right for gnome-3-18 though; it's a pretty big > change in how the whole desktop looks. Given that it's supposed to make things better, I think it's fine. If it's not good enough for 3.18, I don't see how it's good enough for master either...
I am not saying it's not good enough. I am saying that it changes the look of the whole desktop and we've committed to UI stability in stable releases. Also, we might need to adjust our fonts based on the new default. This is something that needs time to iron out, something that we can only get from 6 months pre-release testing in rawhide.
I'm with Kalev here -- people will most likely complain that a point release drastically changes the look. Better test it for 3.20, willingness to accept changes should be greater for a new version. As for fontconfig defaults, I'm on it. But don't expect it to be changed too soon...
I agree with Kalev too. I would have pushed this to master but not gnome-3-18. Thanks for pushing this through, Nikolaus!
Also, building Freetype2 with TT_CONFIG_OPTION_SUBPIXEL_HINTING has a dramatic effect on the bytecode hinter used for full/medium. Many Microsoft fonts (e.g. Segoe UI) become usable, but the lack of X-snapping on other fonts (like DejaVu) rubs a lot of people the wrong way.
SUBPIXEL_HINTING is still experimental and reportedly slow, though. FreeType since 2.6.0 actually renders native ClearType fonts correctly (Look at Liberation * and Open Sans). SUBPIXEL_HINTING seems to introduce backwards-compatible ClearType for fonts that were produced before it and fonts that were written with both "old" and ClearType rendering in mind (various popular Microsoft fonts). I actually don't know if you could instruct specific fonts like DejaVu to use X-and-Y snapping via fontconfig.
The behavior depends on the interpreter version. The default is hardcoded (although Arch adds a getenv hack) but changeable at runtime. I guess this is something the entire stack (fontconfig, cairo, pango, Xft?) would need to pick up to be able to configure it per-font. The fonts themselves can query the interpreter version. I guess Open Sans and Liberation see that FreeType is an old interpreter and adjust accordingly. Fonts can also control whether "ignore_x_mode" is enabled and tell a newer interpreter that they want classic hinting.
(In reply to Jan Alexander Steffens (heftig) from comment #17) > Also, building Freetype2 with TT_CONFIG_OPTION_SUBPIXEL_HINTING has a > dramatic effect on the bytecode hinter used for full/medium. Many Microsoft > fonts (e.g. Segoe UI) become usable, but the lack of X-snapping on other > fonts (like DejaVu) rubs a lot of people the wrong way. In Fedora, we build with --without-subpixel-rendering for legal reasons.
commit 854aa8073cae9402dbecb7d3eaded85c0ee4f8c5 (HEAD -> gnome-3-18, origin/gnome-3-18) Author: Bastien Nocera <hadess@hadess.net> Date: Wed Nov 4 15:32:17 2015 +0100 Revert "xsettings: Change font hinting to default to 'slight'" This reverts commit 1d444e1b2bba0102c7e8d94a6dae3014b511f7b0. This commit broke the string freeze for the stable version, and it was commented that this shouldn't be committed to a stable release as it might cause regressions in stable distributions.
(In reply to Michael Catanzaro from comment #20) FT_CONFIG_OPTION_SUBPIXEL_RENDERING and TT_CONFIG_OPTION_SUBPIXEL_HINTING are two different things.
Uhm, so, is this change in the 3.20 branch?
It's in the master branch, so it will be in 3.20. Bastien, want to do a 3.19 release, to get this into rawhide, GNOME:Next, etc?