Debian Bug report logs - #474136
Error when creating pdf charts for new FreeSerifItalic.ttf

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Davide Viti <zinosat@tiscali.it>

To: submit@bugs.debian.org

Subject: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 17:28:37 +0200

[Message part 1 (text/plain, inline)]

Package: fntsample
Version: 2.7-1

I get the following error when creating pdf (or ps) charts for FreeSerifItalic.ttf

zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301: _cairo_array_allocate: Assertion `array->num_elements + num_elements <= array->size' failed.

Not sure it it matters, but the ttf file (which can be grabbed from [1]),
was created with new fontforge (20080330, just entered in sid) from
the new ttf-freefont package (sources already in sid too)

regards,
Davide

[1] http://www.alioth.debian.org/~zinosat-guest/FreeSerifItalic.ttf

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Cc: cairo@cairographics.org

Subject: Re: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 11:09:21 -0700

[Message part 1 (text/plain, inline)]

On Thu, 3 Apr 2008 17:28:37 +0200, Davide Viti wrote:
> I get the following error when creating pdf (or ps) charts for
> FreeSerifItalic.ttf
>
> zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
> fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301:
> _cairo_array_allocate: Assertion `array->num_elements + num_elements
> <= array->size' failed.

Davide,

Thanks so much for the bug report, (particularly with the nice easy
recipe for replicating the bug).

I've done some git-bisect guided exploration of the issue along the
1.5.x branch. Here's what I found:

    * First, 1.4.10 doesn't appear to have the assertion bug

    * Along the 1.5 branch, the assertion failure first occurs here:

	commit b20e08999e2f6e7a72ee75a7c3fd865bf0368794
	Author: Adrian Johnson <ajohnson@redneon.com>
	Date:   Sun Sep 23 11:37:02 2007 +0930

	    Truetype Subsetting: Avoid failing when fonts are missing optional
	    tables

    * Then, the assertion failure disappears again here:

	commit e0187ad49b754c4024f1999155ed248616028582
	Author: Chris Wilson <chris@chris-wilson.co.uk>
	Date:   Thu Dec 27 12:46:13 2007 +0000

	    [cairo-path-fixed] Ensure the points array is naturally aligned,
	    take 2.

	    By enlarging buf_size to ensure the correct alignment of the points
	    array with the cairo_path_buf_t block, we can efficiently use the
	    padding bytes to store more ops.

I shared the above with Chris Wilson and he seemed quite mystified.

Davide's original report was about an assertion failure in cairo
1.4.14, so the bug may have been introduced and not subsequently fixed
in that branch. I haven't explored that issue at all.

Meanwhile, there's an independent bug that's perhaps even more
concerning. Namely, with cairo 1.5.16 (or current git master), the
results of running fntsample are totally wrong, (with the large glyphs
all misplaced by a consistent offset). The incorrect output can be
seen here:

	http://people.debian.org/~eugen/strange-output.pdf

Eugeniy Meshcheryakov, (the fntsample author), pointed out that the
assertion failure can be avoided with the following command line:

	fntsample -f FreeSerifItalic.ttf -o output.pdf -i -0xFFFFF

So I bisected with that command and found that the misplaced-glyphs
bug first shows up in the pdf-operators commit:

	commit 26c6159b1e2f5481fb18f5f06f01063002dd6c98
	Author: Adrian Johnson <ajohnson@redneon.com>
	Date:   Mon Jan 7 20:36:32 2008 +1030

	    Move the PDF drawing operators into cairo-pdf-operators.c

	    By defining PostScript functions the same as the PDF drawing
	    operators, this code can be shared by both the PDF and PS
	    backends.

The purpose of this commit was to allow the cairo-ps backend to share
code with cairo-pdf, but it wasn't intended to change the cairo-pdf
output. There's a lot of code movement here, and unfortunately some
code changes at the same time. For example, comparing the old
_cairo_pdf_surface_show_glyphs with the new
_cairo_pdf_operators_show_glyphs I see things like this:

-            _cairo_output_stream_printf (surface->output,
+            _cairo_output_stream_printf (pdf_operators->stream,
                                          "%f %f %f %f %f %f Tm\r\n",
                                          scaled_font->scale.xx,
                                          -scaled_font->scale.yx,
                                          -scaled_font->scale.xy,
                                          scaled_font->scale.yy,
                                          glyphs[i].x,
-                                         surface->height - glyphs[i].y);
+                                         glyphs[i].y);

...

-                        _cairo_output_stream_printf (surface->output,
+                        _cairo_output_stream_printf (pdf_operators->stream,
                                                      "%f %f Td\r\n",
                                                      (glyphs[i].x - Tlm_x)/scaled_font->scale.xx,
-                                                     -(glyphs[i].y - Tlm_y)/scaled_font->scale.yy);
+                                                     (glyphs[i].y - Tlm_y)/scaled_font->scale.yy);

