5050c55f93 fixed type1-fallback to use the glyph advance instead of
glyph width in the stored glyph metrics in the font. However it did
not fix the same bug in Type 2 charstrings (used by CFF fallback in
PDF). This problem was not noticed since the glyph widths in the PDF
font dictionary overrides these values.
Fix this in case any software reading cairo PDFs uses these values.
If _cairo_scaled_glyph_lookup() returns CAIRO_INT_STATUS_UNSUPPORTED
it will be caught by the ASSERT_NOT_REACHED in
_emit_unscaled_font_subset in PS/PDF. It is more useful to catch this
closer to the source.
This fixes the filter-bilinear-extents test case and the
related bug entry:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
Though there are still differences in the PDF and PostScript
backends, (primarily because we can't capture cairo's filter
modes in those file formats).
This test exercises code that computes the extents of a surface
pattern with CAIRO_FILTER_BILINEAR, (where the filtering
effectively increases the extents of the pattern).
The original bug was reported by Owen Taylor here:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
This covers the known-to-broken 1.3 servers such as appeared
in Fedora 8. It also leaves the workaround off, (since it's
a severe slowdown), for the known-to-be-working 1.4.99.901
server as appears in Fedora 9 Betas.
XRenderAddGlyph() does not split its image data across multiple requests
and so the glyph surface must be smaller than XMaxRequestSize or else
the server will disconnect the client, causing "Fatal IO error 104".
As this will require an extension to the XRender spec, we can work
around the issue by using our fallbacks if we detect that the glyph will
be too large for a single request.
See bugs https://bugs.freedesktop.org/show_bug.cgi?id=4339 and
http://bugs.freedesktop.org/show_bug.cgi?id=13266 for examples.
PDF has a concept of "soft" masks, for which it is able to construct a
mask out of PDF drawing operations. These tests exercise constructing
various masks using the high level drawing operations.
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.
Interestingly, this test case does demonstrate that cairo-pdf
is fixed, (where without commit f6509933a4 the Y positions
of the glyphs were inverted); however, cairo-ps is failing
with this test, (all the glyphs are ending up on top of each
other).
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...)
An especial thanks to Vladimir Vukicevic and the Mozilla
Foundation for a tremendous amount of work on cairo-quartz
while it has been marked as "experimental"
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).
