A little bit of sleep and reflection suggested that the use of
device_offset_[xy] was confusing and clone_offset_[xy] more consistent
with the function naming.
Previously the rule for clone_similar() was that the returned surface
had exactly the same size as the original, but only the contents within
the region of interest needed to be copied. This caused failures for very
large images in the xlib-backend (see test/large-source).
The obvious solution to allow cloning only the region of interest seemed
to be to simply set the device offset on the cloned surface. However, this
fails as a) nothing respects the device offset on the surface at that
layer in the compositing stack and b) possibly returning references to the
original source surface provides further confusion by mixing in another
source of device offset.
The second method was to add extra out parameters so that the
device offset could be returned separately and, for example, mixed into
the pattern matrix. Not as elegant, a couple of extra warts to the
interface, but it works - one less XFAIL...
We reverted the public API for setting lcd_filter font options
back in 1b42bc8033 , but we had left the implementation which
would examine fontconfig and Xft properties for the option, and
which would call into freetype for subpixel glyph rasterization.
However, I recently realized, (and the test suite had been trying
to tell me for a while), that this approach would cause a
regression for users who were previously using sub-pixel text,
but without sub-pixel rendering built directly into freetype.
That's not acceptable, so all the code is coming out for now.
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()...
cairo_surface_get_font_options() has the side effect of initialising the
font options on the surface, but fails to check that the surface is
valid first. Therefore if we are passed a read-only error object, we will
trigger a segmentation fault.
Most likely this is the bug behind:
http://bugs.freedesktop.org/show_bug.cgi?id=17096.
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.
