[Cairo] Text APIs round 2

[Kai Wetzel]

On Thursday 14 August 2003 21:47, Keith Packard wrote:
> Around 20 o'clock on Aug 14, Kai Wetzel wrote:
> > Why not drop the explicite font from the glyph struct and use the current
> > font ? In most cases the number of fonts in use is significantly smaller
> > then the number of glyphs in a given piece of text.
>
> Because it's easier for applications to just explicitly set the font for
> every glyph -- otherwise, the application has to check if the font is the
> same or set it before every rendering call.

In most cases, applications won't be involved directly, they would rather use
a text layout library like Pango or use high-level funtions provided by the
toolkit (e.g. Qt). But even if an application needs a custom text layout layer
I don't see how this would complicate things much, compared with the other
complexities involved. 
For me, setting the font before drawing a style-run even
seems very natural, but from what you are saying I understand that many
people see this differently. My concern is not really the application-
programmers API, though.

> It's only temporary storage
> for each string, so memory usage isn't a serious concern.
>
> Experience with Xft has demonstrated that of the vast number of interfaces
> provided for applications, only the unified position/glyph/font structure
> has seen any significant use.  If other applications find this so painful
> as to be a problem, we can add new interfaces in the future.  But, I'd
> rather not add interfaces that aren't going to be used.

I think that it's useful to specify a core API containing those essential
functions which a driver would have to implement and see the other funtions
as convenience provided for application programmers. This core set of
functions should IMHO be feature-complete (of course) and concise.

I would further like to see display lists (command lists) added to the show.
This makes it necessary to specify clearly which functions can go in a
display list, and which can't (such as those returning a value).

Eventually, I would like to see a server-side implementation of the (core) 
vector graphics API (be it X or some other display server) including display 
lists stored in the server.

> > This also makes it a little bit more suitable for display-list
> > construction because the font references don't have to be dereferenced at
> > the time the list is constructed.
>
> I can't see how this makes any difference.

It seperates cleanly (at the core API level) the function which requires 
turning a client-side font description into a server-side, immutable font
representation (cairo_set_font) from the other funtion which just dumbly puts
glyphs from the current font and doesn't need much conversion or lookup
before sending it to the server.

I think the font-for-each-glyph functions is more high-level, combining
multiple functions into one (and less cocise by passing the same (font) 
info multiple times in almost all practicle cases).
I see no reason why this function shouldn't be provided on top of the
set_font + the simple draw_glyphs functions if people like it, though.

kai