Normally, Mac OS X fonts live in /Library/Fonts. Is there a ‘normal’ place for fonts under Linux and Windows?
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
Normally, Mac OS X fonts live in /Library/Fonts. Is there a Œnormal¹ place
for fonts under Linux and Windows?
On Linux, they're usually in subdirectories of /usr/lib/X11/fonts
and/or /usr/share/fonts, but there are no guarantees (/usr/lib/X11 is
often a symlink to /usr/X11R6/lib/X11). It's possible that some
systems might use /etc/X11/fonts (much of what historically lived in
/usr/lib/X11 has migrated to /etc/X11 in recent years).
On Windows, they're typically in %WINDIR%\Fonts, where %WINDIR% is
typically (but not always) C:\WINDOWS. Actually, I'm not sure whether
%WINDIR% or %SYSTEMROOT% are the "right" choice; both refer to
C:\WINDOWS on my system.
--
Glynn Clements <glynn@gclements.plus.com>
So if I set "/usr/lib/X11/fonts" as a default starting directory for Linux
and Cygwin (if it exists) and "C:\WINDOWS\Fonts" (should I specify it like
this for GRASS under mysys?), it will start out in a place that has fonts
for many or most folks? (you can always change directories if this doesn't
work)
Michael
On 4/29/07 3:09 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Normally, Mac OS X fonts live in /Library/Fonts. Is there a �normal� place
for fonts under Linux and Windows?On Linux, they're usually in subdirectories of /usr/lib/X11/fonts
and/or /usr/share/fonts, but there are no guarantees (/usr/lib/X11 is
often a symlink to /usr/X11R6/lib/X11). It's possible that some
systems might use /etc/X11/fonts (much of what historically lived in
/usr/lib/X11 has migrated to /etc/X11 in recent years).On Windows, they're typically in %WINDIR%\Fonts, where %WINDIR% is
typically (but not always) C:\WINDOWS. Actually, I'm not sure whether
%WINDIR% or %SYSTEMROOT% are the "right" choice; both refer to
C:\WINDOWS on my system.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
>> Normally, Mac OS X fonts live in /Library/Fonts. Is there a e$(0!;e(Bnormale$(0!;e(B place
>> for fonts under Linux and Windows?
>
> On Linux, they're usually in subdirectories of /usr/lib/X11/fonts
> and/or /usr/share/fonts, but there are no guarantees (/usr/lib/X11 is
> often a symlink to /usr/X11R6/lib/X11). It's possible that some
> systems might use /etc/X11/fonts (much of what historically lived in
> /usr/lib/X11 has migrated to /etc/X11 in recent years).
>
> On Windows, they're typically in %WINDIR%\Fonts, where %WINDIR% is
> typically (but not always) C:\WINDOWS. Actually, I'm not sure whether
> %WINDIR% or %SYSTEMROOT% are the "right" choice; both refer to
> C:\WINDOWS on my system.So if I set "/usr/lib/X11/fonts" as a default starting directory for Linux
and Cygwin (if it exists) and "C:\WINDOWS\Fonts" (should I specify it like
this for GRASS under mysys?), it will start out in a place that has fonts
for many or most folks? (you can always change directories if this doesn't
work)
First, we should try to come up with a list of directories which are
viable candidates for containing fonts.
The installed freetypecap file (currently just a copy of
scripts/d.text.freetype/freetypecap) should be generated by scanning
all such directories for .ttf files.
If browsing for font files, I would suggest starting with whichever
directory has the most entries in the freetypecap file.
BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.
--
Glynn Clements <glynn@gclements.plus.com>
On 4/29/07 5:27 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Normally, Mac OS X fonts live in /Library/Fonts. Is there a
e$(0!;e(Bnormale$(0!;e(B place
for fonts under Linux and Windows?On Linux, they're usually in subdirectories of /usr/lib/X11/fonts
and/or /usr/share/fonts, but there are no guarantees (/usr/lib/X11 is
often a symlink to /usr/X11R6/lib/X11). It's possible that some
systems might use /etc/X11/fonts (much of what historically lived in
/usr/lib/X11 has migrated to /etc/X11 in recent years).On Windows, they're typically in %WINDIR%\Fonts, where %WINDIR% is
typically (but not always) C:\WINDOWS. Actually, I'm not sure whether
%WINDIR% or %SYSTEMROOT% are the "right" choice; both refer to
C:\WINDOWS on my system.So if I set "/usr/lib/X11/fonts" as a default starting directory for Linux
and Cygwin (if it exists) and "C:\WINDOWS\Fonts" (should I specify it like
this for GRASS under mysys?), it will start out in a place that has fonts
for many or most folks? (you can always change directories if this doesn't
work)First, we should try to come up with a list of directories which are
viable candidates for containing fonts.The installed freetypecap file (currently just a copy of
scripts/d.text.freetype/freetypecap) should be generated by scanning
all such directories for .ttf files.
This would solve the issue. But this also needs to be done outside the GUI.
If browsing for font files, I would suggest starting with whichever
directory has the most entries in the freetypecap file.
My freetypecap file has virtually nothing in it, only the fonts from the
x11/fonts directory. Maybe this is different for your system. If most linux
TTF end up there, then I can set the browse dialog to start there for linux
systems. I don't know about windows.
BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.
OK. Sounds good. Is $WINDIR an accessible environmental variable under
Cygwin (e.g., env(WINDIR) for TclTk and os.environ["WINDIR"] for wxPython?
If so, is this only with Cygwin, or is it available under mysys too?
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Apr 29, 2007, at 7:27 PM, Glynn Clements wrote:
First, we should try to come up with a list of directories which are
viable candidates for containing fonts.The installed freetypecap file (currently just a copy of
scripts/d.text.freetype/freetypecap) should be generated by scanning
all such directories for .ttf files.If browsing for font files, I would suggest starting with whichever
directory has the most entries in the freetypecap file.BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.
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).
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."
- Marvin
Michael Barton wrote:
> If browsing for font files, I would suggest starting with whichever
> directory has the most entries in the freetypecap file.My freetypecap file has virtually nothing in it, only the fonts from the
x11/fonts directory. Maybe this is different for your system. If most linux
TTF end up there, then I can set the browse dialog to start there for linux
systems. I don't know about windows.
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.
> BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
> converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
> is likely to have more fonts than Cygwin.OK. Sounds good. Is $WINDIR an accessible environmental variable under
Cygwin (e.g., env(WINDIR) for TclTk and os.environ["WINDIR"] for wxPython?
If so, is this only with Cygwin, or is it available under mysys too?
It should be available in all Windows-based environments, including
Cygwin, although I'm not sure if WINDIR or SYSTEMROOT is the preferred
method (they both point to C:\WINDOWS on my system).
--
Glynn Clements <glynn@gclements.plus.com>
On 4/29/07 9:29 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
If browsing for font files, I would suggest starting with whichever
directory has the most entries in the freetypecap file.My freetypecap file has virtually nothing in it, only the fonts from the
x11/fonts directory. Maybe this is different for your system. If most linux
TTF end up there, then I can set the browse dialog to start there for linux
systems. I don't know about windows.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/FontsThe 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.
I'm sure this will be useful, especially for people who just want to type in
a font name and go. I'm not quite sure how I can use it at the moment, as
I've got a file browser looking in a directory for fonts. To make use of
this in the GUI, I think I'd need to build a list control that reads the
font name from the first part of each line in the freetypecap file.
BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.
Can I specify this location for both MySys and Cygwin systems by using the
TclTk syntax...
set fontpath [file joint $WINDIR "Fonts"]
and letting it work differently for each system? Or do I need to have
set fontpath [exec cygpath -u $WINDIR/fonts]
for Cygwin (or something different) ?
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Glynn 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)
* quote "$GISBASE" on the final line as it may well have a space in it.
* regular modules shouldn't write to $GISBASE. Move the script into
$(ETC) or tools/.
* make d.text.freetype a symlink to d.text.new, not in scripts/.
(see d.paint.labels or p.out.vrml for an example)
cheers,
Hamish
Michael Barton wrote:
>>> BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
>>> converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
>>> is likely to have more fonts than Cygwin.Can I specify this location for both MySys and Cygwin systems by using the
TclTk syntax...set fontpath [file joint $WINDIR "Fonts"]
and letting it work differently for each system? Or do I need to have
set fontpath [exec cygpath -u $WINDIR/fonts]
for Cygwin (or something different) ?
AFAICT, you'll need to convert it explicitly for Cygwin:
% puts $env(WINDIR)
C:\WINDOWS
% puts [file join $env(WINDIR) Fonts]
C:\WINDOWS/Fonts
% puts [file join [exec cygpath -u $env(WINDIR)] Fonts]
/cygdrive/c/WINDOWS/Fonts
--
Glynn Clements <glynn@gclements.plus.com>
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@gclements.plus.com>
William Kyngesburye wrote:
> First, we should try to come up with a list of directories which are
> viable candidates for containing fonts.
>
> The installed freetypecap file (currently just a copy of
> scripts/d.text.freetype/freetypecap) should be generated by scanning
> all such directories for .ttf files.
>
> If browsing for font files, I would suggest starting with whichever
> directory has the most entries in the freetypecap file.
>
> BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
> converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
> is likely to have more fonts than Cygwin.
>
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.
The rest of GRASS doesn't care about filenames. If a name passed to
R_font() matches the first field of a line in the freetypecap file,
the second field is passed directly to FT_New_Face(). Also, if the
argument to R_font() begins with "/"[1] and doesn't begin with (the
expansion of) "$GISBASE/fonts/", it is treated similarly.
[1]. Er, that isn't going to work on native Windows. The line:
if (name[0] == '/')
[lib/driver/Font.c:27]
will need to be changed to something like:
#ifdef __MINGW32__
if (isalpha(name[0]) && name[1] == ':' && (name[2] == '\\' || name[2] == '/'))
#else
if (name[0] == '/')
#endif
Hmm; that still doesn't handle UNC paths.
... || (name[0] == '\\' && name[1] == '\\') || (name[0] == '/' && name[1] == '/')
This is starting to get ugly.
--
Glynn Clements <glynn@gclements.plus.com>
Thanks. I'll change accordingly.
Michael
On 4/30/07 1:02 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.Can I specify this location for both MySys and Cygwin systems by using the
TclTk syntax...set fontpath [file joint $WINDIR "Fonts"]
and letting it work differently for each system? Or do I need to have
set fontpath [exec cygpath -u $WINDIR/fonts]
for Cygwin (or something different) ?
AFAICT, you'll need to convert it explicitly for Cygwin:
% puts $env(WINDIR)
C:\WINDOWS% puts [file join $env(WINDIR) Fonts]
C:\WINDOWS/Fonts% puts [file join [exec cygpath -u $env(WINDIR)] Fonts]
/cygdrive/c/WINDOWS/Fonts
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Fixed and committed the Cygwin setting and a TclTk typo bug. Someone else
already fixed the x11/X11 issue.
Michael
On 4/30/07 1:02 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
BTW, with Cygwin, I would suggest starting with $WINDIR/Fonts,
converted to a Cygwin path, e.g. "cygpath -u $WINDIR/fonts". Windows
is likely to have more fonts than Cygwin.Can I specify this location for both MySys and Cygwin systems by using the
TclTk syntax...set fontpath [file joint $WINDIR "Fonts"]
and letting it work differently for each system? Or do I need to have
set fontpath [exec cygpath -u $WINDIR/fonts]
for Cygwin (or something different) ?
AFAICT, you'll need to convert it explicitly for Cygwin:
% puts $env(WINDIR)
C:\WINDOWS% puts [file join $env(WINDIR) Fonts]
C:\WINDOWS/Fonts% puts [file join [exec cygpath -u $env(WINDIR)] Fonts]
/cygdrive/c/WINDOWS/Fonts
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Apr 30, 2007, at 3:34 AM, Glynn Clements 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.
A few more comments:
$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.
Maybe Michael’s proposed font path env var could be used here? For additional user font paths to search automatically.
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? 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.
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.
This is a good candidate for my new G_find_etc() function. Find the first writable freetypecap in the etc paths (G_find_etc() would need to be expanded to do that).
William Kyngesburye <kyngchaosatkyngchaosdotcom>
http://www.kyngchaos.com/
Earth: “Mostly harmless”
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@gclements.plus.com>
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@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/freetypecapThis 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
Michael Barton wrote:
Are any of the fonts normally in the /Library/Fonts directory of OSX NOT
freetype?
There might be files there which aren't fonts; hopefully, any "system"
files will begin with a dot, so you could use e.g. "-iname '*'", which
won't match files which start with a dot but will match everything
else.
Would there be any problem with a non-freetype font sneaking into
freetypecap beyond it simply not displaying?
AFAICT, passing an path to a file which isn't a valid TTF file simply
results in text not being drawn.
--
Glynn Clements <glynn@gclements.plus.com>
On Apr 30, 2007, at 1:50 PM, Michael Barton wrote:
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
This is related to another font item that I hesitated to bring up since the focus has been on TT fonts - postscript and opentype (which are really just font packages for PS and TT) fonts. Sure, assuming all files are font files may be OK, and thus get all types of fonts (PS and TT). But with PS fonts, there are multiple files per font face.
On OSX there is the bitmap/suitcase that has the pre-made bitmaps for certain sizes and references to all the faces, and then each face has its own PS font file. You normally reference a suitcase font from the suitcase file and a face index or name, not the PS file (though FT may be able to do that also, I don't know). And on other platforms PS fonts are usually split into individual faces, but can also have more than one file per face - pfb/pfa, afm and possibly others.
You would have to filter out the extras or you will get a mess of duplicate or unusable fonts.
One possibility would be to test each font file found with freetype calls, but this might add more time to the startup than simply listing files, and I don't know if it could be done from a script - mkftcap might need to be a C prog.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."
- Marvin
On Apr 30, 2007, at 1:45 PM, Glynn Clements wrote:
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).
I can poke around for an OSX prog that can return type/creator info. I know there is something in the Dev tools, but someone who installs a binary GRASS may not have that. There should be something that is on all Macs that can give type/creator info...
I don't know about the C equivalents for R_font(). but it would probably involve tapping into some system frameworks, something that hasn't been done in GRASS yet, at least directly.
- 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.
If it uses a colon-separated list like other path env vars do, can't it be split that way, and then each item quoted in the loop? My shell scripting isn't very good to know.
- 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.
What about at startup time? Users may want to manage fonts in between runs of GRASS, so the available fonts can change often.
- 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.
I missed GRASS_FT_CAP - how recent is this?
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
[Trillian] What are you supposed to do WITH a maniacally depressed robot?
[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...
- HitchHiker's Guide to the Galaxy