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.

I downloaded the source and started reverting changes until i found the bug:

http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=af0cbe2aed0b19613b90e171a2c252e8c8327efd;hp=6da5947efa6fbd0da85352974c2eb762bd42ffa7

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)

I have this problem too.

http://bugs.gentoo.org/show_bug.cgi?id=132297

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 
GTK2.

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

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.

-Carl

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 
later.

Right, for testing against 1.0.4 use val->image instead of surface.

-Carl

I guess it doesn't work against cairo-1.1.6, the bug is still there.

No change on 1.0.4 either, I'm afraid.

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.

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.

-Carl

> 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) {
+	
+	return CAIRO_STATUS_SUCCESS;
+    }

Carl wrote:
> It would be useful if I could replicate this bug.

http://sourceforge.net/project/showfiles.php?group_id=95348

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.

Recent versions of Sylpheed-Claws are also GTK2. I found it effected my GTK2 
apps most of the time though.

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.

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.

-Carl

    if (width * height == 0) {
        cairo_format_t format;
        /* Looks like fb handles zero-sized images just fine */
        switch (font_options->antialias) {
        case CAIRO_ANTIALIAS_NONE:
            format = CAIRO_FORMAT_A1;
            break;
        case CAIRO_ANTIALIAS_SUBPIXEL:
            format= CAIRO_FORMAT_ARGB32;
            break;
        case CAIRO_ANTIALIAS_DEFAULT:
        case CAIRO_ANTIALIAS_GRAY:
        default:
            format = CAIRO_FORMAT_A8;
            break;
        }

        (*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;
    }

Carl, that didn't work.

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;
+    }

it prints: success

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;
+    }

with 1.0.4 both sans and snap (from artwiz) are affected, with your last fix
only sans 12 is affected

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

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).

Thanks,

-Carl

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?

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)

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:

<quote>
This patch is based one the patch of Dave Turner, and fix a type error when
call
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.
</quote>

So, seems like FreeType has been doing something special with zero-height glyphs
previously.

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.

I installed cairo-1.2.0 and i can confirm comment #27, this bug now affects all
fonts.

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

The all-fonts-disappearing is a separate bug, possibly in pango.  I'm tracking
it down.

Humm, maybe not.

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

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

-Carl

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

Created attachment 6209 [details]
small gtk app that ilustrates the problem, includes testfont.pcf

well, i hope you can reproduce it..
just read README

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

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

-Carl

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.

Daniel

http://video.google.com/videoplay?docid=4185884872188535455&hl=en - a flash 
video that illustrates the problem (cairo 1.2.0)

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.

-Carl

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.

-Carl

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.

-Carl

I've now pushed this fix out into cairo's 1.0 branch:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=71e9372bbdc5c85e14dfc1156269ae6f74802f4d

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
enough.

-Carl