[Fontconfig] Re: [Cairo] Text API proposal

[Keith Packard]

Around 23 o'clock on Aug 11, Owen Taylor wrote:

> I guess I'm pretty set on an OO mindset these days. :-) I definitely
> see "a few extra win32 methods" as being inheritance rather than just
> some extra code we compile in on Windows.

Ok, so I guess the plan should be to always expose the native fonts as the 
"normal" API; you get cairo_font_win32 functions on the Win32 version of 
cairo and cairo_font_freetype functions in the Linux version of cairo.  
Code which can't deal with that isn't portable.  I can live with that, 
especially if we can provide the FreeType functions in Win32 as a 
bag-on-the side separate library for weird apps that want it.

> I'd tend to say that if we are going to have multiple font
> implementations, especially on the same platform, but even if not
> on the same platform, virtualization makes a lot more sense than a
> bunch of #ifdef's and switches.

Certainly there should be abstract datatypes which are independent of the
underlying font system; otherwise we'll all go insane.  The question is how
much functionality should exist at that level.  I'd like to make sure
enough exists so that most of the output code can be system independent,
even if the fancy font selection and layout code is heavily system
dependent.

> If you mean "an application that can handle Arabic and Hindi and Thai
> and all the other languages of the world that anybody wants to display",
> then there are two routes:

No, I plan on leaving cairo at the glyph level; anything else is clearly a 
bad idea at this point.  When layout libraries are better defined, we may 
be able to standardize on a single one on top of cairo, but that's not 
the right thing to do at this point.

I guess I'd like to see the actual rendering code able to use
system-independent functions; once the fonts and glyphs are selected and
positioned, it would be nice to have everything else use just cairo_font_t.

It would also be nice to provide system independent functions to deal with 
font selection, but I'm not sure that's a great plan given the differences 
between the various systems.  Perhaps we really do just want a 
cairo_freetype and cairo_win32 library for all of that and force 
applications to choose which underlying font selection mechanism is to be 
used.

> I don't think there is anything wrong with having an API at the
> approximate level of Xft in Cairo, but Mozilla has all sorts of
> ad-hoc FreeType and TrueType table access in it where it goes beyond
> Xft

Yeah, Xft is about the highest level I'd consider doing; something that 
takes unicode and maps each codepoint to a single glyph and sticks them 
adjacent on the screen.

> I'm not quite sure what the underlying mechanism is but the XP font
> selector knows the scripts supported for each font.

I wouldn't be surprised if it was just using the OS/2 codepage range bits.

> You probably could also compute language coverage information and cache it
> much as we do with font files.

I'd rather just bail on fontconfig for win32 and make you suffer there by 
providing cairo functions that took preselected win32 fonts instead.  
Having us design a Win32 API seems like a really bad idea...

> And if Cairo allows replacing the font system at runtime, it will be easy
> to hook it up.

We'll have to be careful in designing the internal interfaces that 
implement font stuff so that we can plug in separate datatypes and have 
them work, but I don't think it's impossible.  Stick the FreeType stuff in 
a separate library and just make applications link against it explicitly.  
We could do the same with the Win32 font stuff; that way the core cairo 
library would be the same and the differences would be isolated to 
external libraries.

I think we're converging on a reasonable direction here; don't pretend to 
be os-independent when applications are explicitly interested in os 
dependence.

-keith