[Cairo] Text API proposal

[Carl Worth]

On Jul 30, Kai Wetzel wrote:
 > That's one of my main itches with the API proposal: What is the
 > seperation between the low-level drivers' responsibilities and the
 > "shared", high(er)-level parts of the API

That's the big open question right now. The goal of Cairo is to have
extremely high fidelity in rendering across many different output
devices. Of necessity, this requires Cairo to implement a lot of
functionality itself, and have a rather low-level backend interface.

At the same time, we're not sure of all the answers at this point, and
we'll learn a lot as we actually start implementing more backends. One
thing we are doing is not exporting the backend interface, (at least
for the time being). This gives a lot more flexibility in adapting the
interface as we learn, and it may be that different backends plug in
at different levels.

 > Did you consider adding "display list" support to Cairo ?

Not yet. We can certainly look into it.

 > > 	void
 > > 	cairo_select_font (cairo_t *ct, char *name);
 > 
 > Where "name" is a Xft pattern including scale/matrix, etc. ?

The idea was to use a fontconfig pattern string, yes. The nice thing
about this string-based interface is that it provides a lot of
flexibility.  PostScript, for example, leaves the interpretation of
the name as completely implementation dependent. I'd like to make some
stronger guarantees about what the user can expect than that, though.

 > This function, along with the "current*" functions, shouldn't
 > be expected from all drivers, making it possible to have "write-only"
 > drivers (PostScript, PDF, etc.).

I'm not convinced it will be necessary to have any write-only
drivers. Since Cairo provides alpha-blended compositing, and
PostScript does not, it will be essential to be able to get the
current output state for input to the compositor.

Keith's latest idea is to always have a libic-based in-memory buffer
being rendered to alongside the PostScript output stream. It would
also keep track of the region that has been touched by non-opaque
objects. Then, at the time of showpage, it could put the relevant
region from the libic surface onto the PostScript output.

 > How will drivers and the high-level layout layer communicate
 > fonts and font-metrics to match ?

The current proposal is to just directly expose the Freetype API. I'm
waiting to see if that plan will meet violent objections or not.

 > E.g. I could just use FreeType directly or let Pango use FreeType
 > directly, no need to go through Cairo in the layout phase, right ?

That's the idea.

-Carl