Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
All the cases are the same, except len is different.
Use the already calculated len parameter to handle all
cases except RGB24 the same.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Suggested-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
The code that looked at CAIRO_TEST_NUM_THREADS was removed seven years
ago in commit 6ef9779a6f, because it was dead code. I have not
managed to figure out how long exactly this code was dead already.
This commit removes the last traces of NUM_THREADS.
Signed-off-by: Uli Schlachter <psychon@znc.in>
With VERBOSE=1, a lot more stuff is printed while make runs. Perhaps
most interestingly, this prints the output of a failed test after the
test failed. Thus, this gives us the output of the test suite.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Converting a series of glyphs to a path triggers an out of memory error
if there is a space glyph (bytesGlyph==0). The regression was
introduced by commit 19982393 in cairo-win32-font.c:107.
The behavior of malloc(0) is not well defined - it can return NULL on
some platforms, or an arbitrary (non-allocated) pointer on other
platforms. Commit 19982393 introduced sanity by enforcing that NULL is
always returned in this situation, which inappropriately triggers the
OOM check in _cairo_win32_scaled_font_init_glyph_path(). Instead,
special case the handling for bytesGlyph==0.
Patch authored by Uli Schlachter, based on fix proposed by lb90.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/339
Reference: https://gitlab.gnome.org/GNOME/pango/issues/323
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*gnome.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}gnome\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*freedesktop.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}freedesktop\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*cairographics.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}cairographics\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
From further testing and investigation it appears that many PDF viewers
already have a workaround to invert Adobe CMYK JPEGs, so our generated
PDFs display incorrectly with those viewers due to double-inversion.
Further investigation will be needed to find a better solution that
doesn't cause regression for some PDF viewers; perhaps PDF viewers that
lack this inversion workaround should be changed to include it. For now
we'll drop the patch to avoid shipping the regression in 1.16.0.
This reverts commit b207a932a2.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97612
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/156
Fix distcheck by dropping use of the now-obsolete gtkdoc-mktmpl.
In preparation for the upcoming 1.16 release, I've made a few changes to
get distcheck to pass. I also updated it to run on Ubuntu 18.04, but
found that on newer distros distcheck won't run due to missing
gtkdoc-mktmpl, which has been deprecated upstream for some time. The
patch below disables everything that references it, and enables
distcheck to finish successfully.
Unfortunately, this probably regresses portions of our document
generation, and thus will need some reimplementation work. Anyone got
time to investigate a better solution for this?
For me, with this fix, the base image test cases now pass 100%, when
running:
make test TARGETS=image FORMAT=rgba
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The discrepancies in these tests appear to all be font rendering /
antialiasing, probably due to algorithmic changes in Pixman.
Some of these reference images were updated in Federico's recent patch,
so the fact that they differ on my system may indicate there may be some
system dependencies beyond just pixman, that can cause test result
variation from person to person. Ideally, these would be isolated and
the tests modified to not have such dependencies.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
[In testing, I was able to reproduce Federico's results for most, but
not all, of the test images. There might be some additional
platform-specific discrepancies that need ironed out, but this is a
solid step forward in any case.
Results for a quick run against just the image backend on my system:
--bryce]
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
I don't see how the old reference file could have been generated.
Things I tried:
* Using an old pixman (but it seems that the relevant code for Adobe
extended blend modes has not changed?)
* Using the Cairo version where the test was first introduced.
* Changing the alpha value from .5 to something else.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Tested-by: Bryce Harrington <bryce@bryceharrington.org>
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
The comment said that using CAIRO_OPERATOR_SOURCE for the background
triggered a librsvg bug, but the relevant commit message does not even
include a link to a librsvg bug.
Also, changing it from OVER to SOURCE completely breaks these
tests (the reference images don't match at all), so this comment is
stale. Just remove it.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
num_glyphs and num_clusters are explicitly checked to be non-NULL at the
beginning of this routine, and by this point in the code both have been
deref'd multiple times, so checking them for NULL here again is
superfluous.
It looks like the intent here is to verify the glyphs and clusters
arrays are non-NULL unless their counts are zero, so change the tests
accordingly.
Coverity ID: #983386
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
There is no glesv3.pc provided by mesa, perhaps because
the glesv3 support is provided by the libGLESv2 library.
Don't bother testing for glesv3.pc, just check for glesv2.pc
and then search for the gl3.h header file.
This fixes an issue reported by Theo Veenker, where building
with glesv3 enabled would result in a cairo.pc file that depends
on the non-existant glesv3.pc.
The code is checking a variable is non-NULL after it's already been
dereferenced in an assert.
I'm not certain whether the assert should be conditionalized to only be
tested when right != NULL (which would allow edges_end() to still be
invoked), or if the function should assert right as non-NULL always.
Coverity ID: #1160730
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
subrs was already tested for NULL prior to this, and will never be NULL
at this point. Meanwhile, find_token()'s return is unchecked (it can
return NULL and is checked in all other calls). Quite clearly, this is
a copy-paste error from the prior find_token call, and the intent was to
check array_start not subrs.
Coverity ID: #1160662
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
Patch 37a22669 improved performance by using bounding box extents.
However, the code appears to be incorrect. If extents is non-NULL it
copies its contents to group->extents, otherwise it sets group->extents
to sensible defaults, but then goes ahead and tries to copy the
undefined contents. This second copy is unnecessary if extents is
non-NULL and will cause a crash if it is NULL.
Drop the extra copy, guessing it's just a typo.
Coverity ID: #1159559
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
