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 > > [EMAIL PROTECTED]:~/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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
pgpg0mMyOoQbq.pgp
Description: PGP signature
