When emitting combined stroke and fill, cairo SVG backend was using the opacity
two times, instead of using fill-opacity and stroke-opacity, leading to
incorrect output.
I've updated the mask test reference images for the SVG output, since it seems
there's a bug in librsvg when fill-opacity is used in the mask image.
I've checked the SVG output with batik, and it looks fine.
https://bugs.freedesktop.org/show_bug.cgi?id=13084 demonstrates a
regression where the clip is ignored by the xlib backend whilst
rendering text. Therefore we extend the current test cases to combine
a clip that represents everything clipped out with the rendering of
text. For completeness, we add a new test case that exactly mimics the
sequence of cairo operations that lead to the discovery of this bug -
namely the rendering of text with an empty clip path.
The height is currently mapped to the atsui metrics property capHeight, which
is documented as "The height of a capital letter in the font from the baseline
to the top of the letter".
That doesn't match what height is in cairo, it should be the disctance between
baselines. This patch that fixes that (and makes webkit on GTK+ OS X
layout nicely).
Whilst NEED_MEMORY_BARRIER should be a subset of ! HAS_ATOMIC_OPS,
until we have accurate configure tests NEED_MEMORY_BARRIER may be
invoked independently.
Allocate subsequent path bufs twice as large as the previous buf,
whilst still embedding a small initial buf into cairo_path_fixed_t
that handles the most frequent usage.
_cairo_surface_fill_region(): avoid allocating the array of boxes if we
know that the region only contains one box and is therefore defined by its
extents.
Add a configure check to determine whether the host cpu can read/write
cairo_atomic_t without an explicit memory barrier, and update the macros
within cairo-atomic-private.h to reflect this knowledge.
Inline and unroll PointDistanceSquaredToSegment() and eliminate the
multiple conversions between fixed point and doubles. This simple
transformation both shrinks the code and wins a few percent in path
intensive benchmarks such as fuckhergently.swf
By splitting out the knot vectors into a smaller, separate structure, we
can dramatically reduce the stack allocation for each level of recursion.
Secondly we can have the storage requirements by modifying the first set
of knots in-place, thus we need only allocate stack space for the knots
covering the deferred half of the spline.
Ensure that the output extents of cairo_scaled_font_glyph_extents(),
are zeroed if we return early due to being passed by the user a
cairo_scaled_font_t with an error set.
If libpng has not been compiled with jmpbuf support, then we cannot
atempt to use it - in which case we fall back to png's default error
handler and abort.
The previous commit increased the precision of floats from 6 digits
after the decimal point to 18 digits to correct rounding errors with
very small numbers. However most of the time this extra precision is
not required and results in increased PS/PDF output.
This commit makes the precision after the decimal point 6 significant
digits. For example:
1.234567
0.123456
0.00123456
0.00000000123456
We write floats using %f as the scientific format used by smarter %g is
invalid in PS/PDF. %f however by default rounds to five digits after
decimal point. This was causing precision loss and making the newly
added degenerate-pen test fail for PDF. We now print up to 18 digits
which is as many bits doubles can accomodate. We can be smarter, but
that's for another commit.
Otherwise, these don't get included in the generated tar file
and the test suite doesn't pass when run from that tar file,
(like 'make distcheck' tests).
When the current font size matches one of the available fixed sizes, and
the overall transform has only scaling components, FreeType will use the
fixed size bitmaps by default. For glyphs which do not have bitmaps,
force them to be rendered in monochrome instead of anti-aliased so
that they all match nicely.
Instead we choose either the first or last pen vertex as
appropriate.
This makes the degenerate-pen pass stop failing on an
assertion, and passes for most backends. It's still failing
for the PDF backend, but that looks like a new, PDF-specific
bug.
The previous commit failed to fix up two callers to the
_cairo_path_fixed_get_current_point function, (and since
C doesn't distinguish between an enum and our integer-as-
Boolean, the compiler didn't complain).
Fortunately, though, the test suite did complain, as the
bug introduced a new failure into the get-path-extents
test, and git-bisect helpfully pointed to the previous
commit.
With this fix, the new failure of get-path-extents is
eliminated, (though, in this branch the arc-based failure
of that test still exists).
This fixes the current failure get-path-extents, which is a
demonstration of the following bug:
cairo_stroke_extents() gives wrong result for arcs in some cases
https://bugs.freedesktop.org/show_bug.cgi?id=7245
Many thanks to Michael Urman whose review of early versions of
this work found a fatal mistake in my algebra.
If we have already returned the error status, then it is cleaner (and
the common idiom) to use 'return CAIRO_STATUS_SUCCESS' rather than
'return status'.
The only caller of cairo_path_fixed_get_current_point(), used the status
return to determine whether or not the path had a current point (and did
not propagate the error) - for which we had already removed the
_cairo_error() markup. Now we reduce the boolean status return to a
cairo_bool_t, with a net reduction in code.
Adrian Johnson hit a SEGV after
_cairo_paginaged_surface_create_image_surface() tried to set the font
options on an error surface after running out of memory. So add the
usual checks that the surface is not a snapshot, or in an error state or
finished before modifying its font options.
