[Cairo] Why not Xr?

[Keith Packard]

Around 15 o'clock on Aug 13, Justin Bradford wrote:

> As for a platform-independent "convenience" function for font selection,
> some cross-platform libraries (like wx) let you pick a generic font
> class for the times you don't care enough to write os-specific code,
> like "serif", "sans serif", "monospaced", etc.

That seems like a better plan than exposing FcPattern datatypes through 
our trivial interface.  The trivial interface can then be something as 
simple as a family, weight and slant values.  Anything beyond that could 
be relegated to os-specific code.

> So perhaps cairo could have a similar set of font mappings. Every
> platform would just have a list of specific font names/patterns for that
> class. I suppose that doesn't help for non-western languages, though.

We could require that the special names 'sans-serif', 'serif' and 
'monospace' always map to "reasonable" fonts; that's certainly easy to do.

> But this is a really general problem for cross-platform toolkits, and I
> still don't think it's cairo's place to solve it. Unless there are some
> really common cases which can be solved in a single, short source file, I
> think platform specific only is ok.

The motivation for the simple API is to make it easy to write simple 
applications that are portable across all cairo implementations.  There's
certainly a slippery slope that we can easily slide down, so I'm tempted 
to keep this as basic as possible.

> I assume cairo_font is basically an interface with specific font backends
> wrapping a FT_Face (is that the right term?) or LOGFONT, right?

That's actually not certain -- it may be that we should not support 
multiple backends in the same implementation and that a 'cairo_font_t' on 
Windows always contains a LOGFONT while on Linux it could always contain a 
FT_Face.  Intra-platform uniformity among multiple toolkits and rendering 
libraries seems of significantly greater interest than inter-platform 
application portability.

> And in the cairo_draw_text function, the specific backend implementation
> gets the underlying specifics from the cairo_font wrapper?

If we did support mulitple back-ends, then presumably the font itself 
would point at a list of functions implementing the various 
platform-specific operations, so 'cairo_draw_text' becomes:

	(*font->functions->draw_text) (...)

This would allow us to plug in new backends without changing the core 
library, making it very easy to place these backends in separate shared 
libaries.

> Postscript and similar backends just need a "get_glyph_outline" function
> on the cairo_font which just returns paths, right?

I suspect there will be quite a few optional font functions so that the 
PostScript backend can get at the Type1/TrueType data to embed all of the 
necessary information on systems which can provide it.  A fallback to 
simply creating a PostScript font from the outlines would work on other 
systems, or for weird font formats.

> Or is this all part of the plan already?

I think we're all still digesting the notion that "real" font manipulation 
in cairo will always be system dependent; that's a lot different than I'd 
originally thought it would be.

-keith