Chris rightfully complained that having a boolean function argument is
new in cairo_show_text_glyphs, and indeed avoiding them has been one
of the API design criteria for cairo. Trying to come up with alternatives,
Owen suggested using a flag type which nicely solves the problem AND
future-proofs such a complex API.
Please welcome _flags_t APIs to cairo.h
We added cairo_has_show_text_glyphs() before. Since this is really a
surface property, should have the surface method too. Like we added
cairo_surface_show_page()...
And update user-font text_to_glyphs() method to match.
Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement ucs4_to_index().
It's the toy font API afterall.
When popping a group, transform it by the ctm centered at the origin
specified by the device_transform so that it ends up in the right place
when we try to paint. This fixes the regressions caused by
1a9809baab as shown by the pdf backend.
New public API:
cairo_text_cluster_t
cairo_has_show_text_glyphs()
cairo_show_text_glyphs()
Add accompanying gstate and surface functions, and surface backend methods.
No backends implement them just yet.
Instead of allocating the union of all possible pattern types, just
allocate the specific pattern as used by the function in order to trim
the stack space consumption and flag potential misuse.
Which generates the path for each cairo operation. If there's any paint,
mask, or intersect-clip-path operations in the meta-surface, UNSUPPORTED
is returned.
Strokes are currently tesselated to traps, then traps converted to path.
Should be made to use stroke_to_path() when we implement that.
Return the default values instead of zero for an error context. This
helps to prevent application logic faults when using the values from
the error context (for an example, see _cairo_arc_in_direction()).
The cairo_path_extents function can perform better than either
cairo_stroke_extents or cairo_fill_extents, so provide that
pointer from the documentation of the other two functions.
I was wrong in my assertion that the call to
_cairo_path_fixed_interpret_flat() could not possibly fail with the
given _cairo_path_bounder_* callbacks - as I had missed the implicit
spline decomposition. (An interesting exercise would be to avoid the
spline allocation...) As a result we do have to check and propagate the
status return through the call stack.
In order to correctly report the error back to the user during the
creation of a scaled font, we need to support a nil object per error.
Instead of statically allocating all possible errors, lazily allocate
the nil object the first time we need to report a particular error.
This fixes the misreporting of an INVALID_MATRIX or NULL_POINTER that
are common user errors during the construction of a scaled font.
Partial revert of commit 0086db893c.
This is a follow to the earlier commit that allowed creation of scaled
fonts using a NULL font options (by interpreting the NULL as meaning
use the default options) to reflect the comments made by Behdad
(http://lists.cairographics.org/archives/cairo/2008-January/012714.html).
The intent is that the public font options getter/setter API has similar
defensive behaviour to that of the core objects - i.e. do not overwrite
the nil object and if the object is in error then return the default
value. For the indirect use of a NULL/nil font options (e.g. creation of
scaled fonts), then an error should be returned rather than crashing.
cairo_has_current_point() can be used to determine whether a current
point is defined. We introduce this new symbol with a boolean return
value to avoid the versioning ambiguity of modifying
cairo_get_current_point(). This way we also don't have to map what
should be a routine operation to an error condition as was previously
proposed.
Previously we left the return values alone, which set the
user up for a nasty trap, (using potentially uninitialized
values with no indication that there was an error). So now
we initialize these values to 0.0 if the cairo_t is in error.
The fixed functions include:
cairo_path_extents
cairo_stroke_extents
cairo_fill_extents
cairo_clip_extents
cairo_font_extents
Document this function as a required call to get the correct
stride value before calling cairo_image_surface_create_for_data.
This means that previously-failing calls with non-multiple-of-4
stride values are now documented as errors. Also, we now have
the possibility of moving to more stringent alignment constraints,
(one can imagine doing 64-bit or 128-bit boundaries for example).
It's a common idiom to stroke degenerate sub-paths made with
cairo_move_to(x,y);cairo_rel_line_to(0,0) to draw dots. Test
that we get the desired extents from cairo_fill_extents,
cairo_stroke_extents, and cairo_path_extents for these cases.
Also document that the cairo_path_extents result is equivalent
to the limit of stroking with CAIRO_LINE_CAP_ROUND, (so that
these "dot" points are included), as the line width
approaches 0.0 .
This new function gets the extents of the current path, whether
or not they would be inked by a 'fill'. It differs from
cairo_fill_extents() when the area enclosed by the path is 0.
Includes documentation and updated test.
