Bug 7494

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.