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

[Michael Barton]

Are any of the fonts normally in the /Library/Fonts directory of OSX NOT
freetype? Would there be any problem with a non-freetype font sneaking into
freetypecap beyond it simply not displaying?

If the answer to these is generally negative, why not just grab all the
fonts from /LibraryFonts (and maybe $HOME/Library/Fonts) for freetypecap and
not worry about whether they have a .ttf extension or not.

Michael


On 4/30/07 11:45 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton