If the operator is unbounded, then its area of effect extends beyond
the definition of the mask by the trapezoids and so we must always perform
the image composition.
Fixes test/operator*.
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
Images in PDF are scaled to a unit square. In PS we set the
ImageMatrix to do the same. When the image is painted we scale the
graphics state to paint the image at the right size. In the case of
Type 3 fonts consisting of bitmap images we want to paint the images
at their original size so we scale the graphics state by the image
width and height.
The bug was that we were scaling by the width/height in the glyph
metrics. For non rotated fonts this worked. However for rotated fonts
the width/height of the glyph images may be larger than the
width/height in the glyph metrics. This resulted in a Type 3 font
where the glyph images were scaled slightly smaller than they should
have been.
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.
