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.
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.
The meta-surface workaround an old bug, which is no longer present in the
tree and open-coded the surface snapshot. However, the workaround itself
was buggy (not respecting the surface content). The lesson to take away
from this is not to add workarounds in test code for bugs in the library!
As PS has different semantics regarding a zero-length dash, we need to
adjust the dash array before emitting. However, we need to modify a copy
of the dash array since the same array may be used by the meta-surface
when replaying to an image fallback.
By using top_srcdir if available. Make's include is relative to
current dir, not the Makefile being processed. That makes it hard
to include Makefile's relatively.