So it looks like there's a semantic change in the coordinate-space of
the Y values happening at the same time this code is moving from one
file to another. So I'm left with a bit too much changing at once to
be able to identify any obvious problem here.

Hopefully Adrian will have some more insight, (and ideally a quick
fix).

-Carl

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Cc: cairo@cairographics.org

Subject: Re: [cairo] Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 11:22:30 -0700

[Message part 1 (text/plain, inline)]

On Thu, 03 Apr 2008 11:09:21 -0700, Carl Worth wrote:
> Meanwhile, there's an independent bug that's perhaps even more
> concerning. Namely, with cairo 1.5.16 (or current git master), the
> results of running fntsample are totally wrong, (with the large glyphs
> all misplaced by a consistent offset). The incorrect output can be
> seen here:

No, the glyphs aren't all consistently offset. Instead the first row
is correctly placed while the relative Y offsets of subsequent rows of
glyphs proceed in the wrong direction, (as if with the incorrect sign
for the Y offset).

> -                                         surface->height - glyphs[i].y);
> +                                         glyphs[i].y);
>
> ...
> -                                                     -(glyphs[i].y - Tlm_y)/scaled_font->scale.yy);
> +                                                     (glyphs[i].y - Tlm_y)/scaled_font->scale.yy);

So I feel like something related to these Y position changes must be
related. The above two changes don't seem consistent for example,
(both involve a change in the sign of glyphs[i].y but only one
involves a subtraction of surface->height).

But I'm definitely still flailing blindly here.

Quick, Adrian, come save me.

-Car

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Eugeniy Meshcheryakov <eugen@debian.org>

To: Carl Worth <cworth@cworth.org>, 474136@bugs.debian.org

Cc: Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>, cairo@cairographics.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 20:22:49 +0200

[Message part 1 (text/plain, inline)]

