Bug 489833
Summary: | Default Font Rendering is Poor | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Wood <cwgarfield12> |
Component: | freetype | Assignee: | Behdad Esfahbod <behdad> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | behdad, craftjml, fonts-bugs, kevin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-03-12 05:28:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Wood
2009-03-12 05:20:58 UTC
We cannot enable these features in Fedora because they violate software patents.
You can try the freetype-freeworld packages from RPM Fusion, but these packages do not carry Ubuntu's antialiasing patches which are not upstream, they only enable the bytecode interpreter and subpixel antialiasing from upstream freetype (which cannot be done in Fedora due to software patents).
The only complaint which sounds valid is this one:
> In Firefox, fonts are too big proportionally no matter how font settings are
> changed in Edit|Preferences. They look about 1 size bigger or smaller than they
> should be.
I've also noticed GTK+ apps displaying larger fonts at the same point size and dpi than Qt apps. 94 dpi in pango is about the same size as 96 dpi in Qt. But this is a completely separate issue, it has nothing to do with the patent-encumbered patches you're referencing.
1. OO.o behaves differently since it uses a different text stack. This is being fixed upstream, you can ask OO.o devs to accelerate the move to pango/cairo if you like 2. GNOME font sizes are different: this is a result of GNOME allowing the overloading of DPI value in gconf instead of using the Xorg DPI value as everything else. Complain GNOME-side. DE people need to be hit with a huge cluestick and leave DPI to X (and modify this value at the X level if needed not in private overlays others apps do not see) 3. Cleartype. Not going to happen for legal reasons. Additionnaly it only performs good on very specific hardware, and very specific fonts (MS fonts which have bugs cleartype hides; we're not going to optimise our display for fonts we do not ship to the detriment of fonts we do ship). For every comment you'll find on the net praising those patches you'll find three stating they suck and make things worse. (likewise for Ubuntu vs Fedora text rendering) ad 2. It's not that. My screen reports a resolution which is basically 96×96 dpi, and I even tried forcing both KDE and GNOME to exactly that, GTK+ apps still display larger fonts at the same size. Only when setting GTK+/GNOME to 94 dpi did I get approximately the same size (but not quite as nice looking fonts as with 96 dpi, though I got used to that). What happens is that if I turn down the hinting (autohinter, mind you, I don't have freetype-freeworld installed, I only maintain it ;-) ), the effect disappears (but the fonts look bad), the stronger the (auto)hinting, the larger GTK+'s fonts get and the smaller Qt's. Somehow they use different algorithms. :-( Ditto on the addendum for #2: GTK actually reads its DPI from Xrdb, like everyone else. It behaves remarkably well. I believe it uses GConf as a way to store DPI changes on the fly. At logon, it loads the GConf value into Xrdb. A useful way to store the user-preference without being Xrdb dependent. Also, Kevin. I'm pretty sure they use the exact same algorithms -- my guess is they have some DPI rounding problems. Example, if you vary Deja Vu Sans, sizes 9 and 10, DPI 94, 96, 98, and hinting between slight and full, you'll notice that Qt and GTK can render nearly identical glyphs -- but at different DPIs. (What's even weirder is that hint-slight on Qt/GTK will mismatch on entirely different DPIs than hint-full. Slight-9-96 will match, but Slight-9-98 won't. Full-10-100 and Full-10-94 will match, but Full-10-98 and Full-10-96 won't.) I was hoping sometime I could build a little visual guide to the discrepancies and post it to the Qt bug thing to see what they think. I'm inclined to think the problem is a rounding bug on their side; GTK allows decimal DPIs (whatever that actually means) while Qt does not, so I'd suspect Qt first. PS, I disagree partially with the "DE need to leave DPI to X". I'm all for consistency, but the X model has inherent flaws of its own -- DPI and subpixel-format should be per-screen, not per-X-server, and X hasn't moved toward that yet. The individual DE's and toolkits would currently be in a better position to use Xrandr and change their rendering based on per-screen settings, than it would be for Xorg to redo their Server attribute paradigms, which would break a whole lot of crap. |