[cairo] Improving PDF output

[Bill Spitzak]

Behdad Esfahbod wrote:
> 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.

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.

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. But if the backend has this api, why 
not allow direct access through the cairo api?

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

I think that is equivalent to the current glyph api. As soon as an array 
is needed other than the source string it probably does not matter what 
it's size is.

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

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

I absolutly agree that font fallbacks should be moved out of Pango and 
into Cairo. It does not have to be anything complicated, basically if 
the current font can't draw a glyph, Cairo will instead select from a 
fixed, unchangable, backup selection of fonts. It does not matter how 
ugly it is, even 16x16 bitmaps would be acceptable. The advanced font 
api would still say the current font cannot draw a glyph, but 
Pango/whatever could then send the code anyway and assumme something 
will appear.