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

[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 at 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 at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080403/ece2b3f4/attachment.pgp