This is needed because analysis-surface takes any UNSUPPORTED returns
as a signal for using image fallbacks. So the fallback mechanism in
_cairo_surface_show_text_glyphs() is not enough. Reported by Adrian
Johnson.
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.
This can be used by _cairo_pattern_acquire_surface_for_solid() to let
the backend create custom surfaces for solid fill instead of a 1x1
similar surface.
This was added in 41c6eebcd1, to avoid
allocating short-lived patterns. However, this was error prune as the
color information was duplicated in the pattern and could get out of
sync. Indeed, it was out of sync before this commit in the call from
cairo-clip.c.
By allocating the solid pattern on the stack we fix the original problem
without creating new ones.
Originally reported here:
http://lists.cairographics.org/archives/cairo/2008-May/014032.html
and analyized later in the thread.
Change (font and surface) backend show_glyphs() API to take a
int *remaining_glyphs argument. It's used to communicate to the caller,
by way of setting remaining_glyphs and returning INT_STATUS_UNSUPPORTED,
that some of the glyphs were shown but not the others. The xlib backend
now correctly uses this to handle failure to upload a glyph to the server.
So the large-font test passes now.
An alternative approach could be to add some public value for glyphs
indices that are not shown. -1 perhaps (the xlib backend already uses
that value internally). Then instead of remaining_glyphs, a backend
could simply set glyph indices of glyphs shown to that -1 value.
This reverts commit ddcd6781a2.
This was an experimental commit that was intended to be on a side
branch but accidentally got committed and pushed to master. Sorry
for the noise.
This is an initial attempt at addressing the recently noticed
fallback-resolution bug. It isn't working correctly yet.
I'm just committing so that behdad can see what I'm up to.
We have tested the case of device transforms that have both translate and
scale. So it basically works. We just are not sure that we handle it in
all places (In fact we know we don't.)
Within the library, we know the precise size of the struct and so can
allocate temporary font options on the stack - eliminating the need
to export an internal alias of cairo_font_options_(create|destory).
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).
Use _cairo_pattern_create_copy()/cairo_pattern_destroy() instead of
_cairo_pattern_init_copy()/_cairo_pattern_fini() so the PDF backend
can reference the patterns and destroy them later.
If the backend does not support fallbacks ie backend->acquire_dest_image
or backend->acquire_source_image is NULL, then return
CAIRO_INT_STATUS_UNSUPPORTED rather than attempt to jump to the NULL
hooks.
In http://bugs.freedesktop.org/show_bug.cgi?id=13699, Pavel Vozenilek
reports a duplicate define for computing the appropriate length for an
on-stack array. The macro in question, and a few other places, was
performing CAIRO_STACK_BUF_SIZE/sizeof(stack[0]) so we can simplify
them slightly by using a common macro.
_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.
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.
