[Cairo] Text API proposal

[Owen Taylor]

On Tue, 2003-07-29 at 11:13, Thorsten Behrens wrote:

[...]

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

Would you use Pango in OpenOffice.org on all platforms? Would
use it if it was called CairoText? That's what you are proposing.

Once you have:

 - A high level easy-to-use API that has the full power to handle
   complex writing systems.
 - A low-level abstraction that can work with different font systems
   like FreeType and Uniscribe. (Pango has a fully functioning
   Uniscribe backend. There are some performance issues, but we
   think they are incidental.)

You have all of Pango (and 50,000 or so lines of code). If you
implemented the FreeType/Unix backend by using Pango itself, 
you'd save a bit of that code, at the cost of efficiency and
increased complexity.

The question of how you can use "Pango" and Cairo together on top
of something other than FreeType is indeed an interesting one
and one that needs to be handled if GTK+ is going to use Cairo
as it's rendering API.

I don't see how putting a Pango equivalent into Cairo really helps with
that; the basic plan of a solution is:

 - Figure out what operations Cairo needs from the font API
   to implement it's low-level and toy APIs:

    - Load a font from a name
    - Scale/Apply a transformation matrix to a font
    - Convert Unicode text to glyphs
    - Render a glyph to a bitmap
    - Add a glyph to a cairo path

 - Create virtualized CairoFontmap, CairoFont (or, I guess,
   cairo_fontmap_t, cairo_font_t, ugh.) objects.

 - Have functions for setting the CairoFontmap for a context

 - Ship implementations of CairoFont* with Cairo for major
   rendering systems. These would have functions like
   CairoFont *cairo_fontconfig_font_new_for_pattern()
   FT_Face cairo_fontconfig_font_lock_ft_face ().

Then, as the person hooking together Cairo and Pango, then all
I have to do is to write a little bit of glue to hook 
CairoFontconfigFont to PangoFontconfig and a bit of glue for hooking
CairoWin32Font to PangoWin32.

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

These are "toy API" issues.

Regards,
						Owen