extend-pad was not a clear demonstration of the EXTEND_PAD mode, so revamp
it to show the filter extending a 4 pixel surface to cover the entire
output. However, this hides a discrepancy with the vector surfaces that we
cannot prevent the external renders from applying an interpolation to the
border pixels, so we copy the original test to extend-pad-border to check
the desired behaviour on boundary pixels.
Use the surface user-data array allow to store an arbitrary set of
alternate image representations keyed by an interned string (which
ensures that it has a unique key in the user-visible namespace).
Update the API to mirror that of cairo_surface_set_user_data() [i.e.
return a status indicator] and switch internal users of the mime-data to
the public functions.
Include a COPYING inside perf/, test/, util/ to clarify the licensing
conditions beneath the respective directories. This is because cairo
itself (libcairo.so) is LGPL-2.1/MPL-1.1 but that only relates to src/.
The auxiliary source files are under a mix of free licenses and we wish to
be clear just what license applies to each file.
In particular, cairo-trace needs to include the GPL terms and conditions.
We frequently use '-' within the test name or format name and so we
encounter confusion as '-' is also used as the field separator. At times
this has caused a new test to break an old test because the new test would
match one of the old test's target specific reference images. So switch
everything over to use '.' between fields (test name, target, format,
subtest, etc.).
Avoid calling libtool to link every single test case, by building just one
binary from all the sources.
This binary is then given the task of choosing tests to run (based on user
selection and individual test requirement), forking each test into its own
process and accumulating the results.
If the filter mode is anything other than DEFAILT, FAST or NEAREST set the
Interpolate flag in the image dictionary so that a smoothing filter is
applied when rasterising the vector file.
As we have no control over the implementation of the Interpolate filter
(the PS/PDF specifications leave it undefined) we need to capture the
output of poppler/GS and update our reference images. (For a couple of
tests, the filtering is irrelevant so for those we set the filter to
NEAREST.)
Note that GhostScript's Interpolate filter does not work on rotated images
(and a variety of other transformations) so several of the PS reference
images have use nearest-neighbour sampling instead of a bilinear filter.
Behdad wants to include the feature with 1.10, so we enable it as early as
possible in 1.9 dev cycle to generate as much feedback as possible.
The first change is to use "<cairo>" as being a name unlikely to clash
with any real font names.
This reverts commits:
a824d284be,
2922336855,
e0046aaf41,
f534bd549e.
This test relied on the recently-removed ability to select
the internal twin-based font family with a name of "cairo".
Presumably, we'll want to bring this test case back when
some other means of requesting that font face is added.
This is just part of the make-distcheck routine for me. I know
Behdad added a test to check for missing images in the list, but
it doesn't seem to be getting run automatically as part of
'make test' nor 'make distcheck', (or if it it, then I'm not
noticing its output).
This test is expected to fail due to a couple of known bugs. Chris
has fixes for both bugs, but is holding off on them until after 1.8.2
to prevent introducing any possible new bugs with his fixes.
Otherwise the reference image (user-font-image-ref.png) gets
interpreted as an image-specific reference image for the
user-font test case resulting in a bogus failure.
PS (ghostscript) interprets the degenerate end-caps quite differently, and
perhaps slightly more rationally... Add this to XFAIL, until we have a
definitive specification on how we should behave.
Test the decomposition of 5 different types of spline curve. Useful test
for future experiments in improving the decomposition algorithm.
Note: the vector targets all need separate reference images due to their
lack of support for cairo_set_tolerance(). Also GS strokes the Bezier
curve differently using offset curves and opposed to transcribing the
outline of a pen.
Adrian Johnson proposed a hack that fixed the current test by simply
scaling the dashed stroke by device_transform.xx. Obviously this exposes a
deficiency in the test case. So add an outer loop to iterate over several
common ppi for both x and y and in doing so reveal more ugly artifacts in
the current fallback code.
As identified in bug 15479,
Unpredictable performance of cairo-xlib with non-integer translations of a
source surface pattern
(https://bugs.freedesktop.org/show_bug.cgi?id=15479),
source surfaces with a fractional translation hit slow paths for some
drivers, causing seemingly random performance variations. As a work-around
Owen Taylor proposed that cairo could convert non-integer translations on
NEAREST sources patterns to their integer equivalents.
The messy detail involved here is replicating the rounding mode used by
pixman for the sample offset, but otherwise the conversion is fairly
trivial.
As proof-of-principle, compute a scale factor to avoid overflow when
converting a linear pattern to pixman_fixed_t. Fixes test/huge-pattern,
but the principle should be extended to handle more cases of overflow.
Since CAN_TEST_PS_SURFACE does not currently require spectre, we were
attempting to compile in spectre support for any2ppm even on systems
without libspectre installed. Fix that by adding a separate flag for
CAIRO_HAS_SPECTRE.
Add a test case to capture the current behaviour when a segment ends on
an off/on dash transition.
Originally filed as bug:
Miter artifacts for dashed strokes
https://bugs.freedesktop.org/show_bug.cgi?id=17973
The use of fine-grained fallbacks requires the native support of the
SOURCE operator applied to an image on the target surface. SVG 1.2
introduces the "comp-op:src" mode fulfilling this criteria - so we can
enable fine-grained fallbacks for 1.2+.
Update test/fine-grained-fallbacks to exercise this pathway in SVG 1.2 -
as SVG natively supported all the current operations within that test.
This reveals yet another librsvg bug in handling SVG 1.2.
mitch reported on irc that expose events in the gimp were suffering from
artifacts which he tracked down to a bug with clipping and source
surfaces. This is the cairo test case for that regression.
There appears to be no simple solution here, as it seems to be a
fundamental flaw in the design of the meta-surface wrt to replaying into
a fallback image. (I may be wrong, but if Carl found no easy solution then
I feel no shame for my own failure ;-)
Moral of this story is bugs cluster. If we made a mistake, especially in a
complicated bit of code that is interfacing with another library, then we
are likely to make a similar mistake in future. Disabling this test hid a
regression between 1.4 and 1.6.
I swear that when I said that it was a rounding error, I was looking at an
image where the squares were overlapping the lines and had a listing of
all the coordinates used. However, the current output on all the machines
I have to hand is correct so I believe the underlying bug to be fixed.
Update the reference images for the external renderers because (a) GS
exhibits the same bug cairo had and (b) librvsg/PDF do not use NEAREST
when applying surface patterns, so the squares are blurred as a result.
With the reintroduction of Carl Worth's and Owen Taylor's work to expand
pattern extents as necessary to include extra samples due to the filter
radius, we expect filter-bilinear-extents to PASS. This patch series is
important as it factors out our assumptions about filter radius into a
single function and cleans up the code in its wake.
However, since the external PS/PDF renderers do not necessarily use the same
filter as cairo (and currently they only use NEAREST due to lack of
/Interpolate emission in those backends) we can expect differences in test
output. So add the respective reference images to capture current
expectations and to highlight future changes.
Fixes bugs:
Bug 15349 - bad clipping with EXTEND_NONE
[https://bugs.freedesktop.org/show_bug.cgi?id=15349],
Bug 15367 -Improve filtering handling in cairo-pattern.c
[https://bugs.freedesktop.org/show_bug.cgi?id=15367]
For this we extend the boilerplate get_image() routines to extract a
single page out of a paginated document and then proceed to manually
check each page of the fallback-resolution test.
(Well that's the theory, in practice SVG doesn't support multiple pages
and so we just generate a new surface for each resolution. But the
infrastructure is in place so that we can automate other tests,
e.g. test/multi-pages.)
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.
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.
