[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