According to "man setjmp", one possible way to avoid variable clobbering
is to declare them as volatile. Thus, this commit turns the variables
that are changed between setjmp() and longjmp() and whose values are
still needed after setjmp() returned the second time into volatile
variables.
The warning in cairo-bentley-ottmann-rectangular.c is worked around by
not initializing the variable before setjmp(). To be honest, I don't
understand why the compiler warns here at all since the value of update
is clearly not used after setjmp()'s second return.
This commit re-fixes the warnings that were reintroduced in commit
82f40285 which reverted b092b63.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
The cairo_font_options_t struct may now contain allocated
memory, so call fini whenever we are about to let go of an
embedded cairo_font_options_t struct.
The variations member of cairo_font_options_t is allocated,
so we need to have a method to free it for cases where
the struct is embedded in larger structs, such as cairo_ft_options_t.
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.
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)
