I don't recall anything about this in the PDF reference, (though I
also didn't look specifically for it), but without this acroread
is quite unhappy with cairo's PDF output when it includes dashing.
Use the same approach as the PDF backend: emit the pen matrix as the
SVG transform for the stroke, and compensate by first transforming all path
coordinates by the ctm_inverse.
Clarify the documentation of cairo_set_line_width to indicate that the
value will be interpreted within the user space at the time of the
stroke.
Also adjust the comments in test/line-width-scale as well as the
reference images for that test to match.
Remove local image check from fill_rectangles and fix check for whether
we can AlphaBlend or not (ARGB->ARGB AlphaBlend works fine)
(cherry picked from f099783b3e7f895a59d4d4a67a8534f1d21d44e1 commit)
xlib_show_glyphs was always calculating the glyph extents, even when it
didn't need to; this only does it when necessary.
Also adds an implementation of surface_flush() for xlib that just calls
XSync.
(cherry picked from 8770ac5b5cdba8007c4c6a6a980e6e06acf6aeb6 commit)
Avoid using the fallback paths as much as possible; implement real
show_glyphs, falling back for OPERATOR_SOURCE (due to Render bug), and all
unbounded operators (let the fallback code deal with fixup). Also fall
back if we have a fallback mask clip set.
(cherry picked from 3225a4ec820fd4051dd893ffc4258b182bd62dca commit)
Including style cleanups for _xrender_format_matches_content.
There's even a bug fix here as well. Previously, we would miss compatibility
if the existing xlib surface had a NULL visual, (even if it had a compatible
xrender_format). We now catch this case, and don't bother even trying to
store a visual into the resulting surface.
I recently discovered that cairo_create_similar on a 16-bit xlib surface
creates a surface backed by a 24-bit pixmap. This results in absymal
performance --- I can actually watch a copy from the similar to the
original move down the screen, on my dual Xeon, NVidia vendor driver
machine. It also means xlib-based code like GTK themes can't render to
the surface because it doesn't match the screen depth.
The attached patch makes _cairo_xlib_surface_create_similar match the
characteristics of the input surface as closely as I know how, and fixes
my issues.
This allows for more sharing of resource objects. It also avoids some
confusion in trying to set independent resources at a global and a
per-page level, (which doesn't work since the inheritance only works
for an entire resources object---it can only be overriden in its
entirety, not for subsets of the resources).
The only expected errors that would lead to this fallback are serious
problems such as out of memory. There's no reason to go to heroic
efforts to draw as much as possible in face of an error like that.
Prefer simpler code instead.
Since we are only ever displaying a single glyph at a time we don't
care about the width values passed to setcachedevice at all---we only
care about the bounding box.
That's what the code was trying to do before, but the arguments were
misaligned and we were instead passing bounding-box values for the
widths and hard-coding half of the bounding-box values as 0.
The return of status from this callback was misleading. The function
actually calling the callback was also a hash table callback function,
which itself is void---so any status value returned was being lost.
Instead, we now stash any errors that occur during the fallback into
surface->status.
Eliminate the named structure cairo_pdf_stream_t. This structure was
being dynamically allocated, passed around, and leaked when only an ID
was actually needed to be passed around.
Similarly, many other uses of PDF resources were passing bare unsigned
int types rather than the safer and more legible cairo_pdf_resource_t.
This is an adaptation of Keith ps-type3 branch for SVG backend.
Main differences with ps stuff are font cache is a property of
document, and there's no need of subfonts.
