So far, we only call cairo_ft_apply_variations() in
cairo_ft_scaled_font_lock_face(), but this function is not
used internally. We need to apply it also when loading
glyphs.
This makes pango-view show font variations correctly.
Save the original face_index also for the from_face case,
so we can always rely on it when applying font variations.
This prevents us from running into the same trap we've seen
before where ft_face->face_index changes underneath us as
font variations are applied.
We must not look at the instance_id field of the cached ft_face,
since freetype changes it underneath us (if we set the axis values
to match a named instance, the instance_id gets changed to reflect
that). Thankfully, we have the original instance_id stashed away
in the cairo_unscaled_font, so we can just use that to decide if
we are dealing with a named instance or not.
This makes the font variations tests pass.
Using strtod_l and newlocale is a nicer way to have provide
a C-locale-only strtod. Since these APIs are not available
everywhere, keep the old code as a fallback.
The loop was unnecessarily written in a way that fails
to terminate if len is 0 (ie for the empty string).
Avoid that by checking for len > 0 explicitly.
When a color glyph is completely clipped away, we
get the non-zero status 'nothing to do'. In that case,
we must not exit early, since there might still be work
to do for the other color glyphs.
This bug was showing up as color glyphs stopping to render
in GTK+ entries that are scrolled to the right, and also
as color glyphs not rendering inside the selection sometimes.
See https://bugzilla.gnome.org/show_bug.cgi?id=790255 and
https://bugzilla.gnome.org/show_bug.cgi?id=788071.
Commit 38fbe621 added use of the ptrdiff_t type in a header file,
however `make distcheck` complains:
In file included from headers-standalone-tmp.c:1:0:
../../../src/cairo-image-surface-private.h:74:5: error: unknown type name ‘ptrdiff_t’
ptrdiff_t stride;
^
Add a cairo_svg_surface_set_document_unit() function to allow users to
set a unit for the width and height values of the root <svg> element.
In particular this allows to draw in pixels and still have the expected
result when generating SVG output.
Add also the correspondent getter function.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90166
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Until now fopen was used on Windows to open files for reading and
writing. This assumed however that the filename would be encoded in the
current codepage, which is a major inconvenience and makes it even
impossible to use filenames that use characters from more than one
codepage. This patch enforces the use of UTF-8 filenames on all
platforms.
Based on the work of Owen Taylor (https://lists.cairographics.org/archives/cairo/2007-February/009591.html)
- each annotation was emitted on every page instead of just the page
that contains the annotation
- the document structure did not correctly link to annotation objects
- fix some annotation related memory leaks
When image data is emitted as strings (required when an image is used
in a PaintProc), the base85 encoded data was emitted inside PS strings
(...) and the image filters included an ASCI85Decode filter.
This has been changed to emit the strings as ASCII85 strings <~...~>
and remove the ASCII85Decode filter since the base85 is decoded when
the string is parsed.
Also factor out the string data source procedure into the prolog.
- Restructure the emit_surface code so that mime types are checked first.
- Add a test parameter to emit_surface to test if the surface will be emitted
as an image or recording instead checking the surface type as the attached
mime may override this.
- Mark surface as not clear when mime is attached to avoid optimizing away
"clear" surfaces that have mime attached.
- Include entire surface in analysis if mime attached (also fixes bug with
calculating the extents CONTENT_COLOR surfaces)
PDF XObjects need to specify the bounding box. Emit unbounded surfaces
when finishing as at this point the extents of all uses of the
unbounded surface are known.
Image data is often accessed using:
image->data + y * image->stride
On 64-bit achitectures if the image data is > 4GB, this computation
will overflow since both y and stride are 32-bit types.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98165
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
The cairo_set_opacity() routine has been disabled since 2010. There
appears to be support for it internally in the backend, so it is unclear
why it is not enabled or what might break if it were re-enabled. Given
the lack of bug reports about its omission, it may be vestigal. For
now, just hide the doxygen for it to suppress warnings. It may be worth
deeper review to either re-enable it or remove it entirely.
Reported-by: Rafał Mużyło (See fdo bugzilla #82741)
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
