Bug 7494 - With cairo 1.2.0, non-antialiased xlib text doesn't appear after first space
With cairo 1.2.0, non-antialiased xlib text doesn't appear after first space
Status: VERIFIED FIXED
Product: cairo
Classification: Unclassified
Component: xlib backend
1.2.0
x86 (IA32) Linux (All)
: high blocker
Assigned To: Owen Taylor
cairo-bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-11 13:34 UTC by Adeodato Simó
Modified: 2006-07-28 23:23 UTC (History)
7 users (show)

See Also:


Attachments
.fonts.conf file disabling antialiasing (517 bytes, text/plain)
2006-07-24 02:36 UTC, Frederic Crozat
Details
gtk-demo correctly rendered (with gtk+ 2.8.x + pango 1.10.x + cairo 1.0.0) with antialiasing disabled (13.66 KB, image/png)
2006-07-24 02:37 UTC, Frederic Crozat
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) (11.44 KB, image/png)
2006-07-24 02:38 UTC, Frederic Crozat
Details
Don't call XRenderAddGlyphs for zero-sized glyphs (1.42 KB, patch)
2006-07-26 16:01 UTC, Carl Worth
Details | Splinter Review
Simple test case to demonstrate the bug (2.76 KB, text/plain)
2006-07-26 23:28 UTC, Carl Worth
Details
Elide size-zero glyphs from calls to XRender functions. (3.61 KB, patch)
2006-07-27 00:07 UTC, Carl Worth
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Adeodato Simó 2006-07-11 13:34:12 UTC
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.
Comment 1 Jan de Groot 2006-07-11 23:17:31 UTC
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.
Comment 2 Adeodato Simó 2006-07-15 10:15:07 UTC
(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.
Comment 3 Jan de Groot 2006-07-15 15:31:51 UTC
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.
Comment 4 Frederic Crozat 2006-07-19 10:24:05 UTC
same problem on Mandriva cooker when AA is disabled,
http://qa.mandriva.com/show_bug.cgi?id=23823

Comment 5 Frederic Crozat 2006-07-21 09:34:33 UTC
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 ;)
Comment 6 Behdad Esfahbod 2006-07-21 10:50:30 UTC
I can't reproduce by choosing Monospace.  However, I've heard that having ranges
to disable antialiasing is what causes the bug.
Comment 7 Carl Worth 2006-07-21 11:46:27 UTC
(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
Comment 8 Behdad Esfahbod 2006-07-23 23:34:08 UTC
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?
Comment 9 Frederic Crozat 2006-07-24 02:34:41 UTC
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.
Comment 10 Frederic Crozat 2006-07-24 02:36:31 UTC
Created attachment 6319 [details]
.fonts.conf file disabling antialiasing
Comment 11 Frederic Crozat 2006-07-24 02:37:37 UTC
Created attachment 6320 [details]
gtk-demo correctly rendered (with gtk+ 2.8.x + pango 1.10.x + cairo 1.0.0) with antialiasing disabled
Comment 12 Frederic Crozat 2006-07-24 02:38:55 UTC
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)
Comment 13 Carl Worth 2006-07-24 08:59:19 UTC
(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
Comment 14 Carl Worth 2006-07-26 16:01:43 UTC
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
Comment 15 Jan de Groot 2006-07-26 23:10:49 UTC
Looking at the patch, I see this:
if (glyph_surface->width || glyph_surface->height) {

Would it make sense to draw a 10x0 sized glyph?
Comment 16 Carl Worth 2006-07-26 23:19:18 UTC
(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
Comment 17 Carl Worth 2006-07-26 23:28:21 UTC
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
Comment 18 Carl Worth 2006-07-27 00:04:10 UTC
(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
 
Comment 19 Carl Worth 2006-07-27 00:07:05 UTC
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
Comment 20 Carl Worth 2006-07-27 00:28:57 UTC
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
Comment 21 Frederic Crozat 2006-07-27 02:56:21 UTC
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.
Comment 22 Adeodato Simó 2006-07-27 07:17:59 UTC
(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.
Comment 23 Adeodato Simó 2006-07-27 07:34:02 UTC
> 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.
Comment 24 Jozef Riha 2006-07-28 13:44:37 UTC
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 :-(
Comment 25 Jan de Groot 2006-07-28 14:10:47 UTC
(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.
Comment 26 Jozef Riha 2006-07-28 23:23:13 UTC
(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.