Bug 6617 - With cairo 1.0.4, when drawing bitmapped text to xlib backend, text after the first space does not appear
Summary: With cairo 1.0.4, when drawing bitmapped text to xlib backend, text after the...
Alias: None
Product: cairo
Classification: Unclassified
Component: xlib backend (show other bugs)
Version: 1.1.1
Hardware: x86 (IA32) Linux (All)
: high blocker
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2006-04-16 12:10 UTC by Sérgio Martins
Modified: 2006-07-27 00:34 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:

Proposed fix (1.16 KB, patch)
2006-06-14 04:34 UTC, Carl Worth
Details | Splinter Review
Stress test case (4.32 KB, text/x-csrc)
2006-06-25 02:21 UTC, Carl Worth
My /usr/share/fonts/artwiz-aleczapka (49.22 KB, application/x-gzip)
2006-06-25 08:21 UTC, Sérgio Martins
small gtk app that ilustrates the problem, includes testfont.pcf (14.74 KB, application/x-gzip)
2006-07-12 10:42 UTC, Sérgio Martins
Test case requiring just cairo and xlib (2.74 KB, text/plain)
2006-07-26 13:43 UTC, Carl Worth
Patch for cairo 1.0.4 (1019 bytes, patch)
2006-07-26 13:45 UTC, Carl Worth
Details | Splinter Review

Description Sérgio Martins 2006-04-16 12:10:37 UTC
I'm using sylpheed-claws e-mail client.

Since I upgraded from cairo 1.0.2 to 1.0.4, when i click on a message, the text
disappears, only the first word remains visible.

It only happens with some fonts, like artwiz(snap, nu...) and matto < size 11.

Here are some shots:

Before clicking on a message:


When i move the scrollbar up and down the text reappears.
Comment 1 Sérgio Martins 2006-05-15 01:10:16 UTC
Here's some more information:

a) When i downgrade to cairo-1.0.2 the text is fine again.

b) It also happens with gaim and firefox. (Not allways)

c) I dont see any error messages in stderr/stdin.
Comment 2 Sérgio Martins 2006-05-15 03:42:39 UTC
I downloaded the source and started reverting changes until i found the bug:


This patch is the culprit :)

Adding back this if fixes the problem.

