[Cairo] Text API proposal

[Thorsten Behrens]

Yesterday, Carl wrote:

> Here's the proposed primary Cairo text functionality which fits in 7
> functions. There's a "toy" API here so people like me can succeed in
> getting a string on the screen. Then there's a real API for placing
> individual glyphs at absolute locations so that people like Pango/OOo
> developers can get their work done:
>

Okay, speaking of OOo: we're currently also in the progress of overhauling
our text rendering APIs, and when comparing the functionality needed for
our latest draft
(http://gsl.openoffice.org/canvas/api/XCanvas.html and
 http://gsl.openoffice.org/canvas/api/XFont.html),

we're wondering whether cairo will fit the needs (or maybe, if we
overestimate our needs). Because: One thing we learned in OOo is that most
people prefer native widgets over a cross-platform one-size-fits-it-all
approach. So when overhauling OOo's text API one of the most important
design goals was to avoid this problem: The native text infrastructure
should be used if possible. Users of the text API blackbox should never be
bothered with any of these implementation details though.

We're not sure what cairo's priorities are but we think the design
goal mentioned above has some merits.

We won't debate the toy API here, except for the fact that exposing
FreeType might be troublesome when porting to native Windows (or OS X,
that is). No, we're mainly concerned with the proposed glyph rendering
API. We assume here that a Windows port will _not_ just push bitmaps for
text rendering, taking all supporting libs like Pango, FreeType etc. with
it, but make use of built-in functionality. Our experience has shown that
working around a native font subsystems when there already is a good
infrastructure causes more trouble than it solves.

We think that the layout framework and the generic text API need to be so
tightly coupled as to be indistinguishable for from the outside. When
native font subsystems like Win's Uniscribe or OSX's ATSUI are to be used,
it is very hard to separate them.

Why not abstracting away the layout framework within a generic text API?
That would also cater for backends (like e.g. PDF) that need more than raw
glyph codes.

It also allows the implementation of some neat features like "artificial
glyphs". E.g. displaying the unicode character U+FF10 ("FullWidth Digit
Zero") with an ASCII only font using the normal U+0030 ("ASCII Digit
Zero").

Also "glyph fallback" should be possible without troubling the user of the
text API. Imagine an ASCII-only font. When somebody types a text with e.g.
an u-umlaut this character is not in the font. Getting the glyph from a
related font and using this fallback glyph transparently for everything
including e.g.  measurements makes life much easier.

Just our 2 cents,

-- 

Herbert Duerr, Thorsten Behrens

SO/OOo developers