On Mon, 2003-08-11 at 16:31, Keith Packard wrote: > Around 14 o'clock on Aug 11, Owen Taylor wrote: > > > If you set up things to allow A), B) comes naturally. If you > > have a CairoFontWin32 implementation of CairoFont, you can have > > cairo_font_win32_from_logfont(). > > One option is to always provide FreeType APIs (for portability) and then to > add native APIs at some level to let people plug things in at this level. > > cairo_font_freetype_t cairo_font_freetype_create (FT_Font font); > FT_Font cairo_font_freetype_ft_font (cairo_font_freetype_t cff); > cairo_font_t cairo_font_from_freetype (cairo_font_freetype_t cff); > cairo_font_win32_t cairo_font_win32_create (...); > cairo_font_t cairo_font_from_win32 (cairo_font_win32_t cfw); I don't think even linking to FreeType on, say, Windows is right; for various reasons: - One more dependency that won't be there normally - Inconsistent rendering between different apps - Having cairo_font_t be polymorphic on a single system is going to be confusing and lead to problems where people assume that a font *must* be a cairo_font_win32_t. It isn't a bad idea to allow people to plug in a new font system on the fly if they are doing something really custom, but having two font systems always there is rather peculiar. > then people could choose which they prefer. That leaves in question how to > deal with fontconfig and the 'trivial' APIs. One option is to map > fontconfig patterns to native fonts inside cairo so that (by default) you'd > get native fonts on every platform: This is an appealing choice, as long as the goals mentioned in my last mail are possible: consistent list of fonts with the system, and minimal overhead when not used. > cairo_font_freetypet cairo_font_freetype_create_from_pattern (FcPattern *pattern) > cairo_font_win32_t cairo_font_win32_create_from_pattern (FcPattern > *pattern) > cairo_font_t cairo_font_create_from_pattern (FcPattern *pattern) > > Make cairo_font_create_from_pattern call one of the other two and return > the casted result. Pango uses a factory setup that would look like: cairo_font_map_create_font_from_pattern (fontmap, pattern); I think this works a bit better in general. > Apps that "don't care" can use the generic functions, apps that "kind of > care" can use just the freetype functions while apps that "really care" > can have conditional code that selects the correct code depending on the > underlying operating system. Does this intermediate state of caring make sense? You shouldn't get one rasterization if you "don't care" or "really care", and a different rasterization if you "kind of care". > What I want to avoid is attempting to provide an abstract interface on top > of the underlying font system; that will just frustrate people and cause > cairo to forever lag behind. What do you mean by an "abstract interface"? Do you mean a generic interface that goes beyond being useful for don't-care applications? Regards, Owen