This way the same callback code can be used to render multiple different
glyph arrays. Change done for education purposes, otherwise doesn't
make any difference in the test.
10000 that is. xlib fails now again. Not because of glyph size issues.
Because we skip rendering any glyphs with positions not in range -1024..15359.
Working on a fix.
test/invalid-matrix purposely feeds invalid numbers into cairo, in
order to check its detection of garbage values. In doing so, cairo
raises an Invalid exception, but as this is a direct result of an abuse
of the API we can treat it as expected behaviour and ignore the
exception.
Some platforms and applications enable floating point exceptions, so it
seems sensible to run the test-suite with the most serious exceptions
enabled - divide by zero, invalid result and overflow.
Franz Schmid reported on the mailing list,
http://lists.cairographics.org/archives/cairo/2008-April/013912.html,
an issue with drawing a dashed rubber band in Scribus. The problem
appears when segments of the dashed rectangle are outside the image,
with the errant dash connecting the ends of the visible segments.
The font_face created from cairo_ft_font_face_create_for_ft_face()
was being kept alive by a reference from the context beyond the
lifetime of the parent cairo_scaled_font_t (which owned the FT_Face).
Correct the example in the test code to remove this errant reference
before cleaning up the fonts. (To be fair, to actually trigger a bug
one has to evict the FT_Face from the cache before using the font_face
- merely creating a cairo_scaled_font_t for every font on the system is
enough.)
Check that when loading from index/gray/rgb PNGs, with and without
alpha/transparency, that the correct surface is generated by read_png(),
i.e. if the PNG contains an alpha channel then the image must be an
ARGB32 surface.
This bug first was fixed in 40558cb15e,
but then reintroduced in 9cfd82e87b, which
became part of the 1.6.2 quick release.
As penance to make sure I never repeat this same bug again, I offer this
test case which exercises the XSetClipMask(NULL) path and hopefully
simulates some 'typical' usage of cairo by GUI toolkits.
Convert the boilerplate specific flattened content value to the ordinary
CAIRO_CONTENT_COLOR_ALPHA for use with cairo_push_group_with_content() -
otherwise cairo rightfully flags an error and the test harness decides
that the similar surface is not available.
The experience of running the entire test suite under cairo_push_group()
did at least reveal that there was a potential bug in the pdf backend.
This test is just the simplest of drawing operations - simply filling
the similar surface with solid blue, and then blitting that surface to
the destination.
This reverts commit 07122e64fa.
The extra testing did find a pdf bug, and that should be fixed,
but the extra maintenance burden of running another iteration
of all tests does not seem justfied at all---particularly since
it looks like dozens of new reference images would be needed
for the svg backend.
Also, the new "failures" of the image backend with this new
testing look like a misunderstanding of exactly what the new
testing is actually drawing.
Test surfaces using similar surfaces with both CONTENT_COLOR and
CONTENT_COLOR_ALPHA, if applicable. This seems justified by the apparent
bugs in the pdf backend when going from an ARGB32 similar surface to
a destination RGB24 surface as well as isolated bugs in the image
backend.
The original goal was to try and trick the test suite into producing
a xlib surface with mismatching Visual/XRenderPictFormat. This succeeds,
although with a little bit of brute force in the xlib backend, but the
search to reproduce a BadMatch error fruitless.
I don't know if we made minor changes to the pdf backend, or
if this was due to a poppler change, (we recently bumped the
poppler required for testing up to 0.8.0), but any way around
it these test results look just as good as the reference images
they are replacing.
This test case does show a bug, and we have lots of ideas on how
to fix the bug, but we want to wait until after the 1.6 release
before we fix it. See:
http://bugs.freedesktop.org/show_bug.cgi?id=15349
It appears the reference image wasn't generated on a gold-standard
machine, (and yes, the gold standard is, *ahem* whatever happens
to match what Carl's machine does---eventually we'll make the test-
based tests less picky about system configuration like this).
make -j check has the unfortunate side-effect of performing the summary
before the TESTS have completed, both hiding in the stream of test
output and making it useless. Forcibly disable the jobserver so that the
summary is always last at the expense of not compiling the tests in parallel.
This test exercises code that computes the extents of a surface
pattern with CAIRO_FILTER_BILINEAR, (where the filtering
effectively increases the extents of the pattern).
The original bug was reported by Owen Taylor here:
bad clipping with EXTEND_NONE
http://bugs.freedesktop.org/show_bug.cgi?id=15349
PDF has a concept of "soft" masks, for which it is able to construct a
mask out of PDF drawing operations. These tests exercise constructing
various masks using the high level drawing operations.