3 квітня 2008 о 11:09 -0700 Carl Worth написав(-ла):
> On Thu, 3 Apr 2008 17:28:37 +0200, Davide Viti wrote:
> > I get the following error when creating pdf (or ps) charts for
> > FreeSerifItalic.ttf
> >
> > zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
> > fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301:
> > _cairo_array_allocate: Assertion `array->num_elements + num_elements
> > <= array->size' failed.
> 
> Davide,
> 
> Thanks so much for the bug report, (particularly with the nice easy
> recipe for replicating the bug).
> 
> I've done some git-bisect guided exploration of the issue along the
> 1.5.x branch. Here's what I found:
> 
>     * First, 1.4.10 doesn't appear to have the assertion bug
It has this bug on i386 with libc6-i686 installed.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Eugeniy Meshcheryakov <eugen@debian.org>

To: 474136@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 20:26:56 +0200

[Message part 1 (text/plain, inline)]

reassign 474136 libcairo2
found 474136 1.4.14-1
found 474136 1.5.8-1
# also found in 1.5.16, but it is not in Debian
tags 474136 + upstream
thanks

This now looks like cairo bug to me. Reassigning it there.

3 квітня 2008 о 11:09 -0700 Carl Worth написав(-ла):
> On Thu, 3 Apr 2008 17:28:37 +0200, Davide Viti wrote:
> > I get the following error when creating pdf (or ps) charts for
> > FreeSerifItalic.ttf
> >
> > zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
> > fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301:
> > _cairo_array_allocate: Assertion `array->num_elements + num_elements
> > <= array->size' failed.
> 
> Davide,
> 
> Thanks so much for the bug report, (particularly with the nice easy
> recipe for replicating the bug).
> 
> I've done some git-bisect guided exploration of the issue along the
> 1.5.x branch. Here's what I found:
> 
>     * First, 1.4.10 doesn't appear to have the assertion bug
> 
>     * Along the 1.5 branch, the assertion failure first occurs here:
> 
> 	commit b20e08999e2f6e7a72ee75a7c3fd865bf0368794
> 	Author: Adrian Johnson <ajohnson@redneon.com>
> 	Date:   Sun Sep 23 11:37:02 2007 +0930
> 
> 	    Truetype Subsetting: Avoid failing when fonts are missing optional
> 	    tables
> 
>     * Then, the assertion failure disappears again here:
> 
> 	commit e0187ad49b754c4024f1999155ed248616028582
> 	Author: Chris Wilson <chris@chris-wilson.co.uk>
> 	Date:   Thu Dec 27 12:46:13 2007 +0000
> 
> 	    [cairo-path-fixed] Ensure the points array is naturally aligned,
> 	    take 2.
> 
> 	    By enlarging buf_size to ensure the correct alignment of the points
> 	    array with the cairo_path_buf_t block, we can efficiently use the
> 	    padding bytes to store more ops.
> 
> I shared the above with Chris Wilson and he seemed quite mystified.
> 
> Davide's original report was about an assertion failure in cairo
> 1.4.14, so the bug may have been introduced and not subsequently fixed
> in that branch. I haven't explored that issue at all.
> 
> Meanwhile, there's an independent bug that's perhaps even more
> concerning. Namely, with cairo 1.5.16 (or current git master), the
> results of running fntsample are totally wrong, (with the large glyphs
> all misplaced by a consistent offset). The incorrect output can be
> seen here:
> 
> 	http://people.debian.org/~eugen/strange-output.pdf
> 
> Eugeniy Meshcheryakov, (the fntsample author), pointed out that the
> assertion failure can be avoided with the following command line:
> 
> 	fntsample -f FreeSerifItalic.ttf -o output.pdf -i -0xFFFFF
> 
> So I bisected with that command and found that the misplaced-glyphs
> bug first shows up in the pdf-operators commit:
> 
> 	commit 26c6159b1e2f5481fb18f5f06f01063002dd6c98
> 	Author: Adrian Johnson <ajohnson@redneon.com>
> 	Date:   Mon Jan 7 20:36:32 2008 +1030
> 
> 	    Move the PDF drawing operators into cairo-pdf-operators.c
> 
> 	    By defining PostScript functions the same as the PDF drawing
> 	    operators, this code can be shared by both the PDF and PS
> 	    backends.
> 
> The purpose of this commit was to allow the cairo-ps backend to share
> code with cairo-pdf, but it wasn't intended to change the cairo-pdf
> output. There's a lot of code movement here, and unfortunately some
> code changes at the same time. For example, comparing the old
> _cairo_pdf_surface_show_glyphs with the new
> _cairo_pdf_operators_show_glyphs I see things like this:
> 
> -            _cairo_output_stream_printf (surface->output,
> +            _cairo_output_stream_printf (pdf_operators->stream,
>                                           "%f %f %f %f %f %f Tm\r\n",
>                                           scaled_font->scale.xx,
>                                           -scaled_font->scale.yx,
>                                           -scaled_font->scale.xy,
>                                           scaled_font->scale.yy,
>                                           glyphs[i].x,
> -                                         surface->height - glyphs[i].y);
> +                                         glyphs[i].y);
> 
> ...
> 
> -                        _cairo_output_stream_printf (surface->output,
> +                        _cairo_output_stream_printf (pdf_operators->stream,
>                                                       "%f %f Td\r\n",
>                                                       (glyphs[i].x - Tlm_x)/scaled_font->scale.xx,
> -                                                     -(glyphs[i].y - Tlm_y)/scaled_font->scale.yy);
> +                                                     (glyphs[i].y - Tlm_y)/scaled_font->scale.yy);
> 
> So it looks like there's a semantic change in the coordinate-space of
> the Y values happening at the same time this code is moving from one
> file to another. So I'm left with a bit too much changing at once to
> be able to identify any obvious problem here.
> 
> Hopefully Adrian will have some more insight, (and ideally a quick
> fix).
> 
> -Carl

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Eugeniy Meshcheryakov <eugen@debian.org>

To: Davide Viti <zinosat@tiscali.it>, 474136@bugs.debian.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 20:35:27 +0200

[Message part 1 (text/plain, inline)]

3 квітня 2008 о 17:28 +0200 Davide Viti написав(-ла):
> Package: fntsample
> Version: 2.7-1
> 
> I get the following error when creating pdf (or ps) charts for FreeSerifItalic.ttf
Hmm, i cannot reproduce this bug when generating ps charts...

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Chris Wilson <chris@chris-wilson.co.uk>

To: Carl Worth <cworth@cworth.org>

Cc: 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>, cairo@cairographics.org

Subject: Re: [cairo] Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 19:35:22 +0100

