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.

1 files changed, 23 insertions, 9 deletions

diff --git a/fitz/fitz.h b/fitz/fitz.h
index 769111e3..ccfa0bd6 100644
--- a/fitz/fitz.h
+++ b/fitz/fitz.h
@@ -200,9 +200,9 @@ The macro based nature of this system has 3 main limitations:
 	start of fz_try and something in fz_try throwing an exception may become
 	undefined as part of the process of throwing that exception.
 
-As a way of mitigating this problem, we provide an fz_var() macro that
-tells the compiler to ensure that that variable is not unset by the
-act of throwing the exception.
+	As a way of mitigating this problem, we provide an fz_var() macro that
+	tells the compiler to ensure that that variable is not unset by the
+	act of throwing the exception.
 
 A model piece of code using these macros then might be:
 
@@ -1052,7 +1052,7 @@ struct fz_font_s
 	char *t3flags; /* has 256 entries if used */
 	void *t3xref; /* a pdf_xref for the callback */
 	void (*t3run)(void *xref, fz_obj *resources, fz_buffer *contents,
-		struct fz_device_s *dev, fz_matrix ctm);
+		struct fz_device_s *dev, fz_matrix ctm, void *gstate);
 
 	fz_rect bbox;	/* font bbox is used only for t3 fonts */
 
@@ -1063,7 +1063,7 @@ struct fz_font_s
 
 	/* substitute metrics */
 	int width_count;
-	int *width_table; // in 1000 units
+	int *width_table; /* in 1000 units */
 };
 
 void fz_new_font_context(fz_context *ctx);
@@ -1081,6 +1081,7 @@ void fz_debug_font(fz_font *font);
 
 void fz_set_font_bbox(fz_font *font, float xmin, float ymin, float xmax, float ymax);
 fz_rect fz_bound_glyph(fz_context *ctx, fz_font *font, int gid, fz_matrix trm);
+int fz_glyph_cacheable(fz_font *font, int gid);
 
 /*
  * Vector path buffer.
@@ -1164,6 +1165,8 @@ void fz_debug_path(fz_path *, int indent);
  * Glyph cache
  */
 
+typedef struct fz_device_s fz_device;
+
 void fz_new_glyph_cache_context(fz_context *ctx);
 void fz_free_glyph_cache_context(fz_context *ctx);
 
@@ -1172,6 +1175,7 @@ fz_pixmap *fz_render_t3_glyph(fz_context *ctx, fz_font *font, int cid, fz_matrix
 fz_pixmap *fz_render_ft_stroked_glyph(fz_context *ctx, fz_font *font, int gid, fz_matrix trm, fz_matrix ctm, fz_stroke_state *state);
 fz_pixmap *fz_render_glyph(fz_context *ctx, fz_font*, int, fz_matrix, fz_colorspace *model);
 fz_pixmap *fz_render_stroked_glyph(fz_context *ctx, fz_font*, int, fz_matrix, fz_matrix, fz_stroke_state *stroke);
+void fz_render_t3_glyph_direct(fz_context *ctx, fz_device *dev, fz_font *font, int gid, fz_matrix trm, void *gstate);
 
 /*
  * Text buffer.
@@ -1288,12 +1292,22 @@ enum
 	FZ_IGNORE_SHADE = 2,
 
 	/* Flags */
-	FZ_CHARPROC_MASK = 1,
-	FZ_CHARPROC_COLOR = 2,
+	FZ_DEVFLAG_MASK = 1,
+	FZ_DEVFLAG_COLOR = 2,
+	FZ_DEVFLAG_UNCACHEABLE = 4,
+	FZ_DEVFLAG_FILLCOLOR_UNDEFINED = 8,
+	FZ_DEVFLAG_STROKECOLOR_UNDEFINED = 16,
+	FZ_DEVFLAG_STARTCAP_UNDEFINED = 32,
+	FZ_DEVFLAG_DASHCAP_UNDEFINED = 64,
+	FZ_DEVFLAG_ENDCAP_UNDEFINED = 128,
+	FZ_DEVFLAG_LINEJOIN_UNDEFINED = 256,
+	FZ_DEVFLAG_MITERLIMIT_UNDEFINED = 512,
+	FZ_DEVFLAG_LINEWIDTH_UNDEFINED = 1024,
+	/* Arguably we should have a bit for the dash pattern itself being
+	 * undefined, but that causes problems; do we assume that it should
+	 * always be set to non-dashing at the start of every glyph? */
 };
 
-typedef struct fz_device_s fz_device;
-
 struct fz_device_s
 {
 	int hints;