Mirrors cairo_xlib_surface_set_drawable, allowing the drawable
targeted by a surface to be changed on the fly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is consistent with the naming of most cairo types/functions
(example: cairo_foo_surface_*).
The substitution in the code has been performed using:
sed -i 's/cairo_pattern_mesh_/cairo_mesh_pattern_/' <files>
I did this manually so I could review the docs at the same time.
If anyone finds typos or other mistakes I did, please complain to me (or
better: fix them).
The rationale behind this change is that when someone is trying to
draw on a SVG surface using image surface patterns, the resulting SVG
file can take up to ridiculous 20 megabytes for 3-4 typical
photographic images in a single SVG file. This also can take
significant amount of CPU time to complete.
The reason for this behaviour is that currently whenever SVG backend
needs to emit an image tag for a surface pattern it takes a snapshot
of the subject surface, encodes it in PNG, then Base64-encodes and
emits the (huge) resulting string. With use of
cairo_surface_set_mime_data API this can be somewhat improved by
associating JPEG image contents with the corresponding surfaces.
Still this doesn't allow for post-processing of involved photographic
images without regenerating the SVG file.
As SVG specification allows URIs in the image tag's xlink:href
attribute, it is possible instead of embedding encoded image data to
simply link image files residing physically on the same medium as the
generated SVG file: files on disk under common directory, files on a
web server at common base URI, etc.
To make this happen we add new (unofficial) MIME type "text/x-uri" and
let users associate URIs with surfaces through
cairo_surface_set_mime_data() API. When SVG backend needs to emit
surface contents and it sees "text/x-uri" attached to the surface, it
emits this data instead of taking snapshot. The URI data is emitted
as is, so correctness check is left solely to the client code.
Adds a new, fake, fontconfig font backend. Fontconfig can be disabled
using --disable-fc, in which case the toy text API wont find fonts and
the internal font will always be used.
Also defines the feature macro CAIRO_HAS_FC_FONT. The two fontconfig-specific
functions in cairo-ft.h depend on that macro now.
The release notes for 1.7.6 say that we had dropped this
function, but apparently we had only planned to do that
and didn't actually get around to it until now.
Thanks to the RELEASING insctructions which gave a diff
command that pointed out this problem.
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()...
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.
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.
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.
