[Cairo] Why not Xr?
keithp at keithp.com
Wed Aug 13 15:55:44 PDT 2003
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
> 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:
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
> 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.
More information about the cairo