diff options
author | Robin Watts <robin.watts@artifex.com> | 2012-12-18 19:37:50 +0000 |
---|---|---|
committer | Robin Watts <robin.watts@artifex.com> | 2012-12-19 15:20:26 +0000 |
commit | d4d3b774f21f3a8a238a4f67bc01132119c97a94 (patch) | |
tree | 9de55d45d277129228febcfedcc620805822d2a9 /fitz/fitz-internal.h | |
parent | 956945485624f0df0ffdfbd471a4ec095bd145c9 (diff) | |
download | mupdf-d4d3b774f21f3a8a238a4f67bc01132119c97a94.tar.xz |
Bug 693503: 'Flatten' display list for all type3 glyphs.
It is perfectly allowable to have type3 glyphs that refer to
other type3 glyphs in the same font (and in theory it's probably
even possible to have type3 glyphs that refer back and forth
between 2 or more type3 fonts).
The old code used to cope with this just fine, but with the change
to 'early loading' of the glyphs to display lists at interpret time
a problem has crept in. When we load the type 3 font, we load
each glyph in turn. If glyph 1 tries to use glyph 2, then we look
up the font, only to find that that the font has not been installed
yet, so we reload the entire font. This gets us into an infinite
loop.
As a fix for this, we split the loading of the type3 font into 2; we
load the font as normal, then allow the font to be inserted into
the list of current fonts. Then we run through the glyphs in the
font 'preparing' them (turning them into display lists).
This solves the infinite loop issue, but causes another problem;
recursive references (such as a font holding a display list that
contains a text node that contains a reference to the original font)
result in us never being able to free the structures.
To avoid this, we insist on never allowing type3 glyphs to be referenced
within a type3 display list. The display lists for all type3 glyphs
are therefore 'flat'. We achieve this by adding a 'nested' flag to
the pdf command stream interpreter structure, and setting this in the
case where we are running a glyph stream. We check for that flag in the
type3 glyph render function, and if present, we force the 'render_direct'
path to be used.
Finally, we ensure that fz_text groups are not needlessly created with
no contents.
Problem found in 2923.pdf.asan.22.2139, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
Diffstat (limited to 'fitz/fitz-internal.h')
-rw-r--r-- | fitz/fitz-internal.h | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/fitz/fitz-internal.h b/fitz/fitz-internal.h index 35b20d71..b8d34d80 100644 --- a/fitz/fitz-internal.h +++ b/fitz/fitz-internal.h @@ -1031,7 +1031,7 @@ struct fz_font_s float *t3widths; /* has 256 entries if used */ char *t3flags; /* has 256 entries if used */ void *t3doc; /* a pdf_document for the callback */ - void (*t3run)(void *doc, void *resources, fz_buffer *contents, fz_device *dev, fz_matrix ctm, void *gstate); + void (*t3run)(void *doc, void *resources, fz_buffer *contents, fz_device *dev, fz_matrix ctm, void *gstate, int nestedDepth); void (*t3freeres)(void *doc, void *resources); fz_rect bbox; /* font bbox is used only for t3 fonts */ @@ -1173,8 +1173,8 @@ 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_bbox scissor); fz_pixmap *fz_render_stroked_glyph(fz_context *ctx, fz_font*, int, fz_matrix, fz_matrix, fz_stroke_state *stroke, fz_bbox scissor); -void fz_render_t3_glyph_direct(fz_context *ctx, fz_device *dev, fz_font *font, int gid, fz_matrix trm, void *gstate); -void fz_prepare_t3_glyph(fz_context *ctx, fz_font *font, int gid); +void fz_render_t3_glyph_direct(fz_context *ctx, fz_device *dev, fz_font *font, int gid, fz_matrix trm, void *gstate, int nestedDepth); +void fz_prepare_t3_glyph(fz_context *ctx, fz_font *font, int gid, int nestedDepth); /* * Text buffer. |