bb76eb50 added some checks to ensure we do not read past the end of
the buffer for the loaded glyph. However the checks assumed
tt_composite_glyph_t has a fixed size. tt_composite_glyph_t has a
variable size that depends on the values with the struct.
Sanity check the arguments to _cairo_array_grow_by() such that the
array size does not overflow, similar to the defensive checking of
parameters to malloc.
Pixman stores the bits A1 surfaces in native byte order, PDF stores
A1 masks in MSb - so only perform swapping for little-endian machines.
Note this also removes the extraneous packing as per the PDF spec 4.8.2:
"Byte boundaries are ignored, except that each row of sample data must
begin on a byte boundary. If the number of data bits per row is not a
multiple of 8, the end of the row is padded with extra bits to fill out
the last byte."
Previously, given a valid XRenderFormat the Visual was discarded
when creating similar surfaces. However the original Visual is
required to support reading back from non-TrueColor surfaces.
We cannot guarantee that a newly created error stream is a static error
object, so we need to always destroy the stream on the error path. (One
day this may change with the global pool of error objects...)
The compiler isn't clever enough to notice that these
variables are always initialized (in either the TrueColor
or ! TrueColor conditions corresponding to the later
identical conditions in which the variables are used).
Previously we were using the cairo_fixed_t type which meant we've
historically only been using 16 bits of precision for these offsets,
and recently only 8 bits. Meanwhile, all manipulatons of offsets
have been in floating-point anyway, so we might as well store them
that way.
This change also prevents a rendering regression introduced with the
24.8->16.16 change betwen snapshots 1.5.10 and 1.5.12 .
This change affected gradient-rendering details for the clip-operator
and operator-source tests, so the corresponding reference images are
updated here.
We still don't handle these format codes of course, (they're meaningless
for the context in which they're used here).
Note that we previously avoided adding these to avoid people being forced
to upgrade pixman just to get two enum values that cairo doesn't really
care about. But now we're depending on a new pixman anyway, (for the
pixman_format_code_to_masks function), so we'll go ahead and do this now.
This allows us to do a much more general and complete implementation of
_pixman_format_from_masks and _pixman_format_to_masks so that we'll
even pick up new pixman formats as they get added.
The cairo_path_extents function can perform better than either
cairo_stroke_extents or cairo_fill_extents, so provide that
pointer from the documentation of the other two functions.
