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.
It's trickier than it appears...
There still remains the question of whether the loop should iterate
utf8 forward and glyphs backward (as it does now), or iterate glyphs
forward and utf8 backward.
Doing utf8 forward has the benefit that glyphs appear in the PDF stream
in the logical order of text. That may be a good thing.
Doing glyphs forward has the benefit of most glyphs taking their natural
width, providing for a more compact PDF output.
Firefox 3 currently calls cairo_show_glyphs() with glyphs going
right-to-left for RTL runs. That's like going utf8 forward.
On the other hand, if we are fine doing glyphs backward, then we may as
well remove the "backward" flag and ask callers of show_text_glyphs to
produce glyph array going right to left for RTL runs. The idea behind
having a backward flag in the first place was to allow keeping utf8 in
logical order and glyphs in visual left-to-right order. If we don't
do that in practice, there's no point in having the flag. Another design
idea of the flag was to mark right-to-left runs explicitly so the backend
can use this information. In that case we probably better rename it to
"rtl" as the current semantics make it perfectly fine to set a LTR segment
with backward flag on: just revers the glyph array...
Anyway, the way to determine the right thing to do is to see how Acrobat
extracts text for RTL text in logical vs visual order. Then we can decide
what to do in the PDF backend and whether the flag is worth keeping.
Going to experiment with that.
One is enough. The only downside is that meta-surface will consume
32 more bytes per show_glyphs() call now. If that's a concern,
the show_glyphs implementation can be added back.
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.
It was reported by Liu Yubao that cairo_status_t may be chosen to be
an int8_t by the compiler, in that case cairo_int_status_t values
assigned to cairo_status_t would overflow. Fix this by allocating
the values in int8_t range, and add compile-time sanity checks.
Do this by tiling the surface form the solid pattern. The pattern in
turn calls into xlib's create_solid_surface which returns a dithered
pattern.
This can get into infinite loop right now, because of the way solid
surface cache tries to repaint cached surfaces.
Otherwise we can't do dithering. This drastically improves gradient rendering
on 16bit displays, essentially making them indistinguishable from 32bit ones
with a naked eye.
Remove the intermediate rgb333 for PseudoColor and work on the
cube directly. Also upgrade to a 6x6x6 cube instead of 5x5x5.
Do dithering on both PseudoColor and TrueColor, using a 4x4 pattern.
This only affects X servers with no XRender.
