Specifically, device offsets now affect using the offset surface in
a source pattern as well as drawing to the surface. This behavior
os also verified with a new test case: test/device-offset.c
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.
- Include PS standard encoding table so we can map from standard
encoding indices to glyph names and then make sure to include the
glyph of that name.
- Cut out verbose debugging code.
- Fix a couple of bugs in glyph name to index lookup code.
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.
- Add _cairo_ps_surface_emit_type1_font_subset() which just dumps the
type1 subset into the ps document.
- Add a 'name' parameter to _cairo_type1_subset_init() so it will be
defined under the right name in the ps document.
- Quiet down debug output from type1 subset code.
- Reenable code to output custom /Encoding table.
This patch also factors the word wrap stream setup and teardown
and the call to _cairo_path_fixed_interpret() out into a new function,
_cairo_ps_surface_emit_path().
We probably should figure out from the private dictionary which of the two
pairs the font defines and uses, but I don't actually have fonts that
use -| and |-, so for now for flip the default.
Backends that use the font subsetting code should add the font subsetting
sources to the build. This is dont by setting libcairo_font_subset_sources,
in the conditional section for each backend. If any one is enabled, the
sources will be added to the build.
Same story as for the pdf backend: try to output a truetype subset if
possible, otherwise fall back to a type3 font. Ajdust text output code
to scale font accordingly and scale type3 fonts to unity.
This change changes the text output code to use the Tm operator for
positioning the glyphs. This allows us to set the scale matrix from
the cairo_scaled_font_t so truetype glyphs get transformed correctly.
However, we now need to scale type3 glyph to unity to compensate.
Longer term we should just only output one unit sized type3 subset for
a cairo_font_face_t and use that for all cairo_scaled_font_t's coming from
that font face.
Also, this fixes a num_glyphs initialization bug.