The problem showed up on OS X because the freetype backend reuses font_face_t's
which kept the reference count high enough for long enough to avoid the problem.
As opposed to 8.61.
I had actually forgotten we had documented this. If I had
remembered I could have put more meaningful messages with
some of my recent updates to ps-specific reference images.
It's sad to have to do this. Back with commit 1a9809baa was the
original fix for device-offset-scale, (right after the test was
added), and it fixed it for all backends, including SVG. The fix
involved combining device_transform and CTM into the pattern matrix.
But then, we added the mask-transformed-image and
mask-transformed-similar tests, and commit 20be3182ef for fixing an
SVG-specific bug with masks. That fix involved subtracting away the
pattern matrix when emitting a mask to adhere to SVG semantics.
Unfortunately, this change also made the device-offset-scale test
start failing. A correct fix would probably subtract away only the CTM
portion and not the devive_transform. However, the
_cairo_svg_surface_mask function sees only a pattern matrix and
doesn't know how to separate it into CTM and device_transform pieces.
So fixing this will probably require a change to the surface-backend
interface. And since we're not willing to do that so close to a major
release, we're adding yet another XFAIL.
Thanks to help from Chris, we fixed the bug that was making this
test fail with the PDF backend. All that was left was differing
treatment of the edges of the image---easy enough to address
with a pdf-specific reference image.
The only difference here is a tie-breaker condition for image-
sampling position. While we care about that when it's under our
control, (pixman rasterization), we don't have precise
requirements for ghostscript's sampling. So we can capture the
current result as a reference.
These two tests currently fail only for the PS backend,
but they've done so since before the last major release.
The final image result we're getting is definitely wrong
in both cases, but we have not yet been able to verify
if this is due to bugs in cairo (generating PostScript)
or in ghostscript (interpreting and rasterzing the
PostScript).
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...
