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 > > > > [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
signature.asc
Description: Digital signature