- if (width * height == 0) {
- if (own_buffer && bitmap->buffer)
- free (bitmap->buffer);
- val->image = NULL;
- } else {

(artwiz fonts are bitmap font's btw)

Comment 3 James Le Cuirot 2006-05-16 11:41:52 UTC
I have this problem too.


It doesn't happen with all artwiz fonts, not "drift", for example. Note that 
these are the artwiz-aleczapka fonts. The original artwiz fonts don't work with 
Comment 4 Behdad Esfahbod 2006-06-14 00:49:00 UTC
Don't remember when heard about this, but the problem seems to be with the two
"malloc (stride * height)" lines in _get_bitmap_surface.  If height == 0, it's
not a failure that malloc is returning NULL.  We need to somehow handle it.

Carl, this is a blocker for 1.2
Comment 5 Carl Worth 2006-06-14 04:34:01 UTC
Created attachment 5906 [details] [review]
Proposed fix

Here's a patch that I'm willing to push out.

Please test this and let me know if it fixes the problem for you.

Comment 6 James Le Cuirot 2006-06-14 05:29:44 UTC
That patch wouldn't apply against 1.0.4 and even when applied manually, it 
wouldn't compile because "surface" wasn't declared. I'll try it against CVS 
Comment 7 Carl Worth 2006-06-14 06:28:35 UTC
Right, for testing against 1.0.4 use val->image instead of surface.

Comment 8 Sérgio Martins 2006-06-14 08:57:10 UTC
I guess it doesn't work against cairo-1.1.6, the bug is still there.
Comment 9 James Le Cuirot 2006-06-14 12:55:26 UTC
No change on 1.0.4 either, I'm afraid.
Comment 10 Behdad Esfahbod 2006-06-14 13:43:51 UTC
Carl's patch should be applied anyway.  If it doesn't fix your problem, it means
that the commit you have pointed to is not the cause, and there's another reason
to believe so: that if it was the cause you should have been getting crashes
before.  The old code path very obviously dereferences a NULL pointer.

So, another bisecting session may help.
Comment 11 Carl Worth 2006-06-14 14:38:57 UTC
It would be useful if I could replicate this bug.

If someone could point to a freely available font and also a particular string
to display in the font, that would be great.

Ideally I would just change two lines in cairo/test/show-text-current-point and
be able to replicate the problem.

Comment 12 Sérgio Martins 2006-06-14 15:29:27 UTC
> Carl's patch should be applied anyway.  If it doesn't fix your problem, it
> means that the commit you have pointed to is not the cause.

The exact location of the bug might be in another place. But i'm 100% sure it
was this commit that triggered the bug.

I tried all commits. If i start with cairo-1.0.2 and apply the commits one by
one and test if the bug appears it only appear with the commit that i pointed out.

Carl's patch works if instead of
+    if (width == 0 || height == 0) {
+	*surface = (cairo_image_surface_t *)
+	    cairo_image_surface_create (CAIRO_FORMAT_A1, 0, 0);
+	return (*surface)->base.status;
+    }

you use:
+    if (width == 0 || height == 0) {
+    }

Comment 13 Sérgio Martins 2006-06-14 15:40:17 UTC
Carl wrote:
> It would be useful if I could replicate this bug.


Download artwiz-aleczapka fonts. For example, try using the "snap" font.
Download sylpheed-claws and read some mail. :) (se screenshots in comment #1)

Other gtk2 are also affected, but i can't reproduce allways, so i suggest you
use sylpheed-claws.
Comment 14 James Le Cuirot 2006-06-14 15:47:36 UTC
Recent versions of Sylpheed-Claws are also GTK2. I found it effected my GTK2 
apps most of the time though.
Comment 15 Sérgio Martins 2006-06-14 15:58:25 UTC
One more clue:

monospaced (aka fixed width) bitmap fonts aren't affected, that's why "drift"
was ok (in comment #3).

proportional fonts are the problem.
Comment 16 Carl Worth 2006-06-14 16:02:25 UTC
I'd recommend trying the zero-size glyph handling from _render_glyph_outline
(see below). If it works I would even say we should abstract this code and share
it as _render_glyph_size_zero or so.

If someone can give this a try and let me know if it works better than my last
patch, then I can put the complete thing together.


    if (width * height == 0) {
        cairo_format_t format;
        /* Looks like fb handles zero-sized images just fine */
        switch (font_options->antialias) {
            format = CAIRO_FORMAT_A1;
            format= CAIRO_FORMAT_ARGB32;
            format = CAIRO_FORMAT_A8;

        (*surface) = (cairo_image_surface_t *)
            cairo_image_surface_create_for_data (NULL, format, 0, 0, 0);
        if ((*surface)->base.status)
            return CAIRO_STATUS_NO_MEMORY;
Comment 17 Sérgio Martins 2006-06-14 16:35:52 UTC
Carl, that didn't work.

Comment 18 Behdad Esfahbod 2006-06-14 20:46:45 UTC
What does it print if you do:

+    if (width == 0 || height == 0) {
+	*surface = (cairo_image_surface_t *)
+	    cairo_image_surface_create (CAIRO_FORMAT_A1, 0, 0);
+       printf ("%s\n", cairo_status_to_string ((*surface)->base.status));
+	return (*surface)->base.status;
+    }
Comment 19 Sérgio Martins 2006-06-14 21:03:01 UTC
it prints: success
Comment 20 Behdad Esfahbod 2006-06-14 21:40:46 UTC
This is getting hairy.  Ok, what about this one:

+    if (width == 0 || height == 0) {
+	*surface = (cairo_image_surface_t *)
+	    cairo_image_surface_create (CAIRO_FORMAT_A1, 1, 1);
+	return (*surface)->base.status;
+    }
Comment 21 Sérgio Martins 2006-06-14 22:02:21 UTC
with 1.0.4 both sans and snap (from artwiz) are affected, with your last fix
only sans 12 is affected
Comment 22 Sérgio Martins 2006-06-16 22:28:19 UTC
I tried running cairo-1.1.6/test/show-text-current-point with "snap" font.
Almost all generated png's were fine. All but this one:

*** glibc detected *** double free or corruption (!prev): 0x08067c60 ***
show-text-current-point-ps-argb32 [0]:  Aborted

Comment 23 Carl Worth 2006-06-25 02:21:33 UTC
Created attachment 6034 [details]
Stress test case

Here's a test program that should help. Compile with:

cc `pkg-config --cflags cairo` `freetype-config --cflags` `pkg-config --libs
cairo` `freetype-config --libs` -lpng font2png.c -o font2png

Then run it with bitmap fonts of interest. A useful test is:

locate '*.pcf' | xargs ./font2png

And see the resulting PNG files.

On my system when I run the above command against cairo 1.0.4 various of the
resulting png images have garbage in them, (but interestingly when I re-run it
against the individual font files show the garbage, then things look fine).

More interestingly, when I run the above command against cairo 1.1.11 (as of
now) it generates correct results in all cases.

So I'm wondering if the bug is already fixed. Can you test cairo 1.1.10
(available as a snapshot tar file) or 1.1.11 (available via git clone) and tell
me how it works in your original tests (with sylpheed, for example).


Comment 24 Sérgio Martins 2006-06-25 08:16:43 UTC
With cairo-1.0.2 it segfaulted

With cairo-1.0.4 it produced garbage, then i run it individualy and it was fine.

cairo-1.1.10 still has this bug. I tested it with sylpheed-claws.

So i guess this test (font2png) doesn't test this bug, with cairo-1.0.4 it was
supposed to fail and it didn't.

With GTK apps not all widgets are affected. Maybe if you could try to reproduce
the bug?
Comment 25 Sérgio Martins 2006-06-25 08:21:09 UTC
Created attachment 6041 [details]
My /usr/share/fonts/artwiz-aleczapka

Here's my /usr/share/fonts/artwiz-aleczapka-en dir, maybe you have to restart X
to use these fonts.

Try using snap. (or other proportional font)
Comment 26 Behdad Esfahbod 2006-07-06 10:51:50 UTC
Found this comment in bug 6918 (irrelevant to cairo) that may shed some light on
the issue of why 1.0.2 has not been crashing for the reporter:

This patch is based one the patch of Dave Turner, and fix a type error when
tt_get_metrics. This fix glyph broken with dejavu and other truetype font. This
patch add a deal with glyph with zero height control box which freetype 2.2.1
thinks it is invalid and freetype 2.1.9 just ignores it. This fix warning about
FreeTypeRasteriseGlyph() return error on glyph that has zero height. And also
some fix to let it behave as the original.

So, seems like FreeType has been doing something special with zero-height glyphs
Comment 27 Dave Beckett 2006-07-06 15:27:24 UTC
Here's another report of this bug with cairo 1.2.0 on debian:
there are attached screenshots.  It was reported as not a problem in cairo 1.0.4.

Comment 28 Sérgio Martins 2006-07-06 17:47:26 UTC
I installed cairo-1.2.0 and i can confirm comment #27, this bug now affects all

1.0.2 = good and no segfaults (at least for me)
1.0.4 - 1.1.8 = proportional bitmap fonts disappering
1.2.0 = All fonts disappearing
Comment 29 Behdad Esfahbod 2006-07-08 14:53:14 UTC
The all-fonts-disappearing is a separate bug, possibly in pango.  I'm tracking
it down.
Comment 30 Behdad Esfahbod 2006-07-08 14:55:00 UTC
Humm, maybe not.
Comment 31 Adeodato Simó 2006-07-09 11:59:24 UTC
Okay, let's see. I'm seeing something at least similar to this (arrived
here via Debian Bug#377147, http://bugs.debian.org/377147). My 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

(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 -> 

(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 
  #     Reviewed by: otaylor, cworth

  PNG -> 

(c) a fix for the above is introduced the next day:

  % git checkout -b fix_after_big_commit 

  # 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 -> 

(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 -> 

In case it's relevant, I'm using fontconfig 2.3.2-7, and my ~/.fonts.conf file
can be found here:


But none of the other three possible AA/hinting combinations yield any
different result.

Comment 32 Carl Worth 2006-07-10 16:23:51 UTC
(In reply to comment #27)
> Here's another report of this bug with cairo 1.2.0 on debian:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376714
> there are attached screenshots.  It was reported as not a problem in cairo 1.0.4.

Please don't piggy-back an unrelated bug on top of a current bug!

The original report of this bug is for something that changed between 1.0.2 and
1.0.4 and we've been putting in a bunch of effort to properly understand and
characterize it.

You're reporting something that changed between 1.0.4 and 1.2.0 so that's
definitely a different bug, so the comments for that belong in a separate bug

Comment 33 Adeodato Simó 2006-07-10 16:34:36 UTC
(In reply to comment #32)
> Please don't piggy-back an unrelated bug on top of a current bug!

I just sent it to the upstream bug that the Debian maintainer of cairo, whom I 
consider more knowledgeable on cairo stuff that myself, marked the Debian's 
#377147 as forwarded to.

If that was a mistake, I'll be happy to repost the above comment to a new bug, 
and adjust the "upstream bug" tag in Debian's BTS.

Sorry for the inconvenience.
Comment 34 Sérgio Martins 2006-07-12 10:42:39 UTC
Created attachment 6209 [details]
small gtk app that ilustrates the problem, includes testfont.pcf

well, i hope you can reproduce it..
just read README
Comment 35 Carl Worth 2006-07-12 22:57:11 UTC
(In reply to comment #34)
> small gtk app that ilustrates the problem, includes testfont.pcf
> well, i hope you can reproduce it..

Thanks very much for the test case. I wasn't able to reproduce at first, but I
did after disabling EXA in my X server.

So it looks very X-specific.

I might revisit my font2png test and make it draw to X instead and see how that

Anyway, we should be much closer to tracking this down now. So thanks again.


Comment 36 Daniel Santos 2006-07-16 12:05:56 UTC
Thank you all, this bug's been a pain in my backside (found a workaround for
Mozilla, setting the environment variable MOZ_DISABLE_PANGO to 1)...  This
apparently effects Firefox (at least) on KDE systems where you have GTK+ installed.

Comment 37 Jozef Riha 2006-07-26 01:25:33 UTC
http://video.google.com/videoplay?docid=4185884872188535455&hl=en - a flash 
video that illustrates the problem (cairo 1.2.0)
Comment 38 Carl Worth 2006-07-26 13:36:06 UTC
So I understand this bug, (that is, the 1.0.4-specific incaranation of
"disappearing text), fairly well now, and have a small test case as well as a
fix which I'll be attaching.

There is definitely an X server bug here, for which I can make a direct,
(non-cairo-using), test case later.

I've updated the description to make it a bit more descriptive.

Comment 39 Carl Worth 2006-07-26 13:43:26 UTC
Created attachment 6351 [details]
Test case requiring just cairo and xlib

In my previous attempt at writing a test case for this bug, I had missed the
fact that the bug is only exhibited with the xlib backend.

Here's a simple cairo-xlib test case that uses the snap font.

As I've mentioned previously, this bug does depend on an X server bug as well.
I'm seeing the buggy behavior with Xorg (from HEAD later than 7.1) without EXA.
I do not see the bug with Xati HEAD.

Comment 40 Carl Worth 2006-07-26 13:45:43 UTC
Created attachment 6352 [details] [review]
Patch for cairo 1.0.4

Here's a patch that should fix the bug. This was generated against cairo's 1.0
branch, so should fix the problem in cairo 1.0.4.

With the testcase-6617 I recently attached and Xorg HEAD I see correct behavior
in cairo 1.0.2, buggy behavior in cairo 1.0.4, and correct behavior in cairo
1.0.5 with this patch applied.

Comment 41 Carl Worth 2006-07-27 00:34:44 UTC
I've now pushed this fix out into cairo's 1.0 branch:


So it's there in the interim version "1.0.5" now and would appear if we ever
made another release in the 1.0 series (1.0.6). But I'm not sure there's any
need for that now---for example, the equivalent bug is also fixed in 1.2.1 now,
and I don't know of any compelling reason that someone might want to upgrade
from 1.0.4 and not upgrade to 1.2.

But let me know if the 1.0.6 would be useful and we can certainly do it easily


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.