On Thu, 2008-04-03 at 11:09 -0700, Carl Worth wrote:
> On Thu, 3 Apr 2008 17:28:37 +0200, Davide Viti wrote:
> > I get the following error when creating pdf (or ps) charts for
> > FreeSerifItalic.ttf
> >
> > zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
> > fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301:
> > _cairo_array_allocate: Assertion `array->num_elements + num_elements
> > <= array->size' failed.
> 
> Davide,
> 
> Thanks so much for the bug report, (particularly with the nice easy
> recipe for replicating the bug).

My investigations suggest that the cause of the assertion failure is an
integer overflow during _cairo_array_grow_by() due to this chunk in
cairo-truetype-subset.c (line 574):
	if (be16_to_cpu (header.index_to_loc_format) == 0) {
	    begin = be16_to_cpu (u.short_offsets[index]) * 2;
	    end = be16_to_cpu (u.short_offsets[index + 1]) * 2;
	}
	else {
	    begin = be32_to_cpu (u.long_offsets[index]);
	    end = be32_to_cpu (u.long_offsets[index + 1]);
	}

	size = end - begin; /* <--overflow */

I've added some defensive code to treat the symptoms, but I don't know
whether the root cause is either a bad font or that we are
misinterpreting it.
--
Chris Wilson

Message #48 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Eugeniy Meshcheryakov <eugen@debian.org>

To: Carl Worth <cworth@cworth.org>, 474136@bugs.debian.org

Cc: Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>, cairo@cairographics.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 20:53:07 +0200

[Message part 1 (text/plain, inline)]

3 квітня 2008 о 11:09 -0700 Carl Worth написав(-ла):
> Meanwhile, there's an independent bug that's perhaps even more
> concerning. Namely, with cairo 1.5.16 (or current git master), the
> results of running fntsample are totally wrong, (with the large glyphs
> all misplaced by a consistent offset). The incorrect output can be
> seen here:
Simplified program that demonstrates this bug is attached. It expects
font as the only argument and gives wrong results on amd64 with cairo
1.5.x but not 1.4.14 (result is in file out.pdf).

Another version of this program gives assertion failure with
FreeSansItalic.ttf: http://article.gmane.org/gmane.comp.lib.cairo/9166
(file test.c, cairo 1.4.14 on amd64, but not 1.5.x).

[test.c (text/x-csrc, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Davide Viti <zinosat@tiscali.it>

To: Chris Wilson <chris@chris-wilson.co.uk>

Cc: Carl Worth <cworth@cworth.org>, 474136@bugs.debian.org, Adrian Johnson <ajohnson@redneon.com>, cairo@cairographics.org

Subject: Re: [cairo] Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 21:14:41 +0200

[Message part 1 (text/plain, inline)]

Hi Chris,

On Thu, Apr 03, 2008 at 07:35:22PM +0100, Chris Wilson wrote:
> My investigations suggest that the cause of the assertion failure is an
> integer overflow during _cairo_array_grow_by() due to this chunk in
> cairo-truetype-subset.c (line 574):
> 	if (be16_to_cpu (header.index_to_loc_format) == 0) {
> 	    begin = be16_to_cpu (u.short_offsets[index]) * 2;
> 	    end = be16_to_cpu (u.short_offsets[index + 1]) * 2;
> 	}
> 	else {
> 	    begin = be32_to_cpu (u.long_offsets[index]);
> 	    end = be32_to_cpu (u.long_offsets[index + 1]);
> 	}
> 
> 	size = end - begin; /* <--overflow */
> 
> I've added some defensive code to treat the symptoms, but I don't know
> whether the root cause is either a bad font or that we are
> misinterpreting it.

Here are the details about the font file in case you had to dig deeper:

ttf file is built from the fontforge package [1] version 20080323
using the latest version (20080330) of fontforge [2].
If you're using debian you're just an "apt-get source" away from those sources,
since both packages have been uploaded already.

Not sure it may help, but all started because of bug #472830, which hit me
because of the new "FontForge Spline Font Database (SFD) 2 format" introduced
in Fontforge and adopted by new freefont

thanx to all for such a detailed set of infos.
regards,
Davide


[1] http://ftp.gnu.org/gnu/freefont/freefont-sfd-20080323.tar.gz
[2] http://sourceforge.net/project/showfiles.php?group_id=103338&package_id=111040

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Davide Viti <zinosat@tiscali.it>

To: Eugeniy Meshcheryakov <eugen@debian.org>

Cc: Carl Worth <cworth@cworth.org>, 474136@bugs.debian.org, Adrian Johnson <ajohnson@redneon.com>, cairo@cairographics.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 3 Apr 2008 23:33:23 +0200

[Message part 1 (text/plain, inline)]

On Thu, Apr 03, 2008 at 08:53:07PM +0200, Eugeniy Meshcheryakov wrote:
> Another version of this program gives assertion failure with
> FreeSansItalic.ttf: http://article.gmane.org/gmane.comp.lib.cairo/9166
> (file test.c, cairo 1.4.14 on amd64, but not 1.5.x).

I found out that the problem does not reproduce if I run fntsample on a local terminal,
whereas it fails if I run it on a terminal over an ssh session. that's scary!

hope it helps
Davide

[signature.asc (application/pgp-signature, inline)]

Message #63 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Cc: cairo@cairographics.org

Subject: Re: [cairo] Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 15:28:04 -0700

[Message part 1 (text/plain, inline)]

On Thu, 03 Apr 2008 11:22:30 -0700, Carl Worth wrote:
> On Thu, 03 Apr 2008 11:09:21 -0700, Carl Worth wrote:
> > Meanwhile, there's an independent bug that's perhaps even more
> > concerning. Namely, with cairo 1.5.16 (or current git master), the
> > results of running fntsample are totally wrong, (with the large glyphs
> > all misplaced by a consistent offset). The incorrect output can be
> > seen here:
...
> But I'm definitely still flailing blindly here.
>
> Quick, Adrian, come save me.

And he did, too! Here's the fix that's in cairo now. So this will go
out into the next snapshot (if there is one) or into the cairo 1.6.0
release.

And Chris's fixes should make it so that cairo (again as of the next
1.5.x snapshot or the 1.6.0 release) no longer presents an assertion
failure in the cases that we've seen here.

It may still be that there's a totally bogus font here. And if so,
cairo will start reporting an out-of-memory error rather than
asserting. So that underlying bug should still be investigated and
fixed wherever it is.

But I'm quite glad to see the glpyh-positioning bug fixed. So many
thanks for the report.

-Carl

commit f6509933a4e0abde3b7bca861f65e433b7e8dcf0
Author: Adrian Johnson <ajohnson@redneon.com>
Date:   Fri Apr 4 08:41:08 2008 +1030

    PDF: Fix glyph positioning bug

diff --git a/src/cairo-pdf-operators.c b/src/cairo-pdf-operators.c
index 1dbb08c..1198b4e 100644
--- a/src/cairo-pdf-operators.c
+++ b/src/cairo-pdf-operators.c
@@ -946,7 +946,7 @@ _cairo_pdf_operators_show_glyphs (cairo_pdf_operators_t
                         _cairo_output_stream_printf (word_wrap_stream,
                                                      "%f %f Td ",
                                                      (glyphs[i].x - Tlm_x)/scaled_
-                                                     (glyphs[i].y - Tlm_y)/-scaled
+                                                     (glyphs[i].y - Tlm_y)/scaled_
                         Tlm_x = glyphs[i].x;
                         Tlm_y = glyphs[i].y;
                         Tm_x = Tlm_x;

[Message part 2 (application/pgp-signature, inline)]

Message #68 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: Eugeniy Meshcheryakov <eugen@debian.org>

Cc: 474136@bugs.debian.org, cairo@cairographics.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Subject: Re: [cairo] Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 17:18:57 -0700

[Message part 1 (text/plain, inline)]

On Thu, 3 Apr 2008 20:53:07 +0200, Eugeniy Meshcheryakov wrote:
> Simplified program that demonstrates this bug is attached. It expects
> font as the only argument and gives wrong results on amd64 with cairo
> 1.5.x but not 1.4.14 (result is in file out.pdf).

Excellent, thank you!

I used this as inspiration to write a new test case for cairo's test
suite, (ft-show-glyphs-table). And it nicely demonstrates Adrian's bug
fix for cairo-pdf.

Meanwhile, though, the test totally fails with cairo-ps, (all the
glyphs end up on top of each other). In general, we'd hope that a bug
fix in the cairo-pdf-operators.c, (which is the file used by both
cairo-pdf and cairo-ps in spite of "pdf" in the name), would fix both
backends. But clearly there's something else broken here.

Adrian, ready to work your magic again? I'll look and see if I can't
figure out something myself in the meantime. (I want whack-a-mole to
end now and let's get cairo 1.6 out the door.)

> Another version of this program gives assertion failure with
> FreeSansItalic.ttf: http://article.gmane.org/gmane.comp.lib.cairo/9166
> (file test.c, cairo 1.4.14 on amd64, but not 1.5.x).

Thanks for the report. So somebody might want to backport something
like Chris' recent fixes to 1.4, but it still likes like the assertion
failures have their original cause in a buggy font. Anyone interested
in looking closer at that?

-Carl

[Message part 2 (application/pgp-signature, inline)]

Message #73 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: Eugeniy Meshcheryakov <eugen@debian.org>

Cc: cairo@cairographics.org, 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Subject: Re: [cairo] Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Thu, 03 Apr 2008 17:43:38 -0700

[Message part 1 (text/plain, inline)]

On Thu, 03 Apr 2008 17:18:57 -0700, Carl Worth wrote:
> Adrian, ready to work your magic again? I'll look and see if I can't
> figure out something myself in the meantime.

In the failing PostScript output the part that attempts to position
and display the glyphs:

BT
/f-0-0 1 Tf
20 0 0 20 10 290 Tm
<01> Tj 0 -1.5 Td <02> Tj 0 -1.5 Td <03> Tj 0 -1.5 Td <04> Tj 0 -1.5 Td <05>
 Tj 0 -1.5 Td <06> Tj 0 -1.5 Td <07> Tj 0 -1.5 Td <08> Tj 0 -1.5 Td <09>
 Tj 0 -1.5 Td <0a> Tj 1.5 13.5 Td <0b> Tj 0 -1.5 Td <0c> Tj 0 -1.5 Td <0d>
 Tj 0 -1.5 Td <0e> Tj 0 -1.5 Td <0f> Tj 0 -1.5 Td <10> Tj 0 -1.5 Td <11>
 Tj 0 -1.5 Td <12> Tj 0 -1.5 Td <13> Tj 0 -1.5 Td <14> Tj 1.5 13.5 Td <15>
 Tj 0 -1.5 Td <16> Tj 0 -1.5 Td <17> Tj 0 -1.5 Td <18> Tj 0 -1.5 Td <19>
 Tj 0 -1.5 Td <1a> Tj 0 -1.5 Td <1b> Tj 0 -1.5 Td <1c> Tj 0 -1.5 Td <1d>
 Tj 0 -1.5 Td <1e> Tj 1.5 13.5 Td <1f> Tj 0 -1.5 Td <20> Tj 0 -1.5 Td <21>
 Tj 0 -1.5 Td <22> Tj 0 -1.5 Td <23> Tj 0 -1.5 Td <24> Tj 0 -1.5 Td <25>
 Tj 0 -1.5 Td <26> Tj 0 -1.5 Td <27> Tj 0 -1.5 Td <28> Tj ET

Looks exactly like the functional PDF version (as expected). (Of
course that takes "pdftk ft-show-glyphs-table-pdf-argb32-out.pdf
uncompress legible.pdf" before it can be easily read.)

So then the question is whether there's a bug in the PostScript
emulations of Td and Tj. They certainly look simple enough:

	/Td { moveto } bind def
	/Tj { show } bind def

I compared with the working ft-show-glyphs-positioning case, and there
the text is all placed with TM and TJ. So those are presumably
working, (which is fine by me since their PostScript emulations are
much trickier).

I'll probably have to do some more specification reading before I can
be of any more help here, (unless Adrian has the bug fixed before I
get around to that). The fact that the values passed to Td each time
are the same in every case suggests that there's some relative
positioning desired here. And the small values suggest that we want
these to be multiplied by the font matrix. Meanwhile the
implementation with just "moveto" suggests absolute placement, and the
resulting output suggests that we're not getting transformed values.

-Carl

[Message part 2 (application/pgp-signature, inline)]

Message #78 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Eugeniy Meshcheryakov <eugen@debian.org>

To: 474136@bugs.debian.org

Subject: Re: Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Fri, 4 Apr 2008 14:49:26 +0200

[Message part 1 (text/plain, inline)]

It looks like all those bugs are fixed in upstream git repository. At
least i cannot reproduce them on i386 and amd64.

3 квітня 2008 о 17:28 +0200 Davide Viti написав(-ла):
> Package: fntsample
> Version: 2.7-1
> 
> I get the following error when creating pdf (or ps) charts for FreeSerifItalic.ttf
> 
> zino@slurpy:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o test.pdf
> fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301: _cairo_array_allocate: Assertion `array->num_elements + num_elements <= array->size' failed.
> 
> Not sure it it matters, but the ttf file (which can be grabbed from [1]),
> was created with new fontforge (20080330, just entered in sid) from
> the new ttf-freefont package (sources already in sid too)
> 
> regards,
> Davide
> 
> [1] http://www.alioth.debian.org/~zinosat-guest/FreeSerifItalic.ttf

