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

[Glynn Clements]

William Kyngesburye wrote:

> >> Note that font names on OSX aren't required to follow any file
> >> extension conventions.  First the HFS+ file type/creator is used to
> >> determine if a file is a font, then the file extension if the type/
> >> creator are empty.  I think it's that order.
> >>
> >> So scanning automatically for fonts to create the freetypecap may
> >> miss many fonts, unless it knew how to check OSX type/creator info
> >> for a file.
> >>
> >> ie the MS fonts that come with the system have no extension.  Also,
> >> many TT fonts in OSX have been repackaged in the .dfont (a flattened
> >> resource-fork file).
> >
> > In which case, users will need to construct the freetypecap file
> > manually.
> >
> If you do that, there is not much point to the automatic scan - most  
> of the useful TT fonts that are included with OSX are either dfonts  
> or have no extension.  Most, if not all, of the included .ttf TT  
> fonts are miscellaneous language fonts.
> 
> But, then there is another problem (and in general TT font usage) -  
> d.font.freetype doesn't handle multiple faces in a file.  Many dfonts  
> and resource fonts (the ones with no extension) have multiple faces  
> in a single file (ie regular, italic, bold..).  Without specifying  
> the face index or name, freetype defaults to the first face in a font  
> file. (I thought I made a feature request for this, but I don't see  
> it in either tracker)  There is no guarantee that plain/regular will  
> be the first face in a font file, so you may get italic or bold or  
> other unexpected style.

Regarding both cases (mkftcap and R_font()), fixes are welcome. They
will need to come from someone who can devise (and test) a solution,
though (i.e. someone with a Mac).

> A few more comments:
> 
> - Add /System/Library/Fonts to the search paths (assuming some way to  
> handle other file extensions, or lack of, is worked out, as well as  
> multiple faces in a file).

> $HOME/Library/Fonts would be another good default dir to search.  And  
> to do these in the proper OSX order of precedence would be: $HOME/ 
> Library/Fonts /Library/Fonts /System/Library/Fonts.  $HOME can have  
> spaces if it's on a network driver, so that path at least should be  
> quoted.

These are easy enough to do (adding the directory, not the other
parts). Even if it doesn't do anything yet because there are no .ttf
files there, it's harmless.

> - Maybe Michael's proposed font path env var could be used here?  For  
> additional user font paths to search automatically.

I can add "$@" to the list used by mkftcap, so other directories can
be passed as arguments. Environment variables are problematic when
directories contain spaces, but command-line arguments can be quoted.

> - since this is now in /tools and installed in etc/, that implies  
> that mkftcap will get run automatically somehow?  From GUI?  Or some  
> future script module?  On startup?

At present, it gets run at build time; thereafter, it has to be run
manually. It could be run from a post-install script used by the
packaging system (.deb, .rpm, etc).

It isn't intended to be run automatically during normal use.

> Then it will destroy a user's  
> manually created freetypecap, so it should be as thorough as  
> possible.  Or add some sort of divider in the freetypecap between  
> user entries and auto-generated entries, and mkftcap would not  
> overwrite user edits.

Reasonable enough. Also, I'm considering making it write to stdout
rather than $GISBASE/etc/freetypecap. That allows it to write to some
other file, which can then be referenced by $GRASS_FT_CAP.

Also for preserving user additions, you could use e.g.:

	mkftcap > freetypecap.new
	cat freetypecap.new $GISBASE/etc/freetypecap | sort | uniq > freetypecap.tmp
	mv -f freetypecap.tmp $GISBASE/etc/freetypecap

This won't preserve deletion or re-ordering, but it's trivial to
implement. If the user has a local $GRASS_FT_CAP, an alternative is:

	mkftcap > freetypecap.new
	diff -u $GISBASE/etc/freetypecap freetypecap.new | patch $GRASS_FT_CAP
	rm -f freetypecap.new

> - regenerating the freetypecap at runtime in the GRASS application  
> folder is not a good thing on OSX (see my previous discussions about  
> OSX apps and user preference/config/addon files).  There should be  
> some way to have GRASS look for alternative external freetypecap  
> files, for both generating the freetypecap file, and reading it to  
> set the font.

The code which reads the file already uses $GRASS_FT_CAP if that is
set.

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