[cairo] Improving PDF output

[Behdad Esfahbod]

These are some really frightening comments from you, Bill!

On Mon, 2007-01-08 at 15:03 -0500, Bill Spitzak wrote:
> I suspect the application will be well aware that they are using the 
> metrics for the glyphs unchanged.

Not quite.  Pango doesn't keep track of that as the shaper or the user
may reposition glyphs.

> What I would like to see is a api which is "here is a big list of 
> glyphs, please draw them all starting at x,y and use the escapements for 
> each glyph to get the next one". I'm pretty certain Pango/whatever is in 
> a better position to detect when and if it can use this api, rather than 
> having the backend check every displacement to see if it happens to be 
> the metric escapement, which sounds very wasteful, especially because it 
> is complex enough that you don't think the backends can do it directly 
> but must be provided with helper code.

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.   What's
wrong with letting cairo handle it?  I made the xlib backend do this.
Alp did it for PDF.  It's easy enough to do for PS and SVG too.  I
wanted to do it in the gstate or surface layer, but it's just easier to
do it in the backends, because you have the rounded extents that you
encoded in the output (X server, PS/PDF/SVG file), and can compare that
to the rounded glyph advance.  And you have to find the scaled glyph in
the backend anyway, so you have the default advances available readily.
I don't think this stuff needs any helper functions.

If we want to go by your position, next thing would be "let's add a
cairo api for showing glyphs positioned horizontally".  PS has this
xshow operator after all...


> While you are at it there should also be the exact same function except 
> the list of glyphs is a UTF-8 encoded string and byte count. Yes I know 
> this is the "toy" api. Lets make it not be a "toy". I think it is pretty 
> clear that it is the api everybody wants! Pango and other layout 
> programs should be able to cleanly and easily use this as well as the 
> per-glyph api. I know the problem is that glyphs are not unicode 
> characters, but I feel that should be fixed by the cairo api, by 
> defining glyph ids as being equal to the unicode code they match, or 
> using the application-defined block of unicode if there is no 
> correspondence. 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.


-- 
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