[signature.asc (application/pgp-signature, inline)]

Message #83 received at 474136@bugs.debian.org (full text, mbox, reply):

From: Carl Worth <cworth@cworth.org>

To: Eugeniy Meshcheryakov <eugen@debian.org>

Cc: cairo@cairographics.org, 474136@bugs.debian.org, Davide Viti <zinosat@tiscali.it>, Adrian Johnson <ajohnson@redneon.com>

Subject: Re: [cairo] Bug#474136: Error when creating pdf charts for new FreeSerifItalic.ttf

Date: Fri, 04 Apr 2008 16:11:42 -0700

[Message part 1 (text/plain, inline)]

On Thu, 03 Apr 2008 17:43:38 -0700, Carl Worth wrote:
> 	/Td { moveto } bind def
> 	/Tj { show } bind def
...
> I'll probably have to do some more specification reading before I can
> be of any more help here, (unless Adrian has the bug fixed before I
> get around to that).

Which of course, he did (see below).

Many thanks, Adrian!

-Carl

PS. The original assertion failure doesn't seem to exist on 1.5.x now,
and we've added guards to make sure it should instead report an
out-of-memory error even if some bogus font data is provided.

So, from a mainline cairo-development point of view, I think we're
done here. Thanks for the report!

commit e50324d3cc66df83120f908845657382e0020868
Author: Adrian Johnson <ajohnson@redneon.com>
Date:   Fri Apr 4 19:21:40 2008 +1030

    PS: Fix emulation of 'Td' pdf operator

