Bug 696984: Type 3 fonts bbox fixes.

The upshot of debugging this is that:

 1) We can't trust the FontBBox. Certainly it appears that no
 one else trusts it.
 2) We can't trust the d1 values in all cases, as it can lead to
 use rendering glyphs far larger than we'd want to.

So we have the compromise used here.

 1) We never clip to the FontBBox.
 2) If the FontBBox is invalid, then we calculate the bbox
 from the contents of the data streams.
 3) If the FontBBox is valid, and the d1 rectangle given
 does not fit inside it, then we calculate the bbox from
 the contents of the data streams.

This could theoretically produce problems with glyphs that have
much more content than they actually need, and rely on the d1
rect to clip it down to sanity. If the FontBBox is invalid in
such fonts, we will go wrong.

It's not clear to me that this will actually work in Acrobat/
Foxit/gs etc either, so we defer handling this better until we
actually have an example.

Tested with bug 694952, and bug 695843 which were the last 2 in
this area.

1 files changed, 14 insertions, 0 deletions

diff --git a/source/fitz/geometry.c b/source/fitz/geometry.c
index f7a92816..1d3d0f66 100644
--- a/source/fitz/geometry.c
+++ b/source/fitz/geometry.c
@@ -538,3 +538,17 @@ fz_rect *fz_include_point_in_rect(fz_rect *r, const fz_point *p)
 
 	return r;
 }
+
+int fz_contains_rect(const fz_rect *a, const fz_rect *b)
+{
+	if (a == NULL || b == NULL)
+		return 0;
+	if (fz_is_empty_rect(b))
+		return 1;
+	if (fz_is_empty_rect(a))
+		return 0;
+	return ((a->x0 > b->x0) ||
+		(a->y0 > b->y0) ||
+		(a->x1 < b->x1) ||
+		(a->y1 < b->y1));
+}