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

[Glynn Clements]

William Kyngesburye wrote:

> >> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
> >> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
> >> below) it was a beta and is not available for download any more, as
> >> far as I can tell.  I think the betas must be where fontconfig wasn't
> >> a part of Apple's X11 package (and I'm sure it wasn't at first).
> >>
> >> So, using fc-list on OSX, if it's available, for mkftcap is
> >> reasonable, for now.
> >
> > Is it possible to filter any non-TrueType fonts from the output? Or
> > are there not enough TrueType fonts to worry about?
> 
> I'd say all are TT fonts.  The problem is the mix of font packaging  
> and file extensions, or lack thereof.
> 
> Though, FreeType is easily built with support for all types of fonts  
> and font packages (my FT framework build supports all) - TT & PS (&  
> others), and nix/pc flat file, Mac resource font, dfont & otf packages.
> 
> 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.

> For the usefulness of particular fonts, this appears to be the  
> general pattern of fonts:
> 
> - resource fonts (TT) - MS fonts
> 
> - ttf - language support fonts, so limited usefulness, but there  
> appears to be a couple general use fonts
> 
> - dfont (TT) - where most of the useful fonts are, besides the MS  
> fonts, including Helvetica, Times and a collection of other fonts,  
> but also includes some language support fonts
> 
> - otf (TT) - there are a few opentype fonts for Japanese and Chinese
> 
> So generally, what is supplied in OSX are all TT fonts, it's just  
> that the ttf packaging has the least useful of them.

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

> 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.

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