diff --git a/src/cairo-ps-surface.c b/src/cairo-ps-surface.c
index e78e247..54f5afe 100644
--- a/src/cairo-ps-surface.c
+++ b/src/cairo-ps-surface.c
@@ -183,7 +183,8 @@ _cairo_ps_surface_emit_header (cairo_ps_surface_t *surface)
                                 "    { show } { -0.001 mul 0 cairo_font_matrix dtr
                                 "  } forall\n"
                                 "} bind def\n"
-                                "/Td { moveto } bind def\n"
+                                "/Td { matrix translate cairo_font_matrix matrix c
+                                "   /cairo_font_matrix exch def cairo_font exch se
                                 "/Tm { 6 array astore dup /cairo_font_matrix exch
                                 "      cairo_font exch selectfont 0 0 moveto } bin
                                 "/g { setgray } bind def\n"

[Message part 2 (application/pgp-signature, inline)]

Message #88 received at 474136-close@bugs.debian.org (full text, mbox, reply):

From: Sebastian Dröge <slomo@debian.org>

To: 474136-close@bugs.debian.org

Subject: Bug#474136: fixed in cairo 1.6.4-1

Date: Tue, 15 Apr 2008 20:47:06 +0000

Source: cairo
Source-Version: 1.6.4-1

We believe that the bug you reported is fixed in the latest version of
cairo, which is due to be installed in the Debian FTP archive:

