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();".
If the gradient has constant alpha, then we can express it as a flattened
linear gradient. Otherwise, should the opacity vary across the gradient we
need to fallback.
This reverts commit 85ed37da33.
Adrian Johnson pointed out that iff the gradient has constant alpha then
it can be flattened. Reverting this commit in order to restore the
capability to handle gradient flattening.
