[GRASS-dev] font path question for Linux and Windows

Glynn Clements glynn at gclements.plus.com
Wed May 2 04:10:51 EDT 2007


Glynn Clements wrote:

> > I'm a bit puzzled by the fixation on TT fonts for FreeType support.   
> > Shouldn't the text display commands be able to use whatever types of  
> > fonts that are supported by the installed build of FreeType?
> 
> Yes. However, that isn't all of the fonts which fc-list shows. E.g.
> fc-list shows the PCF fonts, but those don't work with R_font(). Type1
> fonts work.

FWIW, I've extended the mkftcap script to accept .pfa and .pfb files.

> In that case, you can probably just convert the entire output from
> "fc-list : file" to a freetypecap file.

In addition to scanning directories for files with specific
extensions, mkftcap also uses the output from "fc-list :outline",
which should find all of the OSX fonts.

> > Then there is the other problem - resource fonts, dfonts and otf  
> > fonts can have, and most do in the OSX system, multiple faces per  
> > file.  The font display routines in GRASS need an option to specify a  
> > face in a font file, either by index number or name.  Otherwise most  
> > of the fonts included in OSX are of limited usefulness.
> 
> That's easy enough to implement.
> 
> One option is to pick an arbitrary character to separate the index
> from the filename. If the path ends with that character followed by a
> number, the number is the index.
> 
> That has the advantage that only the lowest level of the driver code
> needs to change (draw_main(), in lib/driver/text3.c; the function
> which calls FT_New_Face()).
> 
> Obviously, alphanumerics are out, as are CR, LF, colon, dot, slash and
> backslash; also, space, dash and underscore are all too common. 
> Characters outside the range 32-126 are also problematic. That
> basically means an ASCII punctuation character.
> 
> A vertical bar (ASCII 124) might be a good choice. It isn't legal in
> Windows filenames (all of \/:*?"<>| are prohibited); I use it a field
> separator in text files (comma isn't that uncommon in filenames), and
> I've never had a problem due to it occurring in a filename.

The updated mkftcap script should cope with multi-font files; the part
which uses fc-list outputs the index, and should append it to the path
if it isn't zero. I can't test this, as none of my font files have
more than one font.

Also, I haven't updated the driver code to handle indices yet.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list