cairo_1.6.4-1.diff.gz
  to pool/main/c/cairo/cairo_1.6.4-1.diff.gz
cairo_1.6.4-1.dsc
  to pool/main/c/cairo/cairo_1.6.4-1.dsc
cairo_1.6.4.orig.tar.gz
  to pool/main/c/cairo/cairo_1.6.4.orig.tar.gz
libcairo-directfb2-dev_1.6.4-1_i386.deb
  to pool/main/c/cairo/libcairo-directfb2-dev_1.6.4-1_i386.deb
libcairo-directfb2-udeb_1.6.4-1_i386.udeb
  to pool/main/c/cairo/libcairo-directfb2-udeb_1.6.4-1_i386.udeb
libcairo-directfb2_1.6.4-1_i386.deb
  to pool/main/c/cairo/libcairo-directfb2_1.6.4-1_i386.deb
libcairo2-dbg_1.6.4-1_i386.deb
  to pool/main/c/cairo/libcairo2-dbg_1.6.4-1_i386.deb
libcairo2-dev_1.6.4-1_i386.deb
  to pool/main/c/cairo/libcairo2-dev_1.6.4-1_i386.deb
libcairo2-doc_1.6.4-1_all.deb
  to pool/main/c/cairo/libcairo2-doc_1.6.4-1_all.deb
