diff options
| author | Robin Watts <robin.watts@artifex.com> | 2012-01-17 00:23:13 +0000 |
|---|---|---|
| committer | Robin Watts <robin@ghostscript.com> | 2012-01-18 13:11:52 +0000 |
| commit | 2c836b57d5295b47655988cf8deaffda731e1c3c (patch) | |
| tree | 01b0e51a30412ac90e53993f59c9cc649a8aa88d /pdf/pdf_type3.c | |
| parent | b2c87fcd70b3f069388755baf7baa6b3c2590123 (diff) | |
| download | mupdf-2c836b57d5295b47655988cf8deaffda731e1c3c.tar.xz | |
Better handling of 'uncacheable' Type3 glyphs. Bug 692745.
Some Type 3 fonts contain glyphs that rely on inheriting various
aspects of the graphics state from their calling code. (i.e. a
glyph might use d0, then fill an area without setting a color
first).
While the spec is vague on this point, we believe that technically
it is invalid. Previously mupdf defaulted all elements of the graphic
state back when beginning to draw the glyph. This does not match
what Acrobat does though, so we change the approach taken.
We now watch (by use of bits in the device flags word) for the use
of parts of the graphics state before it is set. If such use is
detected, then we note that the glyph is 'uncacheable' and render
it direct.
This seems to match Acrobats behaviour.
Diffstat (limited to 'pdf/pdf_type3.c')
| -rw-r--r-- | pdf/pdf_type3.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/pdf/pdf_type3.c b/pdf/pdf_type3.c index f43170c4..d9bf528e 100644 --- a/pdf/pdf_type3.c +++ b/pdf/pdf_type3.c @@ -2,9 +2,9 @@ #include "mupdf.h" static void -pdf_run_glyph_func(void *xref, fz_obj *rdb, fz_buffer *contents, fz_device *dev, fz_matrix ctm) +pdf_run_glyph_func(void *xref, fz_obj *rdb, fz_buffer *contents, fz_device *dev, fz_matrix ctm, void *gstate) { - pdf_run_glyph(xref, rdb, contents, dev, ctm); + pdf_run_glyph(xref, rdb, contents, dev, ctm, gstate); } pdf_font_desc * |