Comment out the skia backend in configure.ac to avoid presenting it as
an option to users.
Skia is not API stable and is not available in a packaged/versioned
form. This results in Cairo's skia backend constantly being out of date
and broken, since it will only work with a specific Skia snapshot. The
last time the cairo skia backend was updated was 2014, and it hadn't
been updated very regularly prior to that. For these reasons, unless
someone raises an interest in using and/or maintaining the backend,
we'll consider dropping it entirely.
This reverts commit b092b63119 which
introduced a wrapper function around setjmp(). To quote from man setjmp:
If the function which called setjmp() returns before longjmp() is
called, the behavior is undefined. Some kind of subtle or unsubtle
chaos is sure to result.
Since after the above commit setjmp() is called from the wrapper
function, the result might or might not work, depending on compiler
settings. If the setjmp() wrapper is not inlined, then the state of the
stack after longjmp() will likely be garbage.
[Cherry-Pick:]
This is a cherry-pick from a master branch to the 1.14 branch. The
reverted commit was cherry-picked to this branch in commit
d53db01d01, so this is what this commit
actually reverts.
As reported to me:
"A calculation on signed integers has undefined behaviour if the result is not
representable in the type. In this case, it's trying to negate int_min, aka
-2^31 but the range of an int is [-2^31, 2^31-1] so it doesn't fit. Instead,
cast to unsigned which has 2's complement wrap-around arithmetic which is what
this particular function expects."
Subset array sizes are allocated based on the number of glyphs in the
font. In this bug the fonts did not contain the mandatory .notdef
glyph, hence the subset arrays were not large enough.
https://bugs.freedesktop.org/show_bug.cgi?id=102922
This happens when _cairo_ft_scaled_glyph_init() returns
CAIRO_INT_STATUS_UNSUPPORTED when called from
_cairo_scaled_glyph_lookup(). In those cases
_cairo_scaled_font_free_last_glyph() is called to release the glyph that
has just been allocated. If there aren't more glyphs,
_cairo_scaled_glyph_page_destroy() is called. The problem is that
_cairo_scaled_glyph_lookup() should always be called with the cache
frozen, and _cairo_scaled_glyph_page_destroy() without the cache
frozen. We can simply thaw/freeze the font before calling
_cairo_scaled_glyph_page_destroy().
https://bugs.freedesktop.org/show_bug.cgi?id=103335
If the image operator does not read all the ASCII85 data, the PS
interpreter will try to execute the next byte of unread data.
Define our own image operator that calls flushfile (reads until end of
file) on the filter after drawing the image.
https://bugs.freedesktop.org/show_bug.cgi?id=84811
Some broken pdfs use glyph 0 in embedded fonts for rendering instead of .notdef.
The cmap we use for embedding latin fonts does not allow rendering glyph 0. Ensure
if glyph 0 is used, it is mapped to a non 0 glyph in the subset.
Bug 89082
The code here wants to ignore errors for a specific request. To do so,
it sets a no-op error handler. However, it could happen that some
previous request caused an error and this error will also be ignored by
the no-op error handler.
To avoid this, call XSync() before setting the error handler. This makes
sure that all pending errors are handled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
In short, cairo_surface_create_similar inherits it, while
cairo_surface_create_similar_image doesn't. It wasn't obvious without
reading the code or explicitly checking the device scale of the new
surface.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99094
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
If we cannot let the X11 server do some operation (for example: the
RENDER extension is not available), then we fall back to an image
surface and do the operation locally instead. This fallback requires the
current content of the surface to be downloaded from the X11 server.
This fallback logic had an error.
The fallback is implemented with _get_image() in the function
_cairo_xcb_surface_fallback(). _get_image() is only called if we do not
yet have a fallback available, so when we call _get_image we have
surface->fallback == NULL. Then, if _get_image() fails, it returns a
surface in an error state.
Before this patch, the code would then just ignore this error surface
and return &surface->fallback->base, a NULL pointer. This would then
quickly cause a crash when e.g. the surface's ->status member is
accessed.
Fix this by returning the error surface instead as the fallback.
The end result of this patch will be that the XCB surface that is
currently drawn to ends up in an error state which is a lot better than
a NULL pointer dereference and actually correct in this case. The error
state is reached because the current drawing operation will fail and
this error is reported up the call stack and eventually "taints" the
surface.
(However, the error code could be better: _get_image() too often fails
with a generic CAIRO_STATUS_NO_MEMORY error, but that's left as future
work)
Signed-off-by: Uli Schlachter <psychon@znc.in>
On systems using GNU's strings implementation, 'strings -' causes a scan
of the whole file, which is equivalent to 'strings -a'. However, in
POSIX passing '-' as the first argument to 'strings' is declared
unspecified, and thus may break the build on systems that use a
different POSIX strings implementation.
Patch from Jung-uk Kim
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88639
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Some debugging functions wrote to stdout, which is inconsistent with
the other debugging functions of the same groups.
Instead they should write to the debugging file that they are given as
input.
Reviewed-by: Andrea Canciani <ranma42@gmail.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=95227
Invoking cairo_surface_mark_dirty () on an observer surface would
cause it to print debugging output to stdout.
Reviewed-by: Andrea Canciani <ranma42@gmail.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=95227
The destruction of a scaled font could indirectly trigger the destruction
of a second scaled font, causing the global cache to be locked twice in
the same thread.
This is solved by unlinking the font's glyph pages while holding the global
lock, then releasing the lock before destruction takes place.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93891
According to the Opentype spec, num_contours in a glyf table entry can
be > 0 (single glyph) or < 0 (composite glyph). num_contours == 0 is
undefined.
The embedded font in the test case for this bug contained a space
glyph with num_contours == 0. This was failing on some printers.
According to the spec, glyphs with no outlines such as space are
required to have a 0 size entry in the loca table.
https://bugs.freedesktop.org/show_bug.cgi?id=79897
If XShmGetImage() fails, the code tries to continue with its normal,
non-shared-memory path. However, the image variable, which was previously set to
NULL, now points to an already-destroyed surface, causing a double-free when the
function cleans up after itself (actually, its an assertion failure because the
reference count of the surface is zero, but technically this is still a double
free).
Fix this by setting image=NULL after destroying the surface that this refers to,
to make sure this surface will not be destroyed again.
While we are here (multiple changes in a single commit are bad...), also fix the
cleanup done in bail. In practice, &image->base should be safe when image==NULL,
because this just adds some offset to the pointer (the offset here is actually
zero, so this doesn't do anything at all). However, the C standard does not
require this to be safe, so let's handle this case specially.
Note that anything that is fixed by this change is still buggy, because the only
reason why XShmGetImage() could fail would be BadDrawable, meaning that the
target we draw to does not exist or was already destroyed. This patch will
likely just cause X11 errors elsewhere and drawing to (possible) invalid
drawables is not supported by cairo anyway. This means that if SHM fails, the
following fallback code has a high chance of failing, too.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91967
Signed-off-by: Uli Schlachter <psychon@znc.in>
When doing a "complicated" mask operation, we draw the clip to a surface and use
this as a mask in later operations. The code assumes that this operation draws
to the whole target surface and thus a deferred clear may be skipped.
However, this requires that the extents of the trapezoids that will be drawn and
the extents of the surface are the same. This assumption is wrong, as can be
seen e.g. by the bug report that this commit fixes.
The fix is just not to skip the deferred clear.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=84330
Signed-off-by: Uli Schlachter <psychon@znc.in>
NextRequest is a macro that doesn't mix well with xcb, since
dpy->request is not updated. Instead use XNextRequest() that was fixed
to do the right thing with xcb in libX11 commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=7f8f9a36ef901f31279c385caf960a22daeb33fe
This may solve application X errors when a shmdt() is called by cairo
before the Attach request is processed.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function tries to use _cairo_xcb_connection_put_image() to do the actual
work. However, that function can only be used for images with "native" stride.
If we only want to upload a rectangle from within an image, the function
_cairo_xcb_connection_put_subimage() has to be used. This function makes sure
that the correct information is sent to the X11 server.
No unit test for this, because we currently do not test the !SHM case
automatically. Perhaps we should?
Signed-off-by: Uli Schlachter <psychon@znc.in>
