[GRASS-dev] font path question for Linux and Windows
Glynn Clements
glynn at gclements.plus.com
Mon Apr 30 04:20:30 EDT 2007
Hamish wrote:
> > > I've added scripts/d.freetypecap, which generates a freetypecap file
> > > by scanning a (hard-coded) list of directories for .ttf files. The
> > > list of directories is currently:
> > >
> > > /usr/lib/X11/fonts
> > > /usr/share/fonts
> > > /Library/Fonts
> > > $WINDIR/Fonts
> > >
> > > The script is run during the build process to generate a freetypecap
> > > file. For binary distributions, it really needs to be run after
> > > installation, to identify the fonts on the user's system.
>
> FWIW, the new script finds 61 fonts on my Debian/Sarge setup. Nice!
> The old freetypecap file copied raw from d.text.freetype has some fonts
> in it but it was totally useless as the paths and font names don't exist
> on my system.
>
> Possible improvements:
> * use `uname -s` to look for dir by platform. (see lib/init/init.sh)
That's a bit messy, and not really necessary. If any of those
directories exist on a given system, it's probably worth searching
them for fonts.
> * quote "$GISBASE" on the final line as it may well have a space in it.
Will do.
> * regular modules shouldn't write to $GISBASE. Move the script into
> $(ETC) or tools/.
I was under the impression that "tools" didn't get processed by
default, but it turns out that isn't the case.
The problem with $(ETC) is that it isn't in the path, so it's awkward
for the user to run it directly (and it won't get run any other way at
present).
But, it isn't a normal module, so it probably shouldn't be treated as
such.
> * make d.text.freetype a symlink to d.text.new, not in scripts/.
> (see d.paint.labels or p.out.vrml for an example)
Symlinks don't work on windows (MSys' "ln" just copies the file, which
will be somewhat larger than the script). Also, a script allows for
e.g. printing a warning that the module is deprecated.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list