[cairo] Improving PDF output

[Behdad Esfahbod]

On Mon, 2007-01-08 at 13:16 -0800, Bill Spitzak wrote:

> I may not have been clear that I wanted this api in *addition* to the 
> per-glyph api, not a replacement. My main concern is that an awful lot 
> of glyphs are being placed the "advance" apart and that I feel that 
> Pango is probably well aware of when this is happening (not aware of 
> *always* when it is happening, but it seems likely it is able to detect 
> that large sequences of non-composing western glyphs are being printed). 
> It would seem a shortcut that does not rely on the backend detecting 
> this and recomposing the string would be a good efficiency gain.

The profiles I've seen don't suggest that this would be a good
efficiency gain.  It actually degrades performance, because for example
then we will be more Xrender calls, instead of packing multiple elements
into the same Xrender call like the current code does.  Same about
PS/PDF: more matrix setup code.

> What really prompted me to write was the suggestion that cairo provide 
> "helper functions" to do this, which implies it is difficult. I don't 
> like this solution. If it really has to be done by non-back-end code 
> then I think the backend should provide a "draw a bunch of glyphs the 
> advance apart" as a possible interface, and that the front-end code have 
> a default implementation of the per-glyph code that reduces to the 
> minimum number of calls to this.

That really depends.  Cairo is already using the helper-functions idiom
in the glyph code for setting scaled glyph properties.  scaled-font.c
asks the font backend for the glyph info and the backends calls back
into scaled-font.c to set them.

> But if the backend has this api, why 
> not allow direct access through the cairo api?

Because that's not the philosophy cairo has been following when adding
new API.

> >> Glyph id's are incredibly confusing and completely 
> >> contrary to the idea that Cairo's api should be "fun" and "easy".
> > 
> > No.  You are totally ignoring that even Latin needs things like
> > ligature.  If you mean we should do all the glyph processing in cairo,
> > that means you are just suggesting to move pango+pangocairo into cairo.
> > I don't see any reason to.  In the future, when script shapers are moved
> > to HarfBuzz from Pango, it may be possible to make the toy API useful
> > for more than ASCII though.  Still, the fact that the toy API doesn't do
> > font fallbacks, makes its use rather limited.  Though that's what the
> > Windows API do too, and people are living with it.
> 
> I am quite confused as to why Unicode indexes and glyph ids cannot be 
> made to match more closely. Ligatures and anything else not defined by 
> Unicode would turn into glyph ids that have values that are 
> application-defined unicode indexes. Imagine a 1:1 mapping of the 
> current glyph id's such that if the glyph has an obvious equivalence to 
> a unicode character it has the same value as the unicode character, 
> while all glyphs that don't instead have ids that cannot be confused 
> with a unicde character. There is an entire 2^16 plane and tens of 
> thousands of other unassigned unicode indexes available for these. 
> Another possibility is to map them to values greater than 0x10ffff, 
> which would preculde drawing them with a utf-16 or fully-standard utf-8 
> interface, but that may actually be a good idea.

Mixing glyphs and characters in the same space is what's incredibly
confusing to me.

> This will remove the need to differentiate between glyph and unicode 
> api's in cairo, which would go a long way toward making the api more 
> usable and "fun".

That API is hardly discoverable without reading docs.  I don't call that
usable or fun.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759