We've had these PDF and PS failures here for a *long* time,
(before the last major release for sure). It's a bug, but
we expect it to be there, so advertise it that way.
This is one of those chronically fragile tests. I'm assuming
some font changed or something, because the glyph positions
shifted (consistently) across all the backend. Doesn't look
like a bug.
We'll really need to do proper bundling of all font data to
avoid issues like this.
Very minor rasterization differences crept in here
from somewhere. Of course, it would be easier to
identify from *where* if we documented all the versions
of the various external libraries used in creating
reference images. But for now, the versions on the
machine of the person making the release win.
The difference here was just edge effects, (the kind of
thing that looks like glyph rasterization differences
but might in fact be due to minor rounding differences
in glyph positions). Either way, there's no problem
with respect to what the test is exercising.
If the vector surface matches the output from last time, then the
rasterisation is skipped - but we need to write the expected OUTPUT
filename to the log so that the image is referenced from index.html.
The following tests were added during the 1.7 cycle to
demonstrate bugs:
alpha-similar operator operator-alpha self-copy-overlap
In all cases, the identical bug existed in the last major
release, (1.6.4), so these are not new regressions, but merely
bugs that we're now aware of. The correct way to handle bugs
such as these is to mark them as expected failures (XFAIL).
The reasoning behind the -25 testing is that we want to ensure
that cairo provides translation invariance. However, for
many vector backends we use external rasterizers that don't
necessarily provide that translation invariance.
So this testing makes a bunch of failures appear that we don't
really care about, (and we don't even have a mechanism to turn
them off with custom reference images). For the release, I'm
just turning this off.
After the release, I plan to turn this back on, and then we could
fix this by ensuring that the vector output itself is unaffected
by a device offset, or by moving away from external rasterizers,
(see Chris's micro-gs work to test PostScript with cairo-based
rasterization).
The only difference in this case is whether there is blurring
of the image around the edges. That's a rasterization issue
that we don't care about, (we're testing that the correct
transformation is applied).
Like many other gradient tests, we're just capturing the buggy
output of poppler here, (though this time I *did* verify with
Adobe acroread that our PDF output seems to be correct).
These capture the current poppler output, (rather than the
ideal output). We're still waiting for poppler to start
using cairo gradients before this test will run through
cleanly. And even with these new reference images, there's
still some translation variance, so the -25 tests still
fail.
We don't care about the specifics of rasterization in the viewer
here, (though it still might be worth being more careful about
how we set /Interpolate---but that's not the point of this test).
Are patterns mutable? The image backend is quite happy to write and read
from the same surface, whereas the vector targets create snapshots... This
test case exploits that inconsistency.
Also the interested reader will note that not only does this demonstrate
translational invariance, but a discrepancy with similar surfaces.
Application of a pure-alpha similar source is inconsistently handled
across the backends. The PDF/PS backends allow the rgb channels to bleed
through and the SVG backend mixes in pure white.
Quote Kai-Uwe Behrmann:
"The expected behaviour for masking in Cairo is to set the mask according
to the current active matrix and apply unchanged to a to be masked
surface.
In SVG the mask element is bound to the masked object and thus the local
matrix from that image object applies to the nested mask as well."
This is a test case to exercise applying a mask to an image under
separate transformations.
Original patch by Kai-Uwe Behrmann, altered to run the test against all
backends (where it causes poppler to crash on my machine <evil grin>).
During the cairo summit it was decided that this API is to freetype-
specific to be in the general cairo interface for now. This will
likely come back again soon as a cairo_ft-specific interface.
If the native windowing system is disable (e.g. --disable-xlib) then the
test suite fails to build since the vector converters typically depend
upon gdk-pixbuf-2.0, which in turn depends upon a native gdk which
requires cairo to be built with support for the native windowing system. A
mess that should be resolved by separating rsvg and poppler into core and
higher-level libraries, but which we can workaround by simply ignoring
errors from undefined functions at link time.
The combination of the initial cairo_paint() and the translucent text
colors were causing image fallbacks that prevented the PS type 3 font
embedding from being tested.
The ability to draw glyphs with different metrics is useful when doing
font substitution with fixed layout like in pdf and I eventually plan on
adding code to poppler to do something similar.
Delete the results of previous runs if the reference images are more
recent.
There's still potential error if the conversion utility or its required
libraries are modified...
A slight variation on the simple fill-alpha theme is that if Company is
truly seeing a regression where we dither, the error on a constant
background will be small and might be missed by the test suite.
Benjamin Otte reported "who broke rgba fills? they look dithered with
recent git."
This commit is the result of a skim through the test-suite which revealed
no single test responsible for checking the basic operation of
"set_rgba(); fill();".
