[poppler] Stroke color of type 3 fonts
Michael Vrable
mvrable at cs.ucsd.edu
Wed Jun 18 11:39:20 PDT 2008
On Sun, Jun 08, 2008 at 06:05:49PM +0930, Adrian Johnson wrote:
>>> This pdf from the cairo test suite demonstrates the problem:
>>>
>>> http://annarchy.freedesktop.org/~ajohnson/user-font-pdf-argb32-out.pdf
>>
>> That pdf works correctly with the splash renderer so i don't see why
>> a patch on Gfx.cc is needed, i'd say a patch for the cairo renderer
>> is needed.
>
> Attaching a new patch for the cairo renderer to fix the bug.
I'm now seeing a crash with some PDFs in evince, and reverting this
patch fixes them. The error I'm seeing is
evince: cairo-pattern.c:679: cairo_pattern_destroy: Assertion `((*&(&pattern->ref_count)->ref_count) > 0)' failed.
My guess is that reference counts are not being updated on
fill_pattern/stroke_pattern when they are temporarily changed; if the
Type3 font happens to explicitly set the color, then the reference
counts can be corrupted.
Additionally, I believe it may be possible to have a Type3 font nested
inside another Type3 font, but using a single member variable to save
the old stroke color is not reentrant.
Fortunately, calls to beginType3Char/endType3Char are already wrapped in
calls to saveState/restoreState, so we don't need to save and restore
the stroke color in the Cairo backend--that will happen automatically.
This allows the code to be simplified.
We should still set the stroke pattern to the current fill pattern. Do
that, but with proper reference counting.
Patch is attached.
--Michael Vrable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: type3-crash.patch
Type: text/x-diff
Size: 2176 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/poppler/attachments/20080618/2dde34b9/attachment.patch
More information about the poppler
mailing list