William Kyngesburye wrote: > >> So, I'm disabling the freetype backend and looking at the Cairo > >> quartz > >> font backend. I don't know how GRASS passes font details to Cairo, > >> so > >> I don't know if this will work. In general, how do you specify the > >> cairo backend to use (surface and font), from GRASS? From the GRASS > >> docs, it looks like file extension sets surface backend. > > > > There's no inherent reason why it can't support multiple font > > back-ends. Each provides a different mechanism to obtain a > > cairo_font_face_t* which can be passed to cairo_set_font_face(). > > > > The main issue is that each back-end needs corresponding > > platform-specific code to get the platform's font handle. > > > I'll see what you come up with for freetype fonts. Maybe I can make > sense of the OSX font API(s) and add Cairo/Quartz support.
The support for FreeType fonts via Fontconfig was simple enough. [Most of the effort was spent tracking down why it wouldn't scale the font correctly even though it would rotate it. It turns out that it was a bitmap font, and cairo won't scale bitmap fonts even though it will rotate them.] That should suffice for most purposes, although we can add the option to use a TTF file via an explicit path if there's a need for it (AFAICT, the ability to bypass Fontconfig is mainly for cases such as web fonts, fonts embedded in documents, etc). For Quartz, you need to figure out how to get either a CGFontRef or an ATSUFontID: cairo_font_face_t* cairo_quartz_font_face_create_for_cgfont(CGFontRef font); cairo_font_face_t* cairo_quartz_font_face_create_for_atsu_font_id(ATSUFontID font_id); Similarly, Windows needs a LOGFONTW* and/or an HFONT: cairo_font_face_t* cairo_win32_font_face_create_for_logfontw(LOGFONTW *logfont); cairo_font_face_t* cairo_win32_font_face_create_for_hfont(HFONT font); cairo_font_face_t* cairo_win32_font_face_create_for_logfontw_hfont(LOGFONTW *logfont, HFONT font); > But it will probably mean a complete overhaul of the fontcap setup: Well, it would probably be better to dispense with the fontcap file altogether and just make the driver use the appropriate font management APIs. Given that cairo's FreeType back-end requires Fontconfig, we may as well use that to enumerate the available fonts. > We may need to revise the fontcap setup for more platform-specific > behavior. On OSX it would have to detect "enabled" fonts at runtime, > and not installed fonts when g.mkfontcap is run. This may be easy to > do with python, since it (directly or wx?) probably already has some > such feature or extension. > > Or, since it will still be possible to use freetype and native font > APIs together, leave the fontcap for use by freetype, and have a new > font list function for use by OS native font routines. Personally, I doubt that it's worth going beyond whatever the "system" API provides. Well, other than providing the ability to use the stroke fonts. At present, the driver's Font_{list,info} methods override the generic methods. Ultimately, they should be merged, so that stroke fonts are implemented by the driver library using the driver's polyline method while other fonts are implemented within the driver. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev