[GRASS-dev] 7.x Status Update

[Glynn Clements]

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 <glynn at gclements.plus.com>