This is the first part of updates to match the backwards-incompatible
changes that have been made in the cogl-experimental public API
since this backend last worked.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
- vsnprintf and snprintf are available since vs2015
- define ISREG if not provided
- guard unistd.h include with HAVE_UNISTD_H
- isnan() is available after vs2010
This function is reachable via cairo_ft_font_face_create_for_ft_face()
-> _cairo_ft_unscaled_font_create_from_face() ->
_cairo_ft_unscaled_font_create_internal() ->
_cairo_ft_unscaled_font_map_lock(). Thus, it could happen that nothing
initialized mutexes before this code runs.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We can't just move around the contents of the
passed-in string, we need to make a copy. This
was showing up as memory corruption in pango.
See https://gitlab.gnome.org/GNOME/pango/issues/346
Support subpixel positioning with a 4x4 subpixel grid.
When compositing glyphs in the image compositor,
we store the subpixel phases in the high bits of the
glyph index. The _cairo_scaled_glyph_index() macro
has been updated to discard these bits. By storing
the phases in the glyph index, the glyph cache just
keeps working. When loading a glyph, the Freetype
font backend shifts the outline according to the
phases.
FT_PIXEL_MODE_BGRA is an enum member, not a define, so it always appears
as 0 in the preprocessor conditions added in commit c0ed8ce1a1.
There is an existing define for color font support, use that instead.
Commits cb871c6c made the function _cairo_clip_reduce_to_boxes()
actually do something instead of being a no-op. This exposed a latent
bug in cairo that was so far just not hit due to luck.
The function _cairo_clip_steal_boxes() removes the boxes from a clip and
gives them to a cairo_boxes_t. _cairo_clip_unsteal_boxes() undoes this
operation. For efficiency reasons, cairo_clip_t contains an embedded
cairo_box_t that is used when the clip has only one box to avoid a
memory allocation. Thus, _cairo_clip_unsteal_boxes() must be called on
the same clip that was given to _cairo_clip_steal_boxes(), or otherwise
a clip could end up to the embedded box of another instance of
cairo_clip_t. This is exactly what was happening here.
For example, cairo-xcb can replace extents->clip with another clip via
the call chain _cairo_xcb_render_compositor_paint() (which is where
boxes are stolen) -> _clip_and_composite_boxes() ->
trim_extents_to_traps() ->
_cairo_composite_rectangles_intersect_mask_extents(). This function
replaced the clip with the result of _cairo_clip_reduce_for_composite()
and frees the old clip. At this point, the boxes that were stolen
previously become invalid / become a dangling pointer. The crash later
on is just one of the side effects of this.
This commit fixes this problem by treating embedded boxes specially in
_cairo_clip_steal_boxes() and _cairo_clip_unsteal_boxes(): The
cairo_boxes_t instance also has embedded boxes. An embedded box on the
clip is copied to these other embedded boxes. When unstealing, the
embedded box of the clip is used again. Thus, it does not matter anymore
that another instance of _cairo_clip_t is used for unstealing.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/358
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
The indentation of this line suggests it is a typo. In any case it
causes the function to unconditionally return immediately, thereby
shortcircuiting it entirely, which does not appear to be the intended
behavior.
Fixes: https://gitlab.com/cairo/cairo/issues/2
Similar to writing png, don't squash 16 bpc to 8 bpc and create
a float surface to contain the image.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
_cairo_image_surface_coerce will round down the image to a lower
bpp when using one of the floating point formats, so don't coerce those.
This makes the code actually work for those formats.
Because a float takes more storage than u16, we have to convert float
to u16 before calling png_write_image, because png_write
doesn't give us back the original row data, but an in-place copy.
With these changes we can dump floating point files with the highest
possible accuracy, with floats clamped between 0 and 1.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
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: 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