libcairo2_1.6.4-1_i386.deb
  to pool/main/c/cairo/libcairo2_1.6.4-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 474136@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sebastian Dröge <slomo@debian.org> (supplier of updated cairo package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 15 Apr 2008 20:07:29 +0200
Source: cairo
Binary: libcairo2-dev libcairo2 libcairo2-dbg libcairo2-doc libcairo-directfb2-udeb libcairo-directfb2 libcairo-directfb2-dev
Architecture: source i386 all
Version: 1.6.4-1
Distribution: unstable
Urgency: low
Maintainer: Dave Beckett <dajobe@debian.org>
Changed-By: Sebastian Dröge <slomo@debian.org>
Description: 
 libcairo-directfb2 - The Cairo 2D vector graphics library DirectFB build
 libcairo-directfb2-dev - Development files for Cairo graphics library DirectFB build
 libcairo-directfb2-udeb - The Cairo 2D vector graphics library DirectFB build (udeb)
 libcairo2  - The Cairo 2D vector graphics library
 libcairo2-dbg - The Cairo 2D vector graphics library (debugging symbols)
 libcairo2-dev - Development files for the Cairo 2D graphics library
 libcairo2-doc - Documentation for the Cairo Multi-platform 2D graphics library
Closes: 348109 413690 421266 423951 474136 474395
Changes: 
 cairo (1.6.4-1) unstable; urgency=low
 .
   * New upstream release:
     + Works on remote Sun displays by adding support for
       8 bit pseudocolors (Closes: #348109).
     + Adds support for 32 bit visuals (Closes: #421266).
     + Adds support for 655 xlib format (Closes: #413690).
     + Fixes error when creating pdf charts (Closes: #474136).
     + Fixes assertions in cairo_destroy (Closes: #423951).
     + Fixes display errors with iceweasel 3.0 (Closes: #474395).
     + debian/control:
       - Update build dependencies and dependencies.
       - Add myself as co-maintainer.
       - Fix spelling error.
     + debian/rules:
       - Update shlibs to >= 1.6.0 because of API additions.
     + debian/libcairo2.symbols,
       debian/libcairo-directfb2.symbols:
       - Add symbol files for the libraries.
Checksums-Sha1: 
 ffc86706df6e4bb7d8b51149c6bc2a2327d8633e 1391 cairo_1.6.4-1.dsc
 9d990fe39a125ceb07221623c237cd7015855d5c 5042623 cairo_1.6.4.orig.tar.gz
 34da46a2547e292df21b83dda2972bceeb988e30 23690 cairo_1.6.4-1.diff.gz
 417f3f2e379d8961425380f4d514be43aabeb15c 590908 libcairo2-dev_1.6.4-1_i386.deb
 7476c6d3f39331af689ae9b796cbe1c56add90f8 526374 libcairo2_1.6.4-1_i386.deb
 7cda428d4ebcf307f4d9f59bdeabae06eacd5903 745124 libcairo2-dbg_1.6.4-1_i386.deb
 da4062167de0bb968e413eaf149f24d7245a8772 470006 libcairo2-doc_1.6.4-1_all.deb
 ec39f14d74c589661a38c973f6dbd2645af4d5ac 149386 libcairo-directfb2-udeb_1.6.4-1_i386.udeb
 00f2a41b347108979493c113b996f299e12a4d24 484428 libcairo-directfb2_1.6.4-1_i386.deb
 617cf03555904a45951d6bb913a609833ee86063 542890 libcairo-directfb2-dev_1.6.4-1_i386.deb
Checksums-Sha256: 
 26fbb85212f2dbe7e3d5dee6bb5006e7ef644b8bf72f931f947243df7d6377c3 1391 cairo_1.6.4-1.dsc
 7f0ce28c358706913bc39e6930a18ae89f3b9a6aa17998faa2b59d1e0e2b4f42 5042623 cairo_1.6.4.orig.tar.gz
 bffc010961725210a43d87537bafca1780f731a7b7659e6516f93ae4ea19ae4f 23690 cairo_1.6.4-1.diff.gz
 c03ecfb728b6242ece680ac3ead3635addaff0763072682e019eaf81a69f6720 590908 libcairo2-dev_1.6.4-1_i386.deb
 2411320903ec338fe9796a51aaf2dd1cbdc9ba25f5d331b11950d7d75374e0e5 526374 libcairo2_1.6.4-1_i386.deb
 1ebaf06b06e8f35df3f7d0af044b608c64522045e18460fd172c679b2c771ded 745124 libcairo2-dbg_1.6.4-1_i386.deb
 0496805c578bc1918743be36ae13447ce2dfa37da6590594b47981609fd6ef55 470006 libcairo2-doc_1.6.4-1_all.deb
 a8f96ce8c99c4956b438a01e7f75a116e54dd33b94397f9700e7db4084787de8 149386 libcairo-directfb2-udeb_1.6.4-1_i386.udeb
 538638eb0546b6cd2b98a949a88b4c05b30ddb722e19b5f5cebf8a7e8dda6e88 484428 libcairo-directfb2_1.6.4-1_i386.deb
 4845cbc883e9a79455dd12a22dc2e1403f361e34a653cec1dbdd11aa75a23e20 542890 libcairo-directfb2-dev_1.6.4-1_i386.deb
Files: 
 0a6dafa27bf881431c0a8341b6baf1dc 1391 libs optional cairo_1.6.4-1.dsc
 a198d509f9e3a35b78de8bb02174ebb9 5042623 libs optional cairo_1.6.4.orig.tar.gz
 ee0ca877b81b2e3fcec123fa39382e67 23690 libs optional cairo_1.6.4-1.diff.gz
 89f8442a4c7ac0398e34ea76c0e3ddfa 590908 libdevel optional libcairo2-dev_1.6.4-1_i386.deb
 d202260c88dcf65aba2483bd91ccccd0 526374 libs optional libcairo2_1.6.4-1_i386.deb
 6892ab37f6e5fcfd03b95178a8e02ae6 745124 libdevel extra libcairo2-dbg_1.6.4-1_i386.deb
 81baac60e9a96053b747821ca14916ec 470006 doc optional libcairo2-doc_1.6.4-1_all.deb
 168bb261acda902f36118ec4e6403194 149386 debian-installer optional libcairo-directfb2-udeb_1.6.4-1_i386.udeb
 fe9683f23ad0672ee8f9b3570b2939ed 484428 libs optional libcairo-directfb2_1.6.4-1_i386.deb
 259598662d1d7aea37076629e517f1d5 542890 libdevel optional libcairo-directfb2-dev_1.6.4-1_i386.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIBQguBsBdh1vkHyERAvhlAJ9tVQRPSYeiYJCau9u24xLLVDyEKgCbBbe0
oqTnLU5C6cVG38zMZCUFV+I=
=D4+/
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.