[cairo] Improving PDF output

[Baz]

(drifting further off the topic of glyph<->unicode mapping...)

On 08/01/07, Behdad Esfahbod <behdad at behdad.org> wrote:
> No, I have the exact opposite feeling.  We can add lots of different
> cairo operations to show glyphs, but in the end, apps that have the
> positioned glyphs prefer not to bother about which API to use.

Actually this is a problem for ATSUI. The Mac apps *dont* have
positioned glyphs, they have ATSUTextLayouts. The moz code splits out
positioned glyphs at the last minute because thats the only thing
cairo can handle; using the layout directly would take a lot less
code. On top of that, whats there now is never going to give us nice
rendering of AAT features.

The problem there is that the current code can display unstyled glyphs
from a font instance (eg Helvetica Bold Oblique), but when advanced
features are used, e.g. continuously variable condensed/bold, there is
no API to render that glyph, only to get its path. Rendering glyphs
using their paths is ugly at small point sizes, and won't do subpixel
antialiasing. ATSUI does all that stuff internally, and it'd be better
if we could just tap into it.

I don't have an easy answer though. The 'natural' cairo-atsui API
would work mostly with layouts not glyphs, but that doesn't fit well
with the pango setup. At some point, to get the best out of both APIs,
maybe we need to ditch the idea that you can make directly equivalent
calls in the non-toy api. This doesn't seem odd to me, they need
font-backend-specific code to get hold of the glyphs in the first
place?

Anyway: changing the API isn't my goal just now, its making what's
there work right (as Bill says, any change would have to be in
addition to what's there). I might come back to this when I try to
make it work fast though.

Cheers,
Baz