Declares _cairo_quartz_scaled_font_backend ahead of time and makes it static.
Also, removes the 'static' from the _cairo_quartz_font_backend definition.
If a matrix was something like [0 .000001 0, .000001 0 0] the old code would
assume that xx and yy were greater than 0 and turn the nearly degenerate matrix
into an actual degenerate one. This caused things to blow up later on. Now we
check that our nearly rectangular matrices are not nearly degenerate, and let
the nearly degenerate ones fall through to the non-rectangular path.
Note: I'm not sure why NEARLY_ZERO(d) is fabs(d) < 1/65536 instead of some
other value. Hopefully, it's a useful definition.
This problem was found by a test case attached to:
https://bugzilla.mozilla.org/show_bug.cgi?id=467423
Based on feedback from Jeff Muizelaar, there is a case for a very quick
and dirty extents approximation based solely on the curve control points
(for example when computing the clip intersect rectangle of a path) and
by moving the stroke extension into a core function we can clean up the
interface for all users, and centralise the logic of approximating the
stroke extents.
When analysing the stroke extents, we need the original fixed-point
extents so that we do not incur an OBO when we round-to-integer a second
time. We also need a more accurate estimate than simply using the control
points of the curve, so pass in tolerance and decompose until someone
discovers a cheaper algorithm to determine the precise aligned bounding
box of a bezier curve.
If we are dithering on the Xlib backend we can not simply repaint the
surface used for a solid pattern and must recreate it from scratch.
However, for ordinary XRender usage we do not want to have to pay that
price - so query the backend to see if we can reuse the surface.
When coercing from one image format to another we performed a paint
operation using a temporary context - this is overkill as we can just call
_cairo_surface_paint() directly.
This commit moves the toy-to-real mapping from the scaled font creation
time to font face creation. A toy font face will keep an internal ref
to an implementation face. Then cairo_scaled_font_create() will simply
substitute the implementation face before creating anything.
This also modifies the cairo-ft toy creation in that we now create a
non-resolved pattern and store it in a cairo-ft font-face. We then
do the resolving and unscaled font creation at scaled-font creation
time. This also means that cairo_ft_font_face_create_for_pattern()
now accepts non-resolved patterns too, and does the right thing about
them. As much as that can be called right.
Some testing of toy font creation performance is in order, as is testing
win32 and quartz font backends.
Otherwise this may leads to an invalid memory access to r.
Fixes: Bug 18588 - XCB backend fails with missing render.
https://bugs.freedesktop.org/show_bug.cgi?id=18588
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 834f1d7b70)
Sascha Steinbiss reported a bug where the PDF backend was reading beyond
the end of the glyph array:
http://lists.cairographics.org/archives/cairo/2008-December/015976.html.
It transpires that in the early glyph culling in the gstate we were
not updating the clusters to skip culled glyphs.
