Issue #342

The old code did not work.

https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1790242

Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>

Patch proposed by Bofa.

Fixes: cairo/cairo#317


Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>

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:  cairo/cairo#339
Reference:  https://gitlab.gnome.org/GNOME/pango/issues/323


Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>

Commit 38806bc3 already disabled the backend from use, now drop the
code.

Paul Menzel authored Oct 16, 2018 and Bryce Harrington committed Oct 16, 2018

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>

Paul Menzel authored Oct 16, 2018 and Bryce Harrington committed Oct 16, 2018

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>

Paul Menzel authored Oct 16, 2018 and Bryce Harrington committed Oct 16, 2018

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 b207a932.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97612
Fixes: cairo/cairo#156

Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>

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>

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>

Signed-off-by: Bryce Harrington <b.harrington@samsung.com>

Pointed out by keith.briggs@bt.com

Fix distcheck, which was failing on the copyright symbols in these
files, because their encoding was not being detected as UTF-8.

Makes new COLR/CPAL implementation in FreeType work with cairo now.
Ie. Microsoft's Segoe UI Emoji Regular font renders (instead of
crashing cairo.)

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>

If the call to _cairo_malloc_ab_plus_c() fails, it returns an error
without first freeing event_y.

Coverity ID: #1160682
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>

Note this changes the semantics of the value of extra_out such that it
is set to NULL instead of left undefined in case an error is returned.

Coverity ID: 220086
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>

_cairo_malloc_ab() can return NULL under some circumstances, and all
other callers of this routine in the Cairo codebase check its return, so
do so here as well.

Coverity ID: #1159556
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Uli Schlachter <psychon@znc.in>

If the bitmap's min is non-zero, _bitmap_next_id() could break out of
its loop early, before initializing the prev variable.  prev would then
be dereferenced without a null ptr check.  This condition should never
occur in practice, so add an assert() to assure it doesn't.

Same issue is present in trace.c.

Coverity IDs: #1159557, #1159558
Reviewed-By: Uli Schlachter <psychon@znc.in>
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>