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.
There is an implicit precedence when analyzing patterns for
compatibilty, in order of descending precedence:
fatal error
unsupported
needs image fallback
needs meta-surface analysis
success.
So wehen we have two patterns, we need to check both analysis statuses
simulataneously, in order to correctly report the combined status.
The primary bug here was some missing braces. The code was conditionally
assigning to backend_status, but then unconditionally checking for the
value assigned. The result was the leaking of an internal status value
(CAIRO_INT_STATUS_ANALYZE_META_SURFACE) which finally resulted in
an incomplete PDF file in the mask-transformed-similar test case.
While fixing this, also avoid re-using the backend_status variable so
much so that the code is more readable.
Since these functions are static we don't really need the full
name. And these two functions were both so long that they were
causing some serious line-wrap issues.
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.
Commit 20b1b33c0f added some "paranoid checks" to our png
loading code. One of these was checking that if png_get_IHDR
first reports an interlace value other than PNG_INTERLACE_NONE
that after we call png_set_interlace_handling then we do
get PNG_INTERLACE_NONE from the next call to png_get_IHDR.
However, libpng doesn't seem to actually have that behavior.
When testing cairo_image_surface_create_from_png with an
interlanced PNG file, (which the test suite happens not to
do---even now), the call to png_set_interlace_handling is
doing the trick, but the check for PNG_INTERLACE_NONE is
failing.
So, with the check in place, loading an interlaced PNG image
fails with CAIRO_STATUS_READ_ERROR. By simply removing
that check, an interlaced image loads just fine.
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.
I renamed those generated files to Makefile.*.features but forgot to
update ignore lists. Carl already added the new ones, but didn't
remove the old ones.
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).
I know that I didn't create these Makefile.win32.features files,
so I assume that they are the result of Behdad's build magic and
that he just forgot to add them to .gitignore.
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).
This reverts commit c9ec82f3a8, which
notably caused regresions in the mask and clip-operator tests.
Obviously I'm not smart enough to fix bugs. Since the computer found the
assertion failure, I need to train the computer to fix the bugs as well.
The win32 build system has no way to install anything, but it has
full knowledge of what needs to be installed (which headers). So
we now report files to be installed at the end of the build.
We are being cheap and don't define the cairo_utf8_to_utf16 function
if no one is using it. Previously PS surface was not using it, but
after the pdf-operators merge, it was.
Before this commit, building with PS but without PDF failed. Fixing.
We never do #ifdef-type conditions on CAIRO_HAS_* macros, because we
want to allow setting them to zero. Then if we need to enable a feature
if either of PS or PDF is enabled, the proper syntax is:
#if CAIRO_HAS_PS_SURFACE || CAIRO_HAS_PDF_SURFACE
This works because the preprocessor replaces any unknown identifiers with
zero. Some versions of gcc had a bug that got them very confused with
complex versions of the above. As a workaround for that I have been using
the uglier version:
#if CAIRO_HAS_PS_SURFACE+0 || CAIRO_HAS_PDF_SURFACE+0
which magically worked around that bug. Or more recently replacing that
with the duplicated version:
#if CAIRO_HAS_PS_SURFACE
...
#endif
#if CAIRO_HAS_PDF_SURFACE
...
#endif
Both are uglier than the original. Since the gcc bug was very short lived
and there's lots of software out there relying on the original form to work,
moving back to the simple version seems harmless.
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.
This reverts commit 03c37f56b2.
The AC_PROG_MKDIR_P is also one of those autoconf macros defined
in newer versions only. Since we use mkdir -p in releasing scripts
only, it's not a big deal if it's not portable.
We don't need to tessellate edges strictly above or below the
hit-test point.
(Patch split and modified by Chris Wilson to apply to cairo_in_stroke()
as well - all bugs are his alone.)
Both the source and mask need to be analyzed and checked for an
UNSUPPORTED operation before determining the best course of action.
As before this is simply decided based on the requirements of the
source.
If either point lies on the limit and the other outside, adjust the line
to be parallel to the boundary. This adjusts the previous test where both
points needed to be entirely outside.
Use the utility functions _cairo_box_from_rectangle and
_cairo_box_round_to_rectangle() instead of open-coding. Simultaneously
tweak the whitespace so that all users of traps look similar.
When reporting the extents of the traps, constrain them to the imposed
limits. This is relied upon in the analysis-surface which sets the
limits on the traps (based on clip/surface extents) and then reports the
extents of the traps as the region of the operation.
Avoid the iterative search for the extreme points by first checking the
most likely arrangement (as produced by cairo_rectangle() under no
transformation).
A surface pattern under an extreme transformation could lie entirely in
the negative quadrant. This would trigger the fixup such that it's lower
left corner was clamped to the origin, but the upper right corner was left
unchecked. This could result in the width,height being negative and
wrapping around to large values instead of being clamped to 0.
