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); 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: 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. 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. 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. -keith
