Fixes the bug that paginated backends had font-matrix translation
applied twice, AND removes a second copy of the glyphs. It's
essentially similar to what cworth did for stroke/fill/clip in
this commit: bd92eb7f3c
Reviewed by: Carl Worth
There appears to be a bug in some X servers which is triggered by
rendering 1-bit glyphs with zero size via the functions
XRenderAddGlyphs and XRenderCompositeText8 (and likely its variants).
We avoid this bug by making a copy of the glyphs array which does not
include any of the size-zero glyphs so that the X server never sees them.
As the font matrix includes translation, which is otherwise unused for glyph
transformation, the interpretation of translation is fairly arbitrary. For
1.2.0, we choose to have this translation affect the glyph advance with the
thought that it could be used to do letter spacing/kerning. That is fairly
useless in practice, and a far more useful interpretation is to relocate
the origin of each glyph.
This patch uses the translation in the font matrix as an offset for the
glyph origin in user space. It turns out glyph extents were already correctly
shifted.
The end result with this patch is to have cairo match the 1.0 behaviour for
font matrix translations, but now we know why :-)
Explanation above courtesy of Keith Packard.
This makes the following four tests pass, (which were previously
failing on the ps backend).
move-to-show-surface
scale-source-surface-paint
source-surface-scale-paint
translate-show-surface
This is an attempt to fix the following bug:
http://bugzilla.gnome.org/show_bug.cgi?id=332266
With the recent rewrite of the device-offset code, which pushed things
from the gstate to the surface layer, the 16-bit limitations on coordinates
which previously applied to device space only, have lately been applying to
user space. This commit moves the device_transform back up above the conversion
from floating-point to fixed-point values so that once again the limitation
only applies to device space.
