because pdfTeX (and maybe other PDF consumers) can not handle it.
Previously the content stream was an Form dictionary because at the
time the content is written it is not known whether the content stream
will be belong to the page or be an XObject in a knockout group. With
the additional of the paginated surface function
set_fallback_images_required() this information is now known at the
time the content is emitted.
As the translation is in text space, the full precision of a double
for numbers close to zero is not required. Limit the precision to the
same as for numbers > 1.
Sylvain Munaut discovered a bug in
_cairo_pdf_surface_emit_meta_surface() where the clip may be emitted
after the stream is closed. Fix this by moving the call to
_cairo_surface_set_clip() to before the stream is closed.
Previously this was not correctly checking the position of the first
glyph and falling back to using TJ if the glyph was not at the the
standard glyph advance.
Previously the PS emulation of the PDF operators would change the
current position to the text line matrix instead of the the text
matrix when changing the font.
Ickle knew something when he only extended cache size when we are
committed to inserting something into the cache. I broke that while
fixing other issues a while ago. This cache just doesn't want to
give us any rest...
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.
