We currently (have to) apply font variations for every glyph.
Calling FT_Set_Var_Design_Coordinates has expensive side-effects,
like resetting the autohinter, so we should avoid doing it
fht he coordinates don't actually change.
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.
This test checks that passing font variation settings via
font options has the desired effect. It checks this by reading
the effective axis values out of the FT_Face after creating
a font with these options.
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
The PS output from this test is > 100MB due to the duplicated images.
Using CAIRO_MIME_TYPE_UNIQUE_ID reduces the PS output to 650k, runs
considerably faster, and now produces correct output.
