Hi. This comes from Debian Bug#377147 (http://bugs.debian.org/377147), and was previously misinterpreted to be another symptom of fdo#6617. The problem is that, after upgrading to 1.2.0, fonts in GTK+ widgets (and, to a lesser extent, Qt) are very ugly, plus only the first word is displayed in some labels. My original message in comment #31 of bug #6617 follows. The situation is: - 1.0.4-2 from Debian works fine for me - 1.2.0-2 from Debian does not: ugly fonts, undisplayed words After a session of git-bisect, I can point to the following commits (with screenshots): (a) last commit in the 1.1.x development branch where it works fine: % git checkout -b last_good 568ce860264e63f86ae45258eb106fb7a74a33a3 # commit 568ce860264e63f86ae45258eb106fb7a74a33a3 # Author: Carl Worth <cworth@cworth.org> # Date: Wed Aug 31 14:43:31 2005 +0000 # # Increment CAIRO_VERSION to 1.1.1 after making branch tag BRANCH_1_0. PNG -> http://people.debian.org/~adeodato/tmp/2006-07-09/cairo-bug/cairo-1last_good.png (b) the very next commit to (a) is a big one, and introduces breakage: % git checkout -b after_big_commit b0c58593b30c1fa085b1e7c8e4897da623b8686d # commit b0c58593b30c1fa085b1e7c8e4897da623b8686d # Author: Keith Packard <keithp@keithp.com> # Date: Wed Aug 31 15:08:02 2005 +0000 # # Split out scaled font code to cairo-scaled-font.c # Replace cairo cache implementation (this code from cworth) # No more global glyph cache to clean up # Store glyphs in new per-scaled font caches which hold user-space metrics and device space bounding boxes # Refactor glyph drawing APIs so that the surface API is invoked directly from the gstate code. # Add path creation/destruction routines (to hold glyph paths) # New implementation of scaled fonts which uses per-scaled_font caches for glyphs and keeps user-space metrics, device-space bboxes along with glyph images and/or glyph paths. # Adapt to new scaled font API changes. # New cache and scaled_font APIs # Repond to bug fix in metrics computation for glyphs where y values were rounded up instead of down because of a sign difference between cairo and FreeType. # Reviewed by: otaylor, cworth PNG -> http://people.debian.org/~adeodato/tmp/2006-07-09/cairo-bug/cairo-2after_big_commit.png (c) a fix for the above is introduced the next day: % git checkout -b fix_after_big_commit 0cfa350fa86c7894eec4e1b99ac7b69bc0c8f296 # commit 0cfa350fa86c7894eec4e1b99ac7b69bc0c8f296 # Author: Keith Packard <keithp@keithp.com> # Date: Thu Sep 1 20:38:07 2005 +0000 # # Oops. Call _cairo_scaled_font_set_metrics to set user-space metrics for scaled fonts. # reviewed by: otaylor deserves credit for noticing a problem PNG -> http://people.debian.org/~adeodato/tmp/2006-07-09/cairo-bug/cairo-3fix_after_big_commit.png (d) with current HEAD, the result is the same: % git checkout master # commit a1143d120fbc142fc6ae15f394cfbe400a4a0b3e # Author: Behdad Esfahbod <behdad@behdad.org> # Date: Sat Jul 8 21:04:21 2006 -0400 # # Generate index of new symbols in 1.2. PNG -> http://people.debian.org/~adeodato/tmp/2006-07-09/cairo-bug/cairo-4head.png In case it's relevant, I'm using fontconfig 2.3.2-7, and my ~/.fonts.conf file can be found here: http://people.debian.org/~adeodato/tmp/2006-07-09/cairo-bug/home-dot-fonts.conf But none of the other three possible AA/hinting combinations yield any different result. Thanks.
On archlinux our users are facing this problem too. I couldn't reproduce it at first, but after changing some settings in fontconfig the problem became clear to me. From the screenshots I've seen, most are KDE screenshots. People setup AA from kcontrol, which excludes certain font sizes from AA by default. This is where the problem is: when setting this, somehow cairo looses track of the fontsize and decides that every font, no matter how big it is, is in that exclude range. Using this setting, the bug in https://bugs.freedesktop.org/show_bug.cgi?id=6617 is also exposed using truetype fonts.
(In reply to comment #1) > From the screenshots I've seen, most are KDE screenshots. Uhm, now you mention, I do also use KDE, and the people in the Debian bug that also suffer this, seem to be KDE users as well. Today I discovered this piece of advice: http://lists.debian.org/debian-kde/2006/07/msg00040.html. I don't know why running GTK+ applications under KDE makes ~/.qt/qtrc be relevant for them, but the fact is that setting both enableXft and useXft to true, solves the problem for me.
It happens with ICEWM as well according to bugreports I had (http://bugs.archlinux.org/task/5003 is the main bugreport we have for this on archlinux) Why the qtrc matters in this case: KDE applies settings to non-KDE applications. What I've also seen is that if you make the gnome-settings-daemon program non-executable, kill it, your fonts will also look very bad from within GNOME. Somehow gnome-settings-daemon does things to your font settings that make it look good again, as soon as you fire it up from KDE, the problem goes away.
same problem on Mandriva cooker when AA is disabled, http://qa.mandriva.com/show_bug.cgi?id=23823
easy way to get reproduce the issue : under GNOME : -run gnome-font-properties -choose "monochrome" for rendering I think there might be another bug behind text rendering being damaged, highlighted by KDE : Kcontrol allows to specify a font size range where antialising is disabled and it seems when set, this range isn't checked and antialiasing is disabled for all size. But let's focus on the first bug ;)
I can't reproduce by choosing Monospace. However, I've heard that having ranges to disable antialiasing is what causes the bug.
(In reply to comment #5) > easy way to get reproduce the issue : Please help me understand what you mean by "the issue". The original bug report here, (with the screenshots), is apparently that text is being rendered without antialiasing when antialiasing is desired. Also, there's a second bug being reported at the same time, (which is unfortunate---one bug per report would help), that some text is not being rendered at all. I'm not sure if you are describing either of those things or something else entirely, since you are describing a bug which is triggered by explcility selecting to have non-antialiased rendering. > under GNOME : > -run gnome-font-properties > -choose "monochrome" for rendering I've done that. And the resulting text does appear "ugly" to me, but I expect fonts like Vera to look ugly without antialiasing. So I'm not sure what the bug is here. Can you provide before and after screenshots of the bug you are seeing? > I think there might be another bug behind text rendering being damaged, > highlighted by KDE : Kcontrol allows to specify a font size range where > antialising is disabled and it seems when set, this range isn't checked and > antialiasing is disabled for all size. > > But let's focus on the first bug ;) Yes. Please help me understand what it is and how to reproduce it. -Carl
To all affected users who wish to help, please attach your fontconfig configurations and your gnome-font-properties font settings. What happens if you remove any local configs, or change settings in gnome-font-properties. What fonts are you using. Anything else you have customized on your system? And which distro is it you are using?
ok, let's start again :) I'm talking about text rendering being damaged, when antialising is disabled (see the attached ~/.fonts.conf file). To reproduce, just put the ~/.fonts.conf file and run gtk-demo (no need to run gnome-fonts-properties) : all the text in the treeview is truncated after the first space in text (see attached screenshot). I just did some regressions tests to make sure cairo is causing the issue : -when running with gtk+ 2.8.3 + pango 1.10.3 + cairo 1.0.0, text is displayed correctly -in this same environment, replacing cairo 1.0.0 with cairo 1.2.0, text is truncated to the first space.
Created attachment 6319 [details] .fonts.conf file disabling antialiasing
Created attachment 6320 [details] gtk-demo correctly rendered (with gtk+ 2.8.x + pango 1.10.x + cairo 1.0.0) with antialiasing disabled
Created attachment 6321 [details] gtk-demo incorrectly rendered (text is cut after first space), with cairo 1.2.0 + gtk+ 2.8.x and pango 1.10.x (same problem with gtk+ 2.10.x + pango 1.13.3)
(In reply to comment #9) > ok, let's start again :) Thank you! > I'm talking about text rendering being damaged, ... > all the text in the treeview is truncated after the > first space in text (see attached screenshot). And a thousand thanks for this extra information! It really helps to know that "damaged" means missing text after the first space. We have an existing bug 6617 which is exactly that text disappears after a space, and only for bitmapped fonts. And as it turns out that bug seems to depend on a bug in the X server. For example, I replicated the bug with Xorg without EXA, but the bug disappears when I switch to Xati. I'll look closer at the reports in that bug where people found that changes to cairo were successful at working around the server bug. -Carl
Created attachment 6354 [details] [review] Don't call XRenderAddGlyphs for zero-sized glyphs So here's my current take on this bug: I think there is an X server bug that is triggered by attempting to render (via XRenderAddGlyphs and XRenderCompositeText8, say) a glyph of size 0x0. And in particular I think this server bug only shows up when using a 1-bit glyph, (such as from a bitmapped font or from not doing antialiasing with an outline font). In cairo 1.0.2, cairo was carefully not rendering these size 0 glyphs at all. Then in cairo 1.0.4 it started rendering them again, which led to the bug report in bug 6617, (for bitmapped fonts). Meanwhile, there's some other problem in cairo 1.2.0 which is causing many fonts that should be drawn with antialiasing to be drawn with no antialiasing. So that caused many people to start seeing the disappearing text problem even with outline fonts. Here's a simple patch that should help the disappearing text problem go away. I'll need to look closer for a better fix, (or get keithp to review this), but in the meantime, people might find this patch useful. Even after this patch is cleaned up and committed, there's still the separate issue of why antialiasing is being mistakenly disabled. And there's also the matter of actually reporting the X server bug. -Carl
Looking at the patch, I see this: if (glyph_surface->width || glyph_surface->height) { Would it make sense to draw a 10x0 sized glyph?
(In reply to comment #15) > Looking at the patch, I see this: > if (glyph_surface->width || glyph_surface->height) { > > Would it make sense to draw a 10x0 sized glyph? No, so && could be "better" there, (though, since one being 0 without the other is so unlikely that it probably doesn't matter at all in practice). Meanwhile, the patch doesn't even seem to be fixing the bug, (I'm wondering now how I seemed to think it was), so it likely _really_ doesn't matter. -Carl
Created attachment 6359 [details] Simple test case to demonstrate the bug Here's a test case that can be used to demonstrate the bug without any need for fiddling with fonts.conf nor any other settings. I've also retitled the bug entry to make it more clear what we're dealing with here NOTE: In doing that, I've limited this bug entry to a single issue---the fact that text is not appearing after a space. If someone would like a bug entry for the fact thatn antialiasing is not being applied in some cases, then please feel free to open a new bug for that. One issue per bug report please. -Carl
(In reply to comment #16) > > Meanwhile, the patch doesn't even seem to be fixing the bug, (I'm wondering now > how I seemed to think it was), so it likely _really_ doesn't matter. > Please disregard the above. The first time I tested the patch I was doing it properly. But the second time, (which led to the above comment), I was actually running against a different version of cairo than I was compiling, so I was testing an unpatched cairo. The patch does seem to be fixing the bug, but I still feel a bit funny about the way it works. A cleaner patch will follow shortly. -Carl
Created attachment 6360 [details] [review] Elide size-zero glyphs from calls to XRender functions. Here's an alternate patch which avoids passing the size-zero glyphs to XRenderCompositeText{8,16,32} in addition to avoiding XRenderAddGlyphs. I feel much more comfortable that this patch will be less likely to do odd things, and it seems to fix the problem just as well as the previous patch. -Carl
I felt good enough about this that I've gone ahead and pushed this out to cairo's central tree now. So it's in the latest checkout of 1.2.1 from git and will appear in the upcoming 1.2.2 release. See: http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=456cdb3058f3b416109a9600167cd8842300ae14;hp=8601c2c68306c956744399099a941363d446b906 Thanks for all the reports, guidance, and patience on this one. -Carl
confirmed, this patch fixes the corrupted text issue. FYI, I can't reproduce the other famous "antialiased is always disabled if I set it to be disabled for only a font size range", so I think maybe people were not reporting the corrupted text bug correctly.
(In reply to comment #21) > confirmed, this patch fixes the corrupted text issue. Ditto, thanks for the fix. > FYI, I can't reproduce the other famous "antialiased is always disabled if I set > it to be disabled for only a font size range", so I think maybe people were not > reporting the corrupted text bug correctly. I think I've figured out what was all this about, and it's not cairo's fault. In fact, it's been a fix on cairo (http://gitweb.freedesktop.org/?p=cairo;a=commit;h=fe324c44153cf37a51b51883780daee5500173be, TTBOMK) what has exposed bugs in other layers. For example, if I set Xft.antialiasing to 0, with cairo 1.0.4 I still get antialiased apps, but not with cairo 1.2.0. This explain the behavior observed in comment 2, but it's still a bug on KDE (hopefully I can point to an URL later). Thanks.
> it's still a bug on KDE (hopefully I can point to an URL later). Oh yes. http://websvn.kde.org/branches/KDE/3.5/kdebase/kcontrol/krdb/krdb.cpp?rev=551202&r1=541552&r2=551202.
i have upgraded the cairo lib today from current archlinux repository. the build has already the patch included. guess what, i still cannot see the text after the 1st space :-(
(In reply to comment #24) > i have upgraded the cairo lib today from current archlinux repository. the > build has already the patch included. guess what, i still cannot see the text > after the 1st space :-( Could you provide more information? things like which application, bugs still appearing after logging into a new session, etc? Especially the last thing can be important: if one instance of epiphany or firefox for example is still running, spawning a 2nd instance will just command the first one to open a new window, which still renders using the old cairo library.
(In reply to comment #25) > Could you provide more information? things like which application, bugs still > appearing after logging into a new session, etc? Especially the last thing can > be important: if one instance of epiphany or firefox for example is still > running, spawning a 2nd instance will just command the first one to open a new > window, which still renders using the old cairo library. the issue seems to be an ultimate history after adding useXft=true and enableXft=true to ~/.qt/qtrc (Section [General]). sorry for disturbance.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.