After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756204 - xsettings: Change font hinting to default to 'slight'
xsettings: Change font hinting to default to 'slight'
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: xsettings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2015-10-07 20:52 UTC by Kalev Lember
Modified: 2015-12-11 09:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
xsettings: Change font hinting to default to 'slight' (1.77 KB, patch)
2015-10-07 20:54 UTC, Kalev Lember
needs-work Details | Review
Better rationale and description (5.77 KB, patch)
2015-10-31 12:07 UTC, Nikolaus Waxweiler
none Details | Review
Better rationale and description, fixed omission (5.79 KB, patch)
2015-10-31 12:11 UTC, Nikolaus Waxweiler
none Details | Review
Mention in description that slight ignores native hinting within the font and generates hints algorithmically. (5.86 KB, patch)
2015-10-31 16:35 UTC, Nikolaus Waxweiler
committed Details | Review

Description Kalev Lember 2015-10-07 20:52:08 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.
Comment 1 Kalev Lember 2015-10-07 20:54:16 UTC
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"
Comment 2 Lapo Calamandrei 2015-10-07 20:58:53 UTC
works for me if that works for Jakub ;-)
Comment 3 Nikolaus Waxweiler 2015-10-07 22:40:52 UTC
(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.
Comment 4 Nikolaus Waxweiler 2015-10-08 07:15:59 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=11838 may be related to this discussion.
Comment 5 Bastien Nocera 2015-10-14 15:54:15 UTC
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?
Comment 6 Nikolaus Waxweiler 2015-10-31 12:07:29 UTC
Created attachment 314537 [details] [review]
Better rationale and description

I just edited the patch from kalev, hope it applies cleanly ;)
Comment 7 Nikolaus Waxweiler 2015-10-31 12:11:23 UTC
Created attachment 314538 [details] [review]
Better rationale and description, fixed omission
Comment 8 Nikolaus Waxweiler 2015-10-31 16:35:31 UTC
Created attachment 314549 [details] [review]
Mention in description that slight ignores native hinting within the font and generates hints algorithmically.
Comment 9 Bastien Nocera 2015-11-03 13:05:16 UTC
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.
Comment 10 Bastien Nocera 2015-11-03 13:16:44 UTC
Committed to master and gnome-3-18
Comment 11 Bastien Nocera 2015-11-03 13:18:00 UTC
And we can follow on the discussion about the fontconfig defaults in https://bugzilla.gnome.org/show_bug.cgi?id=757521
Comment 12 Kalev Lember 2015-11-03 13:20:04 UTC
Thanks Basten! Not sure it's right for gnome-3-18 though; it's a pretty big change in how the whole desktop looks.
Comment 13 Bastien Nocera 2015-11-03 13:31:40 UTC
(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...
Comment 14 Kalev Lember 2015-11-03 13:42:53 UTC
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.
Comment 15 Nikolaus Waxweiler 2015-11-03 16:51:10 UTC
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...
Comment 16 Michael Catanzaro 2015-11-03 17:11:00 UTC
I agree with Kalev too. I would have pushed this to master but not gnome-3-18.

Thanks for pushing this through, Nikolaus!
Comment 17 Jan Alexander Steffens (heftig) 2015-11-04 07:54:09 UTC
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.
Comment 18 Nikolaus Waxweiler 2015-11-04 08:06:37 UTC
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.
Comment 19 Jan Alexander Steffens (heftig) 2015-11-04 08:40:59 UTC
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.
Comment 20 Michael Catanzaro 2015-11-04 14:11:37 UTC
(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.
Comment 21 Bastien Nocera 2015-11-04 14:34:06 UTC
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.
Comment 22 Jan Alexander Steffens (heftig) 2015-11-04 15:11:06 UTC
(In reply to Michael Catanzaro from comment #20)

FT_CONFIG_OPTION_SUBPIXEL_RENDERING and TT_CONFIG_OPTION_SUBPIXEL_HINTING are two different things.
Comment 23 Nikolaus Waxweiler 2015-12-10 23:32:24 UTC
Uhm, so, is this change in the 3.20 branch?
Comment 24 Michael Catanzaro 2015-12-11 09:51:58 UTC
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?