Right now the two filters are implemented identically, so there's
no real change for now. But in the future, it's conceivable that an
X server could implement some crazy, high-quality filter for BEST
without regard to performance, (since that's what BEST means).
Meanwhile, GOOD actually captures what we want by default which is
a good mix of both quality and performance.
If the .notdef glyph is the first glyph in the subset to be mapped in
scaled font, we do not know if the subset will scaled or unscaled. We
can put it in the unscaled subset as Type1-fallback will embded an
empty glyph if it can not get the path.
Bug 15348 references the following PDF that was printing incorrectly
when running through poppler and cairo to generate PostScript.
http://launchpadlibrarian.net/12921700/UbuntuDesktop.pdf
The PostScript output had too much space between each word causing
strings of glyphs printed with the TJ operator to overlap.
The original PDF file contains an CFF font with CID Identity-H
encoding. The PDF file is using character code 0 (glyph 0 due to
Identity-H encoding) as a space character. The CFF specification
defines glyph 0 to be the .notdef glyph.
The PS backend subsets CFF fonts as a Type1-fallback
font. Type1-fallback creates it's own empty .notdef glyph with an
arbitrary glyph advance of 500. The problem here is the TJ operator
used to output the glyphs depends on the glyph advance being
correct. pdf-operators.c uses the glyph advance returned by
_scaled_glyph_init(). However the PostScript interpreter sees the
glyph advance of 500 for .notdef. This problem does not occur when
generating PDF as the PDF font dictionary contains an list of glyph
advances that override the font metrics.
Fix this by making Type1-fallback not treat .notdef as special and to
create it the path and metrics obtained from _scaled_glyph_init(). As
a special case, make it not fail if _scaled_glyph_init() is unable to
return a path for .notdef. This was probably the reason Type1-fallback
previously created it's own .notdef glyph as calling
_scaled_glyph_init(_GLYPH_INFO_PATH) for glyph 0 returns
CAIRO_INT_STATUS_UNSUPPORTED for some fonts.
This ensures the Type1-fallback font metrics match the metrics used
by pdf-operators.c to position the glyphs. This also results in the
removal of some duplicated code.
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 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.
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).
