In particular, with bitmap fonts, a floating-point error was affecting
y_bearing, yielding a value close to an integer instead of the integer
exactly. The change consists in replacing some operations of the form
A * (1/B) by A/B. Details of the issue in #503.
This new code will not always avoid rounding errors in final values
when these values could be exact, but it makes some of these errors
disappear.
The changes in the src/cairo-ft-font.c code consists of:
* Define the SCALE() macro (with some explanations in a comment).
* Remove the declarations and definitions of x_factor and y_factor.
* Update the code to use SCALE() instead of x_factor and y_factor.
perl -pi -e 's{(DOUBLE_\w+) ?(\(.*\)) \* ([xy])_factor}
{SCALE (\1 \2, unscaled->\3_scale)}' \
src/cairo-ft-font.c
* Replace the remaining 0 * x_factor and 0 * y_factor by 0.
Commit cf351a8a attempted to convert the font generation in
'_cairo_quartz_font_create_for_toy' to use CTFontCreateWithName and that uses
only Postscript Names, meaning with the hyphens.
Commit c6dc5df6 converted back to CGFont. CGFontCreateWithFontName is supposed
to work with Postscript Names, but it seems sometimes it does not.
In case a CGFont cannot be created using Postscript Names, attempt unhyphenated
version of font family name.
Specially important for font variations, which before did not
work in PDF, etc, output.
Script surface is not updated. It seems out of date with all
recent additions to cairo_font_options_t, so it loses the
variations :(.
Fixes https://gitlab.freedesktop.org/cairo/cairo/-/issues/819
Since a user-font might be calling stroke, and PDF has separate
stroke and fill colors.
Note that this bug was not exposed in Poppler. It's probably a
bug there. But multiple other viewers expoed this bug.
Fixes https://gitlab.freedesktop.org/cairo/cairo/-/issues/813
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
src/cairo-ps-surface.c:3524:18: warning: allocation of insufficient size ‘1’ for type ‘cairo_ps_form_t’ {aka ‘struct _cairo_ps_form’} with size ‘88’ [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(cairo_ps_form_t)`. GCC then sees we're not
doing anything wrong.
Signed-off-by: Sam James <sam@gentoo.org>
kCTFontColorGlyphsTrait is available in Mac OS X 10.7 and later.
kCTFontTraitColorGlyphs is available in OS X 10.8 and later.
Fixes build failure on Mac OS X 10.7.
Closes#810
Something changed in the docbook XSL, and we cannot use the `index`
element for the versioned indices any more. Using `chapter` brings the
indices back.
I hit the problem with _cairo_arc_in_direction() failing the
angle_max >= angle_min assertion earlier this year when using
Thunderbird on openSUSE Tumbleweed. Thunderbird would crash
when rendering some (but not all) HTML email due to this
assert. For some reason, one of the angles passed in was
NaN. Making _cairo_arc_in_direction() return immediately if
either angle is not finite fixed the problem for me, but I
don't know enough about the internals of Cairo to know if
this is, strictly speaking, the "right" fix. Also, having
tested again today _without_ this change applied, I am now
no longer able to reproduce the problem :-/ I still have the
same version of Cairo installed (1.17.8), but various other
packages on that system have been updated in the meantime,
so maybe that's a factor. Or maybe I'm just lucky and
haven't hit a "bad" HTML email this time...?
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/352
Signed-off-by: Tim Serong <tserong@suse.com>
Font options are allocated in _cairo_gstate_ensure_scaled_font() for local
processing, but never freed. Run _cairo_font_options_fini() on these and
fix the leak.
Signed-off-by: Christian Hesse <mail@eworm.de>
