[GRASS-dev] iconv a required dependency for using Freetype?

[Paul Kelly]

As mentioned in an earlier e-mail, I thought I'd try and see if I can get
Freetype font support working on native Windows. Came across the error
message below in lib/driver. As far as I can see it is because I don't
have iconv installed, but the section of the source is only
conditionalised on HAVE_FT2BUILD_H. I'm wondering if the bits that
reference convert_str (which presumably does translation) could safely be
conditionalised on HAVE_ICONV_H, or does anybody know if the
interdependency between Freetype and iconv goes deeper than that?

sh-2.04$ cd lib/driver
sh-2.04$ make
gcc -I/c/grass/grass6/dist.i686-pc-mingw32/include -I/c/grass/extra/include -g -
O2 -I/c/grass/extra/include -DPACKAGE=\""grasslibs"\" -I/c/grass/extra/inc
lude/freetype2 -DPACKAGE=\""grasslibs"\" -I/c/grass/grass6/dist.i686-pc-ming
w32/include \
-o OBJ.i686-pc-mingw32/text3.o -c text3.c
text3.c: In function `convert_str':
text3.c:139: error: `iconv_t' undeclared (first use in this function)
text3.c:139: error: (Each undeclared identifier is reported only once
text3.c:139: error: for each function it appears in.)
text3.c:139: error: syntax error before "cd"
text3.c:157: error: `cd' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/text3.o] Error 1

[Glynn Clements]

Post by Paul Kelly
As mentioned in an earlier e-mail, I thought I'd try and see if I can get
Freetype font support working on native Windows. Came across the error
message below in lib/driver. As far as I can see it is because I don't
have iconv installed, but the section of the source is only
conditionalised on HAVE_FT2BUILD_H. I'm wondering if the bits that
reference convert_str (which presumably does translation) could safely be
conditionalised on HAVE_ICONV_H, or does anybody know if the
interdependency between Freetype and iconv goes deeper than that?

d.text.freetype already handles the lack of iconv(); look at
convert_text() in d.text.freetype/main.c.

You just need a hard-coded conversion to UCS-2 for the case where
iconv() is unavailable. ISO-8859-1 -> UCS-2 (used by d.text.freetype)
is trivial; a built-in UTF-8 -> UCS-2 converter wouldn't be a lot of
work.

Alternatively, you could use mbstowcs() to convert according to the
current locale.

[Paul Kelly]

Post by Glynn Clements
You just need a hard-coded conversion to UCS-2 for the case where
iconv() is unavailable. ISO-8859-1 -> UCS-2 (used by d.text.freetype)
is trivial; a built-in UTF-8 -> UCS-2 converter wouldn't be a lot of
work.

Thanks for the hint - that seems to have worked out fine and I've already
committed the fix.

I've attached a diff of a few more changes I'm considering making, mostly
relating to path and filename handling for Windows compatibility in
loading fonts. Here's what I've changed so far:

lib/driver/Font.c, COM_Font_get():
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
(a) First converting all directory separator characters to '/'
(b) Doing a case-insensitive comparison

lib/driver/font2.c, read_fontmap():
* Warning message when unable to open font made clearer by specifying
the exact path it was trying to open and giving the system error message.

font_init():
* Convert directory separator characters to '/' so that the way the
directory name is stripped off works
* Strip off the ".hmp" extension if it was there. It strikes me as very
weird that I needed to do this, because without that I reall can't see how
passing the full path to one of the GRASS stroke fronts would have worked.
The full filename has to be given in the GRASS_FONT variable, otherwise
the font_exists() check in COM_Font_get() will fail, but the .hmp is never
stripped off and then it is added again in read_fontmap(), resulting in it
trying to open a file ending in ".hmp.hmp".

I haven't committed the changes yet as they're not complete. Apart from
being unsure about stripping off the .hmp extension, specifying a
font in GRASS_FONT from the freetypecap file doesn't work. I'm just
testing this from the command line on Windows, i.e. using direct
rendering as drivers don't work, and I can't see where/if the freetypecap
file is actually being read. Specifying the full path to a Freetype font
works fine, but is the freetypecap file only read when a driver process
is initialised?

[Glynn Clements]

Post by Paul Kelly
I've attached a diff of a few more changes I'm considering making, mostly
relating to path and filename handling for Windows compatibility in
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
(a) First converting all directory separator characters to '/'
(b) Doing a case-insensitive comparison

That last point is probably safe, in that you're unlikely to have
another directory which differs only in case on Unix.

Although, in this case, I'd be inclined to simply remove the option to
specify a stroke font using a full path. Personally, I doubt that this
feature would ever be used.

FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

That handles all of the different ways that you can make multiple
paths refer to the same file/directory (case sensitivity, symlinks,
hard links, mount points, use of . and .., etc).

However, I don't know whether it works on Windows, i.e. whether the
device/inode numbers are meaningful.

Post by Paul Kelly
I haven't committed the changes yet as they're not complete. Apart from
being unsure about stripping off the .hmp extension, specifying a
font in GRASS_FONT from the freetypecap file doesn't work. I'm just
testing this from the command line on Windows, i.e. using direct
rendering as drivers don't work, and I can't see where/if the freetypecap
file is actually being read. Specifying the full path to a Freetype font
works fine, but is the freetypecap file only read when a driver process
is initialised?

parse_freetypecap() is called from LIB_init(), in lib/driver/init.c.
For direct rendering, this is called from LOC_open_driver(); for a
standalone driver it's called from main().

Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

[Paul Kelly]

Post by Glynn Clements

Post by Paul Kelly
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
(a) First converting all directory separator characters to '/'
(b) Doing a case-insensitive comparison

That last point is probably safe, in that you're unlikely to have
another directory which differs only in case on Unix.
Although, in this case, I'd be inclined to simply remove the option to
specify a stroke font using a full path. Personally, I doubt that this
feature would ever be used.

I thought it might be used in the gis.m font chooser, where it opens a
file browse dialog in the $GISBASE/etc/fonts directory and after choosing
puts the full path to the stroke font into the text box in the dialog
widget. But I'm not 100% sure if it does that. Just appears to.

Post by Glynn Clements
FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

Interesting; here we are comparing the directory the fonts are stored in
rather than the font files themselves but perhaps still of use? I suppose
I could test it on Windows.

Post by Glynn Clements
That handles all of the different ways that you can make multiple
paths refer to the same file/directory (case sensitivity, symlinks,
hard links, mount points, use of . and .., etc).
However, I don't know whether it works on Windows, i.e. whether the
device/inode numbers are meaningful.

[...]

Post by Glynn Clements
parse_freetypecap() is called from LIB_init(), in lib/driver/init.c.
For direct rendering, this is called from LOC_open_driver(); for a
standalone driver it's called from main().
Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

Yes, that was it. If I use a semi-colon instead all works great - maybe we
could change mkftcap to generate a file with semi-colon separators? And
change parse_freetypecap() to handle both for backwards compatibility? Is
the last character on a line in freetypecap always a separator character?
If so that would be a quick way to check. Or could scan the first line and
whichever appeared first between : and ; use that as the separator?

It seems we're nearly there.

[Glynn Clements]

Post by Paul Kelly

Post by Glynn Clements
FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

Interesting; here we are comparing the directory the fonts are stored in
rather than the font files themselves but perhaps still of use?

Yes; in the case of COM_Font_get(), you would need to remove the last
part of the path and check whether the directory part refers to the
same device/inode as $GISBASE/fonts.

Post by Paul Kelly

Post by Glynn Clements
That handles all of the different ways that you can make multiple
paths refer to the same file/directory (case sensitivity, symlinks,
hard links, mount points, use of . and .., etc).
However, I don't know whether it works on Windows, i.e. whether the
device/inode numbers are meaningful.

[...]

Post by Glynn Clements
parse_freetypecap() is called from LIB_init(), in lib/driver/init.c.
For direct rendering, this is called from LOC_open_driver(); for a
standalone driver it's called from main().
Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

Yes, that was it. If I use a semi-colon instead all works great - maybe we
could change mkftcap to generate a file with semi-colon separators? And
change parse_freetypecap() to handle both for backwards compatibility? Is
the last character on a line in freetypecap always a separator character?
If so that would be a quick way to check. Or could scan the first line and
whichever appeared first between : and ; use that as the separator?

If it's going to be changed, one option is to use a vertical bar
(which isn't a legal filename character on Windows), and make the face
index a separate column.

That would eliminate the possibility of using a non-zero index when
specifying a font by a pathname, but that's problematic for other
reasons (e.g. gisprompt = "old_file,..." should probably check for
file existence, which would rule out the option of using something
which is "almost" a filename).

AFAIK, the trailing separator is an artifact of the time that style
information (colour, size) was included in the freetypecap file.

BTW, the encoding field isn't used either (d.font.freetype and
d.text.freetype used it, but the driver doesn't).

Note that d.font has code which parses the freetypecap file in order
to generate the option list for font=, and to implement the -l switch,
so that will need to be updated if the format changes.

d.font.freetype and d.text.freetype have similar code, but they no
longer need to be maintained; they have been replaced by scripts which
call d.font and d.text (which is actually d.text.new) respectively.

[Paul Kelly]

Post by Glynn Clements

Post by Paul Kelly

Post by Glynn Clements
FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

Interesting; here we are comparing the directory the fonts are stored in
rather than the font files themselves but perhaps still of use?

Yes; in the case of COM_Font_get(), you would need to remove the last
part of the path and check whether the directory part refers to the
same device/inode as $GISBASE/fonts.

OK well it doesn't work on Windows anyway. The device number corresponds
to the drive letter but it appears the inode number is always 0. So I
suppose we can just keep the string comparison of the directory names. Or
remove the option of specifying the full path to a GRASS stroke font - I
generally feel unhappy with the idea of removing functionality but maybe
it is the best option here?

Post by Glynn Clements

Post by Paul Kelly

Post by Glynn Clements
Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

Yes, that was it. If I use a semi-colon instead all works great - maybe we
could change mkftcap to generate a file with semi-colon separators? And
change parse_freetypecap() to handle both for backwards compatibility? Is
the last character on a line in freetypecap always a separator character?
If so that would be a quick way to check. Or could scan the first line and
whichever appeared first between : and ; use that as the separator?

If it's going to be changed, one option is to use a vertical bar
(which isn't a legal filename character on Windows), and make the face
index a separate column.

I can't see an easy way though of keeping old freetypecap files compatible
with the current reading code that way though - just recognising an
alternative separator character doesn't seem to be too disruptive (apart
from adding extra code and requiring it to be kept there for ever.)

Post by Glynn Clements
That would eliminate the possibility of using a non-zero index when
specifying a font by a pathname, but that's problematic for other

Yes but that's quite neat and an easy and simple way of specifying a
non-zero index if you need to, I thought.

Post by Glynn Clements
reasons (e.g. gisprompt = "old_file,..." should probably check for
file existence, which would rule out the option of using something
which is "almost" a filename).

Yes if the font was being specified through a module like d.font - I
suppose an extra parameter could be added to specify the index. But when
the font is just being read from an environment variable then it's more
complicated and anyway the parser isn't going to be involved here so as
far as I can see the check for file existence needs to be done manually
anyway as it currently is.

Post by Glynn Clements
AFAIK, the trailing separator is an artifact of the time that style
information (colour, size) was included in the freetypecap file.
BTW, the encoding field isn't used either (d.font.freetype and
d.text.freetype used it, but the driver doesn't).
Note that d.font has code which parses the freetypecap file in order
to generate the option list for font=, and to implement the -l switch,
so that will need to be updated if the format changes.
d.font.freetype and d.text.freetype have similar code, but they no
longer need to be maintained; they have been replaced by scripts which
call d.font and d.text (which is actually d.text.new) respectively.

OK. Well here is my current proposal, which can be easily added to both
d.font and libdriver: dynamically generate the format conversion string
(containing either a : or ; as separator) based on the relative position
of : and ; characters in the first line of the file that contains either
of them.
The code looks like below; it is complicated but I can't see how to make
it simpler without losing backwards compatibility. I'm not quite happy
enough with it to commit it yet. It can be easily included in both d.font
and libdriver as-is, though.

char format[16] = "";

while(fgets(buf, sizeof(buf), fp) && !feof(fp))
{
char *p;

p = strchr(buf, '#');
if(p)
*p = 0;

if (!*format)
{
char *first_colon = strchr(buf, ':');
char *first_semi = strchr(buf, ';');

if (first_colon || first_semi)
{
char sep_char;

if (first_colon == NULL)
sep_char = ';';
else if (first_semi == NULL)
sep_char = ':';
else
sep_char = (first_colon < first_semi)? ':' : ';';

sprintf(format, "%%[^%c]%c%%[^%c]", sep_char, sep_char, sep_char);
}
else
continue;
}

if(sscanf(buf, format, iname, ipath) != 2)
continue;

[Glynn Clements]

Post by Paul Kelly

Post by Glynn Clements

Post by Paul Kelly

Post by Glynn Clements
FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

Interesting; here we are comparing the directory the fonts are stored in
rather than the font files themselves but perhaps still of use?

Yes; in the case of COM_Font_get(), you would need to remove the last
part of the path and check whether the directory part refers to the
same device/inode as $GISBASE/fonts.

OK well it doesn't work on Windows anyway. The device number corresponds
to the drive letter but it appears the inode number is always 0. So I
suppose we can just keep the string comparison of the directory names. Or
remove the option of specifying the full path to a GRASS stroke font - I
generally feel unhappy with the idea of removing functionality but maybe
it is the best option here?

I think so.

Allowing a full path is exposing an implementation detail, it isn't
sufficient for files containing multiple faces, and it may cause
problems with future development.

I would rather just have fonts selected by an abstract identifier.

Post by Paul Kelly

Post by Glynn Clements

Post by Paul Kelly

Post by Glynn Clements
Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

Yes, that was it. If I use a semi-colon instead all works great - maybe we
could change mkftcap to generate a file with semi-colon separators? And
change parse_freetypecap() to handle both for backwards compatibility? Is
the last character on a line in freetypecap always a separator character?
If so that would be a quick way to check. Or could scan the first line and
whichever appeared first between : and ; use that as the separator?

If it's going to be changed, one option is to use a vertical bar
(which isn't a legal filename character on Windows), and make the face
index a separate column.

I can't see an easy way though of keeping old freetypecap files compatible
with the current reading code that way though - just recognising an
alternative separator character doesn't seem to be too disruptive (apart
from adding extra code and requiring it to be kept there for ever.)

I don't think that maintaining compatibility is all that important.
The original freetypecap format is something which Huidae made up on
the spot. It's already lost the colour/size fields, and the encoding
field isn't actually used.

Post by Paul Kelly

Post by Glynn Clements
That would eliminate the possibility of using a non-zero index when
specifying a font by a pathname, but that's problematic for other

Yes but that's quite neat and an easy and simple way of specifying a
non-zero index if you need to, I thought.

Post by Glynn Clements
reasons (e.g. gisprompt = "old_file,..." should probably check for
file existence, which would rule out the option of using something
which is "almost" a filename).

Yes if the font was being specified through a module like d.font - I
suppose an extra parameter could be added to specify the index. But when
the font is just being read from an environment variable then it's more
complicated and anyway the parser isn't going to be involved here so as
far as I can see the check for file existence needs to be done manually
anyway as it currently is.

Yes, but we should be able to use a generic file existence check,
without having to worry about hacks. When I was implementing the face
index hack, it took several iterations to get it right (either
forgetting to strip the index for the check, or inadvertantly using
the stripped version when the index was needed). My suspicion is that
the index hack will bite people continuously so long as it's around.

Post by Paul Kelly

Post by Glynn Clements
AFAIK, the trailing separator is an artifact of the time that style
information (colour, size) was included in the freetypecap file.
BTW, the encoding field isn't used either (d.font.freetype and
d.text.freetype used it, but the driver doesn't).
Note that d.font has code which parses the freetypecap file in order
to generate the option list for font=, and to implement the -l switch,
so that will need to be updated if the format changes.
d.font.freetype and d.text.freetype have similar code, but they no
longer need to be maintained; they have been replaced by scripts which
call d.font and d.text (which is actually d.text.new) respectively.

OK. Well here is my current proposal, which can be easily added to both
d.font and libdriver: dynamically generate the format conversion string
(containing either a : or ; as separator) based on the relative position
of : and ; characters in the first line of the file that contains either
of them.
The code looks like below; it is complicated but I can't see how to make
it simpler without losing backwards compatibility. I'm not quite happy
enough with it to commit it yet. It can be easily included in both d.font
and libdriver as-is, though.

Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

[Paul Kelly]

Post by Glynn Clements
Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

So what about having a totally new file, let's call it fontcap - different
name to make it clear there is no backwards compatiblity. It could include
the stroke fonts as well as freetype-compatible fonts, with a field to
indicate whether the font is stroke or freetype, also absolute filename,
index within the file, perhaps a field for a descriptive/long name too.

I wonder if something like this is what Michael had in mind when we
started this whole discussion - a simple list of all the avaiable fonts
that could be offered to the user to choose from through the GUI?

It would be generated automatically on compilation/installation and then
the user could further edit it to add to / strip it down if required.
Wolf said he was interested in writing something to automatically extract
information from font files on the system - maybe what he comes up with
can be used to generate this fontcap file. And then once we're finished
GRASS_FONT can only contain a font id string from this file - nothing else
is accepted. Does that sound like it might be workable?

[Glynn Clements]

Post by Paul Kelly

Post by Glynn Clements
Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

So what about having a totally new file, let's call it fontcap - different
name to make it clear there is no backwards compatiblity. It could include
the stroke fonts as well as freetype-compatible fonts, with a field to
indicate whether the font is stroke or freetype, also absolute filename,
index within the file, perhaps a field for a descriptive/long name too.

Sounds reasonable.

Also, built-in PostScript fonts (for the PS driver) might also be
added at some point (although R_get_text_box() will have to be fudged
in that case).

Post by Paul Kelly
I wonder if something like this is what Michael had in mind when we
started this whole discussion - a simple list of all the avaiable fonts
that could be offered to the user to choose from through the GUI?

You can get that from "d.font -l".

Although, ultimately the raster API should be extended with e.g.
R_list_fonts(); that would eliminate the possibility of mismatch
between the driver's view of which fonts are available and the
client's. In particular, built-in PostScript fonts would only be
available through the PS driver.

Regarding that last point, it should be possible to have multiple
fonts with the same name but different types, e.g. both FreeType and
PostScript versions of Helvetica. The X/PNG drivers would use the
libfreetype rasteriser with the TTF/Type1 file, while the PS driver
would just use "/Helvetica findfont ...".

Post by Paul Kelly
It would be generated automatically on compilation/installation and then
the user could further edit it to add to / strip it down if required.
Wolf said he was interested in writing something to automatically extract
information from font files on the system - maybe what he comes up with
can be used to generate this fontcap file. And then once we're finished
GRASS_FONT can only contain a font id string from this file - nothing else
is accepted. Does that sound like it might be workable?

Yes.

[Jerry Nelson]

Would fontlist be a more intuitive name to use?

-----Original Message-----
From: grass-dev-***@grass.itc.it [mailto:grass-dev-***@grass.itc.it]
On Behalf Of Glynn Clements
Sent: Monday, May 07, 2007 11:30 AM
To: Paul Kelly
Cc: grass-***@grass.itc.it
Subject: Re: [GRASS-dev] iconv a required dependency for using Freetype?

Post by Paul Kelly

Post by Glynn Clements
Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

So what about having a totally new file, let's call it fontcap - different
name to make it clear there is no backwards compatiblity. It could include
the stroke fonts as well as freetype-compatible fonts, with a field to
indicate whether the font is stroke or freetype, also absolute filename,
index within the file, perhaps a field for a descriptive/long name too.

Sounds reasonable.

Also, built-in PostScript fonts (for the PS driver) might also be
added at some point (although R_get_text_box() will have to be fudged
in that case).

Post by Paul Kelly
I wonder if something like this is what Michael had in mind when we
started this whole discussion - a simple list of all the avaiable fonts
that could be offered to the user to choose from through the GUI?

You can get that from "d.font -l".

Although, ultimately the raster API should be extended with e.g.
R_list_fonts(); that would eliminate the possibility of mismatch
between the driver's view of which fonts are available and the
client's. In particular, built-in PostScript fonts would only be
available through the PS driver.

Regarding that last point, it should be possible to have multiple
fonts with the same name but different types, e.g. both FreeType and
PostScript versions of Helvetica. The X/PNG drivers would use the
libfreetype rasteriser with the TTF/Type1 file, while the PS driver
would just use "/Helvetica findfont ...".

Post by Paul Kelly
It would be generated automatically on compilation/installation and then
the user could further edit it to add to / strip it down if required.
Wolf said he was interested in writing something to automatically extract
information from font files on the system - maybe what he comes up with
can be used to generate this fontcap file. And then once we're finished
GRASS_FONT can only contain a font id string from this file - nothing else
is accepted. Does that sound like it might be workable?

Yes.

[Paul Kelly]

Post by Jerry Nelson
Would fontlist be a more intuitive name to use?

I think "cap" is short for capabilities, i.e. you are showing the
"capabilites" of all the fonts - although TBH it is really just a list.
As far as I can think the name is more relevant for monitorcap - monitor
capabilities, but *cap is just kind of a Unix convention for those sorts
of file I think. fontlist sounds OK too though.

Paul

[Glynn Clements]

Post by Glynn Clements

Post by Paul Kelly
I wonder if something like this is what Michael had in mind when we
started this whole discussion - a simple list of all the avaiable fonts
that could be offered to the user to choose from through the GUI?

You can get that from "d.font -l".
Although, ultimately the raster API should be extended with e.g.
R_list_fonts(); that would eliminate the possibility of mismatch
between the driver's view of which fonts are available and the
client's. In particular, built-in PostScript fonts would only be
available through the PS driver.

I've added R_font_list().

This currently returns the list of fonts from the freetypecap file;
I'm not sure whether to extend it to include the stroke fonts, or
whether those will get added to freetypecap file soon.

I've also changed "d.font -l" to use this function, so we don't have
to re-write multiple freetypecap parsers if the format changes.

Future enhancement: add an option to return complete information
rather than just the name (e.g. "d.font -L"). But I'll leave that
until things have settled down a bit.

[Paul Kelly]

Post by Glynn Clements

Post by Glynn Clements

Post by Paul Kelly
I wonder if something like this is what Michael had in mind when we
started this whole discussion - a simple list of all the avaiable fonts
that could be offered to the user to choose from through the GUI?

You can get that from "d.font -l".
Although, ultimately the raster API should be extended with e.g.
R_list_fonts(); that would eliminate the possibility of mismatch
between the driver's view of which fonts are available and the
client's. In particular, built-in PostScript fonts would only be
available through the PS driver.

I've added R_font_list().
This currently returns the list of fonts from the freetypecap file;
I'm not sure whether to extend it to include the stroke fonts, or
whether those will get added to freetypecap file soon.

They're there now in the new fontcap file.

Post by Glynn Clements
I've also changed "d.font -l" to use this function, so we don't have
to re-write multiple freetypecap parsers if the format changes.

I added a structure to hold the information in the fontcap file to
general/g.mkfontcap/local_proto.h - perhaps it should go somewhere more
general to be shared with d.font. Currently it is:

struct GFONT_CAP
{
char *name; /**< Short name for this font face */
char *longname; /**< Descriptive name for the font face */
char *path; /**< Full path to the file containing this font face */
int index; /**< Index within the file of this font face */
int type; /**< Type of this font face (currently stroke or freeype) */
char *encoding; /**< Encoding to be used with this font face. */
};

#define GFONT_STROKE 0
#define GFONT_FREETYPE 1

Post by Glynn Clements
Future enhancement: add an option to return complete information
rather than just the name (e.g. "d.font -L"). But I'll leave that
until things have settled down a bit.

Yes. I suppose the GUI will need it to produce pretty output (long names)
and populate the encoding text box with a default value etc.

[Glynn Clements]

Post by Paul Kelly

Post by Glynn Clements
I've added R_font_list().
This currently returns the list of fonts from the freetypecap file;
I'm not sure whether to extend it to include the stroke fonts, or
whether those will get added to freetypecap file soon.

They're there now in the new fontcap file.

Post by Glynn Clements
I've also changed "d.font -l" to use this function, so we don't have
to re-write multiple freetypecap parsers if the format changes.

I added a structure to hold the information in the fontcap file to
general/g.mkfontcap/local_proto.h - perhaps it should go somewhere more
general to be shared with d.font.

It needs to be available to lib/driver; as the driver.h header file
isn't installed, I can only suggest graphics.h. Or into its own public
header <grass/fontcap.h> (it would need to be moved to either include
or lib/driver, so that it gets installed to $GISBASE/include before
lib/driver is compiled).

Also, can you update lib/driver/parse_ftcap.c to use the new file, and
change COM_Font_get() to use the type field (rather than the
$GISBASE/fonts heuristic) to determine stroke/freetype font.

Now that d.font no longer uses the freetypecap file, it's only
lib/driver which needs to understand the format.

[Paul Kelly]

Post by Glynn Clements

Post by Paul Kelly
I added a structure to hold the information in the fontcap file to
general/g.mkfontcap/local_proto.h - perhaps it should go somewhere more
general to be shared with d.font.

It needs to be available to lib/driver; as the driver.h header file
isn't installed, I can only suggest graphics.h. Or into its own public
header <grass/fontcap.h> (it would need to be moved to either include
or lib/driver, so that it gets installed to $GISBASE/include before
lib/driver is compiled).

I put it in include/freetypecap.h. Seemed the obvious place after a bit of
poking around.

Post by Glynn Clements
Also, can you update lib/driver/parse_ftcap.c to use the new file, and
change COM_Font_get() to use the type field (rather than the
$GISBASE/fonts heuristic) to determine stroke/freetype font.

I think I've done that successfully now. Summary from CVS commit:
* Add a trailing | to fontcap format to allow for future expansion and
make parsing easier
* Move GFONT_CAP struct to include/freetypecap.h
* Change libdriver to read the new fontcap file
* Stop tools/mkftcap generating the freetypecap file
* Change libdriver to set the encoding according to the value in fontcap

This is probably the most controversial change - not really sure what its
implications are. Is GRASS_FT_ENCODING still available to override this
when using direct rendering? I couldn't find it in the source code
anywhere although it's documented in lib/init/variables.html. In d.font
R_charset() is called after R_font() so it should override it OK. Except
in lib/driver/font_freetype.c the default is ISO-8859-1 but in the
generated fontcap file it is utf-8 - is that likely to cause any problems
or unusual behaviour? It is probably good that the encoding value in
fontcap is actually used, anyway.

* Change d.font to list only the output from R_font() and not do a
separate search for stroke fonts

Also noticed that d.font called G_gisinit() twice - I assumed this was a
bug and removed the second call (just before G_parser()).

* Fix gis.m to discard stderr from d.font as using R_font() seems to cause
it to print some PNG driver messages to stderr

The font selection box in gis.m is now not as pretty (on Windows anyway,
with the short 8-character filenames) as it only shows the short filename
and not the full descriptive font name. But this is a minor point for now.

Paul

[Glynn Clements]

Post by Paul Kelly
* Change libdriver to set the encoding according to the value in fontcap
This is probably the most controversial change - not really sure what its
implications are. Is GRASS_FT_ENCODING still available to override this
when using direct rendering?

Yes.

Post by Paul Kelly
I couldn't find it in the source code
anywhere although it's documented in lib/init/variables.html.

1. lib/raster/loc_io.c (for direct rendering)
2. display/d.mon/pgms/select.c (for standalone drivers)

Post by Paul Kelly
In d.font
R_charset() is called after R_font() so it should override it OK. Except
in lib/driver/font_freetype.c the default is ISO-8859-1 but in the
generated fontcap file it is utf-8 - is that likely to cause any problems
or unusual behaviour?

There should always be an explicit call to R_charset() before anything
else gets a chance to draw text.

Post by Paul Kelly
Also noticed that d.font called G_gisinit() twice - I assumed this was a
bug and removed the second call (just before G_parser()).

FWIW, G_gisinit() protects against multiple calls (which is good, as
the PNG/PS driver libraries call it from {PNG,PS}_Graph_set(),
although it will already have been called by the module in the direct
rendering case).

Post by Paul Kelly
* Fix gis.m to discard stderr from d.font as using R_font() seems to cause
it to print some PNG driver messages to stderr

d.font has to call R_open_driver() before it can call R_font(); with
direct rendering, R_open_driver() will run the driver's Graph_set()
function, which normally generates some stderr output.

[Hamish]

Post by Glynn Clements

Post by Paul Kelly
* Fix gis.m to discard stderr from d.font as using R_font() seems to
cause it to print some PNG driver messages to stderr

that will also mask any real warning and error messages, which isn't so
nice. Makes debugging + support much harder.

Post by Glynn Clements
d.font has to call R_open_driver() before it can call R_font(); with
direct rendering, R_open_driver() will run the driver's Graph_set()
function, which normally generates some stderr output.

G_message() or G_warning()?


if just G_message(), d.font could run G_putenv("GRASS_VERBOSE","0"); to
disable all uninteresting messages and % done but still keep G_warning()
and G_fatal_error()s.

I think
G_putenv("GRASS_VERBOSE","0");
will do the same as
G_set_verbose( G_verbose_min() );

? So better to use the latter ? Will level set with G_set_verbose()
reset when the module exits, or will it be persistent within libgis?
In that case, the former is preferred and the latter should be avoided
for general use by modules.


Hamish

[Glynn Clements]

Post by Hamish

Post by Glynn Clements

Post by Paul Kelly
* Fix gis.m to discard stderr from d.font as using R_font() seems to
cause it to print some PNG driver messages to stderr

that will also mask any real warning and error messages, which isn't so
nice. Makes debugging + support much harder.

Post by Glynn Clements
d.font has to call R_open_driver() before it can call R_font(); with
direct rendering, R_open_driver() will run the driver's Graph_set()
function, which normally generates some stderr output.

G_message() or G_warning()?

G_message():

G_message("PNG: GRASS_TRUECOLOR status: %s",
true_color ? "TRUE" : "FALSE");

G_message("PNG: collecting to file: %s,\n GRASS_WIDTH=%d, GRASS_HEIGHT=%d",
file_name, width, height);

Post by Hamish
if just G_message(), d.font could run G_putenv("GRASS_VERBOSE","0"); to
disable all uninteresting messages and % done but still keep G_warning()
and G_fatal_error()s.
I think
G_putenv("GRASS_VERBOSE","0");
will do the same as
G_set_verbose( G_verbose_min() );
? So better to use the latter ? Will level set with G_set_verbose()
reset when the module exits, or will it be persistent within libgis?
In that case, the former is preferred and the latter should be avoided
for general use by modules.

[Paul Kelly]

Post by Hamish

Post by Glynn Clements

Post by Paul Kelly
* Fix gis.m to discard stderr from d.font as using R_font() seems to
cause it to print some PNG driver messages to stderr

that will also mask any real warning and error messages, which isn't so
nice. Makes debugging + support much harder.

Post by Glynn Clements
d.font has to call R_open_driver() before it can call R_font(); with
direct rendering, R_open_driver() will run the driver's Graph_set()
function, which normally generates some stderr output.

G_message() or G_warning()?

They were just messages. And d.font --q suppresses them. Thanks for the
hint - have committed to CVS.

Paul

[Hamish]

Post by Paul Kelly
So what about having a totally new file, let's call it fontcap -
different name to make it clear there is no backwards compatiblity.
It could include the stroke fonts as well as freetype-compatible
fonts, with a field to indicate whether the font is stroke or
freetype, also absolute filename, index within the file, perhaps a
field for a descriptive/long name too.

why do the stroke fonts need to be in a *cap file at all? Their presence
is not volatile, and their only "tag" is that they are stroke fonts.
"d.font -l" already works without adding them, I fear it would just be
uneeded clutter.


?,
Hamish

[Paul Kelly]

Post by Hamish

Post by Paul Kelly
So what about having a totally new file, let's call it fontcap -
different name to make it clear there is no backwards compatiblity.
It could include the stroke fonts as well as freetype-compatible
fonts, with a field to indicate whether the font is stroke or
freetype, also absolute filename, index within the file, perhaps a
field for a descriptive/long name too.

why do the stroke fonts need to be in a *cap file at all? Their presence
is not volatile, and their only "tag" is that they are stroke fonts.
"d.font -l" already works without adding them, I fear it would just be
uneeded clutter.

I was just thinking that it would be clear to the user where all the
available fonts were coming from and that he/she (or the package
maintainer?) could re-arrange the order that stroke and freetype fonts
were listed in, or even remove some of them just by editing the
freetypecap/fontcap/fontlist file. But now I see that that conflicts with
the idea that the stroke fonts are always guaranteed to be there in every
GRASS installation, so perhaps that's not a good idea after all.

Another point is that currently if a specified font is not an absolute
path and can't be found in freetypecap, the driver code assumes it is a
stroke font and goes looking for it in the $GISBASE/fonts directory. If
all font names had to be in the font list file it would enable clearer
error reporting - "xxxx not found in font list file" rather than failing
at a later stage with "can't open file $GISBASE/fonts/xxxx.hmp".

Well that was my reasoning anyway but I see it's not a clearcut decision.

Paul

[Glynn Clements]

Post by Hamish

Post by Paul Kelly
So what about having a totally new file, let's call it fontcap -
different name to make it clear there is no backwards compatiblity.
It could include the stroke fonts as well as freetype-compatible
fonts, with a field to indicate whether the font is stroke or
freetype, also absolute filename, index within the file, perhaps a
field for a descriptive/long name too.

why do the stroke fonts need to be in a *cap file at all? Their presence
is not volatile, and their only "tag" is that they are stroke fonts.
"d.font -l" already works without adding them, I fear it would just be
uneeded clutter.

Because having a way to list all fonts would be simpler than having to
list each type of font separately then merge the results.

Also, it would allow the user to remove fonts which they will never
use from the list and/or change the ordering.

[Hamish]

Post by Glynn Clements
I don't think that maintaining compatibility is all that important.
The original freetypecap format is something which Huidae made up on
the spot.

more over, it contained hardcoded values and paths with no actual
relevance to the local machine. (the given font dir didn't exist in
Debian)

Post by Glynn Clements
and the encoding field isn't actually used.

then lets remove it before we get bug reports about it not working.

[...]

Post by Glynn Clements
Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

The ability to select TTF fonts by absolute path is a nice foolproof
feature. It doesn't depend on every one of the intermediary layers
working 100% to succeed. (e.g. freefontcap created on a binary
packager's system which has a different font set to the user's)


Hamish

[Glynn Clements]

Post by Hamish

Post by Glynn Clements
I don't think that maintaining compatibility is all that important.
The original freetypecap format is something which Huidae made up on
the spot.

more over, it contained hardcoded values and paths with no actual
relevance to the local machine. (the given font dir didn't exist in
Debian)

Post by Glynn Clements
and the encoding field isn't actually used.

then lets remove it before we get bug reports about it not working.

Or use it.

AFAICT, anything which sets both a font and an encoding always sets
the font first. If something only sets the font, using the encoding
from the freetypecap file is probably a better choice than retaining
the previous encoding.

[Hamish]

So I suppose we can just keep the string comparison of the directory
names. Or remove the option of specifying the full path to a GRASS
stroke font - I generally feel unhappy with the idea of removing
functionality but maybe it is the best option here?

IIUC the ability to specify a stroke font (romans, et al) by path name
has only been in the Tcl GUI for about a week, and even then the path
and extension are stripped away in order to use it. No functionality
will be lost.


Hamish

[Paul Kelly]

Post by Glynn Clements

Post by Paul Kelly
I've attached a diff of a few more changes I'm considering making, mostly
relating to path and filename handling for Windows compatibility in
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
(a) First converting all directory separator characters to '/'
(b) Doing a case-insensitive comparison

That last point is probably safe, in that you're unlikely to have
another directory which differs only in case on Unix.
Although, in this case, I'd be inclined to simply remove the option to
specify a stroke font using a full path. Personally, I doubt that this
feature would ever be used.

I've done that now. Discovered that gis.m doesn't rely on this and strips
the path itself, so it should be safe. And removes a lot of ugly code too
which is good. So if an absolute path is supplied, it assumes it's a
Freetype-compatible font. An interim solution, but one which (along with
the new G_is_absolute_path() function) gets font selection working
on Windows.

Paul

[Michael Barton]

...

Post by Glynn Clements

Post by Paul Kelly
OK well it doesn't work on Windows anyway. The device number corresponds
to the drive letter but it appears the inode number is always 0. So I
suppose we can just keep the string comparison of the directory names. Or
remove the option of specifying the full path to a GRASS stroke font - I
generally feel unhappy with the idea of removing functionality but maybe
it is the best option here?

I think so.
Allowing a full path is exposing an implementation detail, it isn't
sufficient for files containing multiple faces, and it may cause
problems with future development.
I would rather just have fonts selected by an abstract identifier.

Could this be the kind of font specification used in native font selection
dialogs for wxPython and TclTk? They *appear* to be quite similar in the way
they specify fonts. But I still have found no way to get back to original
font files from these specifications, suggesting that it happens somewhere
at the system level. If we could somehow tap into that, it could ultimately
make life easier for cross-platform font selection.

...

Post by Glynn Clements

Post by Paul Kelly
OK. Well here is my current proposal, which can be easily added to both
d.font and libdriver: dynamically generate the format conversion string
(containing either a : or ; as separator) based on the relative position
of : and ; characters in the first line of the file that contains either
of them.
The code looks like below; it is complicated but I can't see how to make
it simpler without losing backwards compatibility. I'm not quite happy
enough with it to commit it yet. It can be easily included in both d.font
and libdriver as-is, though.

Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

Then I'm not going to worry about implementing a different way of selecting
fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
now, so I'll leave well enough alone until this gets sorted out further.

But it *is* really nice to see this discussion over improvements in how to
specify display fonts in GRASS. It makes an enormous impact on the
professional look of GRASS output, not to mention its readability in
presentations. Thanks much guys.

Michael

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

Post by Glynn Clements

Post by Paul Kelly
OK well it doesn't work on Windows anyway. The device number corresponds
to the drive letter but it appears the inode number is always 0. So I
suppose we can just keep the string comparison of the directory names. Or
remove the option of specifying the full path to a GRASS stroke font - I
generally feel unhappy with the idea of removing functionality but maybe
it is the best option here?

I think so.
Allowing a full path is exposing an implementation detail, it isn't
sufficient for files containing multiple faces, and it may cause
problems with future development.
I would rather just have fonts selected by an abstract identifier.

Could this be the kind of font specification used in native font selection
dialogs for wxPython and TclTk? They *appear* to be quite similar in the way
they specify fonts. But I still have found no way to get back to original
font files from these specifications, suggesting that it happens somewhere
at the system level. If we could somehow tap into that, it could ultimately
make life easier for cross-platform font selection.

It cannot be done.

Just because a program can get a list of fonts, get information about
those fonts, and even draw text using those fonts, that doesn't mean
that it can actually access the underlying files (if there are any).

An X application can ask the X server for a list of fonts (XListFonts,
XListFontsWithInfo), can obtain information about a font (XQueryFont,
XGetFontProperty), and can tell the X server to use a specific font
for drawing text (XSetFont, XChangeGC).

It cannot, however, obtain either the raw contents of the underlying
file or it's path (not that it would be much use, given that it may
not have access to the filesystem of the system on which the X server
is running). Even the X server may not have that access if it's
getting its fonts from a font server.

There may not even *be* any underlying files. A font server can
manufacture glyphs on the fly, e.g. automatically generating bold
and/or oblique versions of a font, generating outlines from strokes,
bitmaps from outlines, etc.

IOW, any list of fonts which you can get from X is only useful insofar
as you can pass the name to XLoadFont() etc.

[Paul Kelly]

Post by Michael Barton
Then I'm not going to worry about implementing a different way of selecting
fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
now, so I'll leave well enough alone until this gets sorted out further.

If we remove the ability to set a Freetype-compatible font through the
GRASS_FONT env var by specifying it's full filename, then it will no
longer work though. Just thinking - I don't see any reason why the font
selection dialog can not just take the list of font options from
"d.font -l" and present this list in a drop down selection box to the
user. It includes the stroke fonts and the Truetype etc. fonts available
in freetypecap (or wherever they will be listed in the future), all in one
list.

I was thinking perhaps you didn't want to have to rely on users having
updated their freetypecap file with fonts on the system, and that is why
you've offered the possiblity of choosing Freetype-compatible fonts
directly from the directory most of them are typically stored in on the
platform gis.m is running on? That would seem to be no longer relevant now
that the freetypecap file (and in future, its replacement) are
automatically generated to contain the fonts available on the system, i.e.
the list from "d.font -l" is now more reliable as an indicator of all
possible font choices - and simplifies things too as it doesn't need a
separate choice/browsing mode for stroke and freetype fonts.

In that sense, using the d.font -l output directly will be I suppose more
future-proof (I'm thinking of the new Python GUI too) than parsing
freetypecap directly.

Paul

[Michael Barton]

Actually, I am trying to avoid having to do any more than I need to, to the
TclTk GUI so that I can focus my time on the wxPython development.

Interactive selection of display fonts seemed an important enough function
to add for a relatively small investment in time. But I'm mostly trying to
fix problems and leave new features to wxPython.

So it's more a matter of having to rebuild the widgets from a fairly easy
file selection dialog to a little more complicated listbox. But if this is
what is needed to avoid future breakage, I can try to do this.

Michael

Post by Paul Kelly

Post by Michael Barton
Then I'm not going to worry about implementing a different way of selecting
fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
now, so I'll leave well enough alone until this gets sorted out further.

If we remove the ability to set a Freetype-compatible font through the
GRASS_FONT env var by specifying it's full filename, then it will no
longer work though. Just thinking - I don't see any reason why the font
selection dialog can not just take the list of font options from
"d.font -l" and present this list in a drop down selection box to the
user. It includes the stroke fonts and the Truetype etc. fonts available
in freetypecap (or wherever they will be listed in the future), all in one
list.
I was thinking perhaps you didn't want to have to rely on users having
updated their freetypecap file with fonts on the system, and that is why
you've offered the possiblity of choosing Freetype-compatible fonts
directly from the directory most of them are typically stored in on the
platform gis.m is running on? That would seem to be no longer relevant now
that the freetypecap file (and in future, its replacement) are
automatically generated to contain the fonts available on the system, i.e.
the list from "d.font -l" is now more reliable as an indicator of all
possible font choices - and simplifies things too as it doesn't need a
separate choice/browsing mode for stroke and freetype fonts.
In that sense, using the d.font -l output directly will be I suppose more
future-proof (I'm thinking of the new Python GUI too) than parsing
freetypecap directly.
Paul

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

I was afraid that you'd say something like that. Oh well.

Michael

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements

Post by Paul Kelly
OK well it doesn't work on Windows anyway. The device number corresponds
to the drive letter but it appears the inode number is always 0. So I
suppose we can just keep the string comparison of the directory names. Or
remove the option of specifying the full path to a GRASS stroke font - I
generally feel unhappy with the idea of removing functionality but maybe
it is the best option here?

I think so.
Allowing a full path is exposing an implementation detail, it isn't
sufficient for files containing multiple faces, and it may cause
problems with future development.
I would rather just have fonts selected by an abstract identifier.

Could this be the kind of font specification used in native font selection
dialogs for wxPython and TclTk? They *appear* to be quite similar in the way
they specify fonts. But I still have found no way to get back to original
font files from these specifications, suggesting that it happens somewhere
at the system level. If we could somehow tap into that, it could ultimately
make life easier for cross-platform font selection.

It cannot be done.
Just because a program can get a list of fonts, get information about
those fonts, and even draw text using those fonts, that doesn't mean
that it can actually access the underlying files (if there are any).
An X application can ask the X server for a list of fonts (XListFonts,
XListFontsWithInfo), can obtain information about a font (XQueryFont,
XGetFontProperty), and can tell the X server to use a specific font
for drawing text (XSetFont, XChangeGC).
It cannot, however, obtain either the raw contents of the underlying
file or it's path (not that it would be much use, given that it may
not have access to the filesystem of the system on which the X server
is running). Even the X server may not have that access if it's
getting its fonts from a font server.
There may not even *be* any underlying files. A font server can
manufacture glyphs on the fly, e.g. automatically generating bold
and/or oblique versions of a font, generating outlines from strokes,
bitmaps from outlines, etc.
IOW, any list of fonts which you can get from X is only useful insofar
as you can pass the name to XLoadFont() etc.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

Can d.font -l get rid of duplicates and alphabetize (better if it ignored
caps)? Or will I have to do that in the GUI?

Michael

Post by Paul Kelly

Post by Michael Barton
Then I'm not going to worry about implementing a different way of selecting
fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
now, so I'll leave well enough alone until this gets sorted out further.

If we remove the ability to set a Freetype-compatible font through the
GRASS_FONT env var by specifying it's full filename, then it will no
longer work though. Just thinking - I don't see any reason why the font
selection dialog can not just take the list of font options from
"d.font -l" and present this list in a drop down selection box to the
user. It includes the stroke fonts and the Truetype etc. fonts available
in freetypecap (or wherever they will be listed in the future), all in one
list.
I was thinking perhaps you didn't want to have to rely on users having
updated their freetypecap file with fonts on the system, and that is why
you've offered the possiblity of choosing Freetype-compatible fonts
directly from the directory most of them are typically stored in on the
platform gis.m is running on? That would seem to be no longer relevant now
that the freetypecap file (and in future, its replacement) are
automatically generated to contain the fonts available on the system, i.e.
the list from "d.font -l" is now more reliable as an indicator of all
possible font choices - and simplifies things too as it doesn't need a
separate choice/browsing mode for stroke and freetype fonts.
In that sense, using the d.font -l output directly will be I suppose more
future-proof (I'm thinking of the new Python GUI too) than parsing
freetypecap directly.
Paul

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Paul Kelly]

Post by Michael Barton
Can d.font -l get rid of duplicates and alphabetize (better if it ignored
caps)? Or will I have to do that in the GUI?

I think that is better handled at the time the font list file is
generated. So the answer is no, but when we get this sorted out it won't
need to. So I guess no need to rush into any changes right now.

Paul

[Glynn Clements]

Post by Paul Kelly

Post by Michael Barton
Can d.font -l get rid of duplicates and alphabetize (better if it ignored
caps)? Or will I have to do that in the GUI?

I think that is better handled at the time the font list file is
generated.

Agreed.

Ideally, mkftcap would unique-ify duplicate names, although this isn't
easy to do in a shell script.

I'm not so sure that either mkftcap, "d.font -l" or the GUI should
sort the overall list. It may be better if mkftcap grouped fonts
according to the directory in which they reside, in which case, both
"d.font -l" and the GUI should preserve that ordering. Ditto if the
user manually re-orders the entries.

[Hamish]

Post by Glynn Clements

Post by Paul Kelly

Post by Michael Barton
Can d.font -l get rid of duplicates and alphabetize (better if it
ignored caps)? Or will I have to do that in the GUI?

I think that is better handled at the time the font list file is
generated.

Agreed.
Ideally, mkftcap would unique-ify duplicate names, although this isn't
easy to do in a shell script.
I'm not so sure that either mkftcap, "d.font -l" or the GUI should
sort the overall list. It may be better if mkftcap grouped fonts
according to the directory in which they reside, in which case, both
"d.font -l" and the GUI should preserve that ordering. Ditto if the
user manually re-orders the entries.

If mixing stroke fonts and TTF fonts in the same list, sorting them by
name alone would be a pain. I'd rather see the stroke fonts grouped
together, at either the top or the bottom of the list.


Hamish

[Michael Barton]

Just because fonts come from different directories, that doesn't mean that
there is some significance to the grouping. Might be and might not be. Also,
I don't know how to get rid of duplicates unless I sort first. Standard font
dialogs always sort by name. In wxPython, you can start typing the name and
it will automatically scroll to the font.

Michael

Post by Glynn Clements

Post by Paul Kelly

Post by Michael Barton
Can d.font -l get rid of duplicates and alphabetize (better if it ignored
caps)? Or will I have to do that in the GUI?

I think that is better handled at the time the font list file is
generated.

Agreed.
Ideally, mkftcap would unique-ify duplicate names, although this isn't
easy to do in a shell script.
I'm not so sure that either mkftcap, "d.font -l" or the GUI should
sort the overall list. It may be better if mkftcap grouped fonts
according to the directory in which they reside, in which case, both
"d.font -l" and the GUI should preserve that ordering. Ditto if the
user manually re-orders the entries.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

While I can see the value in this, actually doing it would be a real pain. I
have to sort to remove duplicates. Trying to reorganize the list again by
pulling out the stroke fonts and moving into a group is not easy. Sorry.

Michael

Post by Hamish

Post by Glynn Clements

Post by Paul Kelly

Post by Michael Barton
Can d.font -l get rid of duplicates and alphabetize (better if it
ignored caps)? Or will I have to do that in the GUI?

I think that is better handled at the time the font list file is
generated.

Agreed.
Ideally, mkftcap would unique-ify duplicate names, although this isn't
easy to do in a shell script.
I'm not so sure that either mkftcap, "d.font -l" or the GUI should
sort the overall list. It may be better if mkftcap grouped fonts
according to the directory in which they reside, in which case, both
"d.font -l" and the GUI should preserve that ordering. Ditto if the
user manually re-orders the entries.

If mixing stroke fonts and TTF fonts in the same list, sorting them by
name alone would be a pain. I'd rather see the stroke fonts grouped
together, at either the top or the bottom of the list.
Hamish

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Hamish]

Hamish

Post by Hamish
If mixing stroke fonts and TTF fonts in the same list, sorting them by
name alone would be a pain. I'd rather see the stroke fonts grouped
together, at either the top or the bottom of the list.
While I can see the value in this, actually doing it would be a real
pain. I have to sort to remove duplicates. Trying to reorganize the
list again by pulling out the stroke fonts and moving into a group is
not easy. Sorry.

so wait to add them until after your sort|uniq?

note the last act of tools/mkftcap is "| sort | uniq", so some of this
work is already done for you. Where do the duplicates come from then?

`sort` has a number of options like --dictionary-order and --ignore-case
which, if cross-platform, could help pre-sort the freetypecap list as
needed. Also note `sort` has a --unique flag, although I am not sure if
that operates just on the --key column or the entire line. If it just
works on the key column, that would be cool, although that means
arbitrarily throwing away (perhaps better) variants.


Hamish

[Michael Barton]

In wxPython, I've switched to a scrolling listbox whose items are built from
the output of d.font -l. It seems to work fine and should work on all
platforms because it does not require a full, absolute path, but builds from
whatever is in the new freetypecap + stroke fonts.

I was planning to do the same with TclTk, since this seems the most robust
approach and likely to remain stable regardless of other font management
changes. Any reason not to do so?

Michael

Post by Paul Kelly

Post by Glynn Clements

Post by Paul Kelly
I've attached a diff of a few more changes I'm considering making, mostly
relating to path and filename handling for Windows compatibility in
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
(a) First converting all directory separator characters to '/'
(b) Doing a case-insensitive comparison

That last point is probably safe, in that you're unlikely to have
another directory which differs only in case on Unix.
Although, in this case, I'd be inclined to simply remove the option to
specify a stroke font using a full path. Personally, I doubt that this
feature would ever be used.

I've done that now. Discovered that gis.m doesn't rely on this and strips
the path itself, so it should be safe. And removes a lot of ugly code too
which is good. So if an absolute path is supplied, it assumes it's a
Freetype-compatible font. An interim solution, but one which (along with
the new G_is_absolute_path() function) gets font selection working
on Windows.
Paul

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Paul Kelly]

Post by Michael Barton
In wxPython, I've switched to a scrolling listbox whose items are built from
the output of d.font -l. It seems to work fine and should work on all
platforms because it does not require a full, absolute path, but builds from
whatever is in the new freetypecap + stroke fonts.
I was planning to do the same with TclTk, since this seems the most robust
approach and likely to remain stable regardless of other font management
changes. Any reason not to do so?

Only that it won't (yet) work on Windows because the current freetypecap
file format is incompatible with Windows pathnames - but that is an almost
irrelevant point seeing the current setup has only been working on Windows
for about 10 hours anyway - unlikely anybody's relying on it! Having it
broken again for a short while until we re-do the font file and d.font -l
to use it is not a problem. If you can do it easily I'd say go for it.

Paul

[Michael Barton]

Post by Hamish
Hamish

Post by Hamish
If mixing stroke fonts and TTF fonts in the same list, sorting them by
name alone would be a pain. I'd rather see the stroke fonts grouped
together, at either the top or the bottom of the list.
While I can see the value in this, actually doing it would be a real
pain. I have to sort to remove duplicates. Trying to reorganize the
list again by pulling out the stroke fonts and moving into a group is
not easy. Sorry.

so wait to add them until after your sort|uniq?

The idea is to get them from d.font -l, rather than parse the actual
freetypecap file and etc/fonts directory directly. d.font -l lists stroke
fonts and freetype fonts all in a single list.

Post by Hamish
note the last act of tools/mkftcap is "| sort | uniq", so some of this
work is already done for you. Where do the duplicates come from then?

Same fonts in different directories. uniq sees them as different because
they have different paths, in spite of being the same font.

Michael

Post by Hamish
`sort` has a number of options like --dictionary-order and --ignore-case
which, if cross-platform, could help pre-sort the freetypecap list as
needed. Also note `sort` has a --unique flag, although I am not sure if
that operates just on the --key column or the entire line. If it just
works on the key column, that would be cool, although that means
arbitrarily throwing away (perhaps better) variants.
Hamish

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Hamish]

Post by Michael Barton

Post by Hamish
so wait to add them until after your sort|uniq?

The idea is to get them from d.font -l, rather than parse the actual
freetypecap file and etc/fonts directory directly. d.font -l lists
stroke fonts and freetype fonts all in a single list.

if we change mkftcap to use `| sort -f` (--ignore-case) then the Tcl GUI
only has to worry about unique?

FWIW, for me the existing 'd.font -l' list order is already in a
prefered state (lower case names are all like "n019064l" [Type1], upper
case names (first) are like "Courier_New" [.ttf]). Keeping those groups
separate isn't so bad.


Are .pcf fonts usable?
most .pcf fonts on Debian are compressed by default:
/usr/X11R6/lib/X11/fonts/misc/neep-iso8859-1-05x11.pcf.gz

$ locate .pcf | grep font | grep '.gz$' | wc -l
1103

$ locate .pcf | grep font | grep -v '.gz$'
/usr/share/gnome/cursor-fonts/cursor-large-white.pcf
/usr/share/gnome/cursor-fonts/cursor-large.pcf
/usr/share/gnome/cursor-fonts/cursor-white.pcf

only 3 are not .gz! (rather large freetypecap otherwise; file for each
size, not family)
How to access those fonts?


Bug: "d.font help", "--help", does all sorts of wacky output.
same with "d.font [any string not in ftcap]".


Hamish


# ps - my current list:
G63 > d.font -l
cyrilc
gothgbt
gothgrt
gothitt
greekc
greekcs
greekp
greeks
italicc
italiccs
italict
romanc
romancs
romand
romans
romant
scriptc
scripts
Andale_Mono
Arial
Arial_Black
Arial_Bold
Arial_Bold_Italic
Arial_Italic
Comic_Sans_MS
Comic_Sans_MS_Bold
Courier_New
Courier_New_Bold
Courier_New_Bold_Italic
Courier_New_Italic
FreeMono
FreeMonoBold
FreeMonoBoldOblique
FreeMonoOblique
FreeSans
FreeSansBold
FreeSansBoldOblique
FreeSansOblique
FreeSerif
FreeSerifBold
FreeSerifBoldItalic
FreeSerifItalic
Georgia
Georgia_Bold
Georgia_Bold_Italic
Georgia_Italic
Impact
Times_New_Roman
Times_New_Roman_Bold
Times_New_Roman_Bold_Italic
Times_New_Roman_Italic
Trebuchet_MS
Trebuchet_MS_Bold
Trebuchet_MS_Bold_Italic
Trebuchet_MS_Italic
Vera
VeraBI
VeraBd
VeraIt
VeraMoBI
VeraMoBd
VeraMoIt
VeraMono
VeraSe
VeraSeBd
Verdana
Verdana_Bold
Verdana_Bold_Italic
Verdana_Italic
Webdings
a010013l
a010015l
a010033l
a010035l
b018012l
b018015l
b018032l
b018035l
c0419bt_
c0419bt_
c0582bt_
c0582bt_
c0583bt_
c0583bt_
c059013l
c059016l
c059033l
c059036l
c0611bt_
c0611bt_
c0632bt_
c0632bt_
c0633bt_
c0633bt_
c0648bt_
c0648bt_
c0649bt_
c0649bt_
cmex10
cmmi10
cmr10
cmsy10
cursor
cursor
d050000l
msam10
msbm10
n019003l
n019004l
n019023l
n019024l
n019043l
n019044l
n019063l
n019064l
n021003l
n021004l
n021023l
n021024l
n022003l
n022004l
n022023l
n022024l
opens___
p052003l
p052004l
p052023l
p052024l
s050000l
wasy10
wine_marlett
z003034l

[Glynn Clements]

Post by Michael Barton

Post by Hamish
note the last act of tools/mkftcap is "| sort | uniq", so some of this
work is already done for you. Where do the duplicates come from then?

Same fonts in different directories. uniq sees them as different because
they have different paths, in spite of being the same font.

There's no way that mkftcap can determine that they are actually the
same font.

What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

[Paul Kelly]

Post by Glynn Clements
There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

Maybe writing it in C, linking it against the Freetype library and using
the Freetype API to query information about the font files it finds would
be a good idea. Presumably it would be possible to determine if two fonts
are identical, also the information about more that one font in each file
and perhaps more descriptive names for the font that just the filename
would be available. But I don't know for sure; haven't looked at the
Freetype API.

Paul

[William Kyngesburye]

Post by Paul Kelly

Post by Glynn Clements
There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

...

Post by Paul Kelly
information about more that one font in each file

...

Wolf offered to work out this when he has time (in another thread I
started for that topic). I was thinking that it might be useful to
do a d.freetype.info module that mkftcap could use. Users might want/
need to see info about a font also.

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

[Wolf Bergenheim]

Yes, I'm still offering. Now that I only have one geostatistics report
to write I have finally some time to do other things too. Infact I think
I can start it this weekend, and I think I can have it done by the end
of next week.

So I'm thinking by default d.freetype.info should print something in a
nice human readable way, a bit like ftinfo does. And then if given a
switch -s (for script) it will output a comma separated list instead.
How does that sound?

--Wolf

Post by William Kyngesburye

Post by Paul Kelly

Post by Glynn Clements
There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

...

Post by Paul Kelly
information about more that one font in each file

...
Wolf offered to work out this when he has time (in another thread I
started for that topic). I was thinking that it might be useful to do a
d.freetype.info module that mkftcap could use. Users might want/need to
see info about a font also.
-----
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
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

[William Kyngesburye]

Looks like Paul Kelly took care of the ultimate goal - figuring out
all the face indexes and generating a fontcap/ftcap file from that info.

A command to get info on individual font files might still be handy -
a user could check a new font before manually adding it to their
fontcap file. I'd say one or two switches could be used to output
the font info in either of the fontcap/ftcap formats (when they
settle down).

Post by Wolf Bergenheim
Yes, I'm still offering. Now that I only have one geostatistics report
to write I have finally some time to do other things too. Infact I think
I can start it this weekend, and I think I can have it done by the end
of next week.
So I'm thinking by default d.freetype.info should print something in a
nice human readable way, a bit like ftinfo does. And then if given a
switch -s (for script) it will output a comma separated list instead.
How does that sound?
--Wolf

Post by William Kyngesburye
Wolf offered to work out this when he has time (in another thread I
started for that topic). I was thinking that it might be useful to do a
d.freetype.info module that mkftcap could use. Users might want/
need to
see info about a font also.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

[Wolf Bergenheim]

Yeah I just noticed. Good work Paul! So there really isn't any need
then? I mean most people can use some native way of getting information
about a font. Or do you still see a need for this?

--Wolf

Looks like Paul Kelly took care of the ultimate goal - figuring out all
the face indexes and generating a fontcap/ftcap file from that info.
A command to get info on individual font files might still be handy - a
user could check a new font before manually adding it to their fontcap
file. I'd say one or two switches could be used to output the font info
in either of the fontcap/ftcap formats (when they settle down).

Post by Wolf Bergenheim
Yes, I'm still offering. Now that I only have one geostatistics report
to write I have finally some time to do other things too. Infact I think
I can start it this weekend, and I think I can have it done by the end
of next week.
So I'm thinking by default d.freetype.info should print something in a
nice human readable way, a bit like ftinfo does. And then if given a
switch -s (for script) it will output a comma separated list instead.
How does that sound?
--Wolf

Post by William Kyngesburye
Wolf offered to work out this when he has time (in another thread I
started for that topic). I was thinking that it might be useful to do a
d.freetype.info module that mkftcap could use. Users might want/need to
see info about a font also.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
All generalizations are dangerous, even this one.
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

[Paul Kelly]

Post by Wolf Bergenheim
Yeah I just noticed. Good work Paul! So there really isn't any need
then? I mean most people can use some native way of getting information
about a font. Or do you still see a need for this?

Well Glynn mentioned extending d.font to output more detailed font
information, but I guess that will only be the information that's already
in the fontcap file. There's really no point in complicating d.font by
requiring (part of) it to be built against the Freetype library,
especially as all the intricate Freetype stuff is already in g.mkfontcap.

Maybe William's idea of some extra debug output in g.mkfontcap would be
useful, perhaps an option to add a single new font to fontcap (or provide
extra intricate Freetype details on it), that kind of thing - it could be
extended indefinitely reallly, but I agree that that functionality doesn't
really belong on GRASS, unless the operating system doesn't provide it or
its implementation is broken - which does appear to be the the case with
fc-list outputting the font index numbers at least (they were always 0
IIRC?).

Paul

Post by Wolf Bergenheim
--Wolf

Looks like Paul Kelly took care of the ultimate goal - figuring out all
the face indexes and generating a fontcap/ftcap file from that info.
A command to get info on individual font files might still be handy - a
user could check a new font before manually adding it to their fontcap
file. I'd say one or two switches could be used to output the font info
in either of the fontcap/ftcap formats (when they settle down).

Post by Wolf Bergenheim
Yes, I'm still offering. Now that I only have one geostatistics report
to write I have finally some time to do other things too. Infact I think
I can start it this weekend, and I think I can have it done by the end
of next week.
So I'm thinking by default d.freetype.info should print something in a
nice human readable way, a bit like ftinfo does. And then if given a
switch -s (for script) it will output a comma separated list instead.
How does that sound?
--Wolf

Post by William Kyngesburye
Wolf offered to work out this when he has time (in another thread I
started for that topic). I was thinking that it might be useful to do a
d.freetype.info module that mkftcap could use. Users might want/need to
see info about a font also.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
All generalizations are dangerous, even this one.
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

--
<:3 )---- Wolf Bergenheim ----( 8:>

[Paul Kelly]

Maybe writing it in C, linking it against the Freetype library and using the
Freetype API to query information about the font files it finds would be a
good idea. Presumably it would be possible to determine if two fonts are
identical, also the information about more that one font in each file and
perhaps more descriptive names for the font that just the filename would be
available. But I don't know for sure; haven't looked at the Freetype API.

I've done that now. See attached for the prototype in case anybody would
like to try it. What it does is search through all the files in the list
of directories we gathered (hard-coded in main.c). Rather than checking
the file extension it examines each file using Freetype functions to see
if it is a font or not. This should work for font files with no extension
if they exist. It should also get the multiple fonts in one file OK -
would be especially interested to see what it comes up with when run on a
Mac system.

I haven't done anything yet about finding duplicate fonts - I don't have
any on either the Windows or Linux systems I tested this on. The list is
sorted first by font type (stroke or freetype) and secondly name. I've
just gone with a fully descriptive name, including spaces for the names.
The elegant simplicity of that approach for the GUI font selection box
seems to work quite well.

The version of the program (called g.mkfontcap for now) attached can write
a file in either the current freetypecap format, or the proposed new
fontcap format, which (in order to be Windows-compatible) separates all
the fields with a vertical bar - and includes the index within each font
file and the type of font (stroke or freetype) as fields also. Hopefully
this format should be easily extendible to include PostScript fonts too?

I'm still not very sure at all about the meaning of the encoding field or
if it should be included, or even if it depends on the fonts in any way at
all and if there's any way it should be derived from freetype?

If we can decide on a name - maybe g.mkfontcap is all right? - I can
submit it to CVS for further improvements.

Paul

[William Kyngesburye]

Yeah! That's more like it. Some samples from OSX (default 'new'
style fontcap):

- resource font (and the one that's not showing up in fc-list):

Arial Bold|1|/Library/Fonts/Arial|1|utf-8
Arial Bold Italic|1|/Library/Fonts/Arial|3|utf-8
Arial Italic|1|/Library/Fonts/Arial|2|utf-8
Arial Regular|1|/Library/Fonts/Arial|0|utf-8

- dfont:

Times Bold|1|/System/Library/Fonts/Times.dfont|9|utf-8
Times Bold|1|/System/Library/Fonts/Times.dfont|1|utf-8
Times Bold|1|/System/Library/Fonts/Times.dfont|5|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|11|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|3|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|7|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|2|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|10|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|6|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|0|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|4|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|8|utf-8

Strange - almost ALL the dfonts have tripled indexes for each style.
And always alternating indexes. I'm not sure what that's all about,
but with the dulicate names, only one of the triplet will be usable.
As a test I made the names unique for the Times styles in my
freetypecap file and drew each of them - they all work. So it
appears that only the first one of each triplet is needed.


One suggestion - make it useable outside of GRASS, or during the
startup process. (I tried it and got a segfault)

This would be useful for a first-time run of GRASS when an alternate
$GRASS_FT_CAP is used, and that doesn't exist yet. Maybe default to
stdout in this case, since GISBASE might not be set.

I'm thinking of a binary install (especially OSX) that will build a
user freetypecap to use in place of the built copy in the GRASS
binary, but not overwrite the GRASS binary copy, since the user might
not have admin privileges. Maybe run it in init.sh if GRASS_FT_CAP
is set and the referenced file does not exist yet. I guess if run in
init.sh, it could be run at a point when the necessary env vars are
set...


Postscript fonts - no worries there, if FreeType supports them,
they're listed (I have a couple in my /Library/Fonts folder).


Another possible option - write to $GRASS_FT_CAP, if set. Or to a
user-supplied file path.

Post by Paul Kelly
I've done that now. See attached for the prototype in case anybody
would like to try it. What it does is search through all the files
in the list of directories we gathered (hard-coded in main.c).
Rather than checking the file extension it examines each file using
Freetype functions to see if it is a font or not. This should work
for font files with no extension if they exist. It should also get
the multiple fonts in one file OK - would be especially interested
to see what it comes up with when run on a Mac system.
I haven't done anything yet about finding duplicate fonts - I don't
have any on either the Windows or Linux systems I tested this on.
The list is sorted first by font type (stroke or freetype) and
secondly name. I've just gone with a fully descriptive name,
including spaces for the names. The elegant simplicity of that
approach for the GUI font selection box seems to work quite well.
The version of the program (called g.mkfontcap for now) attached
can write a file in either the current freetypecap format, or the
proposed new fontcap format, which (in order to be Windows-
compatible) separates all the fields with a vertical bar - and
includes the index within each font file and the type of font
(stroke or freetype) as fields also. Hopefully this format should
be easily extendible to include PostScript fonts too?
I'm still not very sure at all about the meaning of the encoding
field or if it should be included, or even if it depends on the
fonts in any way at all and if there's any way it should be derived
from freetype?
If we can decide on a name - maybe g.mkfontcap is all right? - I
can submit it to CVS for further improvements.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

[Glynn Clements]

Post by William Kyngesburye
Postscript fonts - no worries there, if FreeType supports them,
they're listed (I have a couple in my /Library/Fonts folder).

Any .pfa/.pfb files which are installed on the system are "FreeType"
fonts so far as the display architecture is concerned.

By "PostScript" fonts, I'm referring to fonts which don't necessarily
exist on the system but could be selected when using the PS driver.
These will typically be the fonts which are installed on your printer
(at least Times, Helvetica, Courier, Symbol, maybe some others).

[Paul Kelly]

I've committed a slightly changed version of this to CVS now as
g.mkfontcap. It should be compiled by default, and create the new-format
file $GISBASE/etc/fontcap automatically during the compile process.

On Wed, 9 May 2007, William Kyngesburye wrote:

[...]

Strange - almost ALL the dfonts have tripled indexes for each style. And
always alternating indexes. I'm not sure what that's all about, but with the
dulicate names, only one of the triplet will be usable. As a test I made the
names unique for the Times styles in my freetypecap file and drew each of
them - they all work. So it appears that only the first one of each triplet
is needed.

No clue what to do about this yet. With the latest change to have separate
long and short names (see below), the short names will now be different
for each variant...

One suggestion - make it useable outside of GRASS, or during the startup
process. (I tried it and got a segfault)

It calls G_no_gisinit(), i.e. it doesn't require a valid location or
mapset to be present, just GISBASE and GISRC to be set, so should be fine
for most purposes I think.

This would be useful for a first-time run of GRASS when an alternate
$GRASS_FT_CAP is used, and that doesn't exist yet. Maybe default to stdout
in this case, since GISBASE might not be set.
I'm thinking of a binary install (especially OSX) that will build a user
freetypecap to use in place of the built copy in the GRASS binary, but not
overwrite the GRASS binary copy, since the user might not have admin
privileges. Maybe run it in init.sh if GRASS_FT_CAP is set and the
referenced file does not exist yet. I guess if run in init.sh, it could be
run at a point when the necessary env vars are set...
Postscript fonts - no worries there, if FreeType supports them, they're
listed (I have a couple in my /Library/Fonts folder).
Another possible option - write to $GRASS_FT_CAP, if set. Or to a
user-supplied file path.

I've changed it so it will write to the file specified by $GRASS_FONT_CAP,
if it's set. Or $GRASS_FT_CAP if the the -f flag is used to write an old
freetypecap-compatible file. Normally it will write to
$GISBASE/etc/fontcap or to stdout if the -s flag is specified.

I also changed the fontcap format to have a shortname and a long
descriptive name. The short name is made up of the filename with any
suffix stripped, and the index number added if it is greater than 0. For
the GUI font selection box to be as pretty as possible then I guess it
will need to use the short name internally as an index key to the list,
but display the long name for the user to select.

Haven't done anything yet about specifying an encoding other than UTF-8,
or removing duplicate fonts.

Paul

[William Kyngesburye]

Post by Paul Kelly

Post by William Kyngesburye
One suggestion - make it useable outside of GRASS, or during the
startup process. (I tried it and got a segfault)

It calls G_no_gisinit(), i.e. it doesn't require a valid location
or mapset to be present, just GISBASE and GISRC to be set, so
should be fine for most purposes I think.

Doesn't help if I want to generate the *cap file before init.sh is
run, since the user hasn't selected a map yet. I thought about
trying a dummy location like the demolocation, but that would have to
be installed with the binary.

I came up with this possibility - in init.sh, after it gets a valid
mapset from the user (and all the needed vars are set):

--- init.sh-orig 2007-05-11 13:58:54.000000000 -0500
+++ init.sh 2007-05-11 13:56:38.000000000 -0500
@@ -676,6 +676,15 @@
exit 1 ;;
esac

+if [ "$GRASS_FONT_CAP" ] && [ ! -f "$GRASS_FONT_CAP" ] ; then
+ echo "Building user fontcap ..."
+ g.mkfontcap -o
+fi
+if [ "$GRASS_FT_CAP" ] && [ ! -f "$GRASS_FT_CAP" ] ; then
+ echo "Building user freetypecap ..."
+ g.mkfontcap -o -f
+fi
+
trap "" 2 3 15

# cygwin has many problems with the shell setup


This should be safe - it should not get run on the *caps installed
with the GRASS binary (though if a user sets either to be the binary
copy, it will try to), but only when either or both env vars are set
and the file doesn't exist. It will give the user a start for adding
other fonts manually, or cleaning up possible mistakes.

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

[Glynn Clements]

Post by Paul Kelly

Maybe writing it in C, linking it against the Freetype library and using the
Freetype API to query information about the font files it finds would be a
good idea. Presumably it would be possible to determine if two fonts are
identical, also the information about more that one font in each file and
perhaps more descriptive names for the font that just the filename would be
available. But I don't know for sure; haven't looked at the Freetype API.

I've done that now. See attached for the prototype in case anybody would
like to try it. What it does is search through all the files in the list
of directories we gathered (hard-coded in main.c). Rather than checking
the file extension it examines each file using Freetype functions to see
if it is a font or not. This should work for font files with no extension
if they exist. It should also get the multiple fonts in one file OK -
would be especially interested to see what it comes up with when run on a
Mac system.
I haven't done anything yet about finding duplicate fonts - I don't have
any on either the Windows or Linux systems I tested this on. The list is
sorted first by font type (stroke or freetype) and secondly name. I've
just gone with a fully descriptive name, including spaces for the names.
The elegant simplicity of that approach for the GUI font selection box
seems to work quite well.

We need a short name for command-line use.

Post by Paul Kelly
The version of the program (called g.mkfontcap for now) attached can write
a file in either the current freetypecap format, or the proposed new
fontcap format, which (in order to be Windows-compatible) separates all
the fields with a vertical bar - and includes the index within each font
file and the type of font (stroke or freetype) as fields also. Hopefully
this format should be easily extendible to include PostScript fonts too?
I'm still not very sure at all about the meaning of the encoding field or
if it should be included, or even if it depends on the fonts in any way at
all and if there's any way it should be derived from freetype?

It's a convenience.

Most fonts will cover a particular character set (repertoire), and
character sets tend to be associated with specific encodings. E.g. for
a font which covers the Latin1 set, text is likely to be in ASCII,
ISO-8859-1 (or -15) or maybe UTF-8, while Japanese will probably use
Shift-JIS, EUC-JP or maybe some form of ISO-2022.

The encoding field is meant to avoid having to explicitly specify the
encoding in the most common cases.

You can't reliably determine this automatically from the font,
although you can use certain heuristics based upon the repertoire
("fc-list : charset" appers to provide something like this, so the
information must be available). But ultimately it's up to the user;
some western users will normally use ISO-8859-1, others will use
UTF-8.

The GUI needs to provide some way to set the encoding explicitly
("iconv -l" will supply a list of valid encodings), at least for text
which is read from a file. For command-line arguments, it could simply
pass the text as UTF-8 and set the encoding to that.

[Michael Barton]

Why can d.font -l be reworked to do this on the fly and dispense with
freetypecap altogether?

Michael

Post by Paul Kelly

Post by Glynn Clements
There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

Maybe writing it in C, linking it against the Freetype library and using
the Freetype API to query information about the font files it finds would
be a good idea. Presumably it would be possible to determine if two fonts
are identical, also the information about more that one font in each file
and perhaps more descriptive names for the font that just the filename
would be available. But I don't know for sure; haven't looked at the
Freetype API.
Paul

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

Post by Paul Kelly

Post by Glynn Clements
There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

Maybe writing it in C, linking it against the Freetype library and using
the Freetype API to query information about the font files it finds would
be a good idea. Presumably it would be possible to determine if two fonts
are identical, also the information about more that one font in each file
and perhaps more descriptive names for the font that just the filename
would be available. But I don't know for sure; haven't looked at the
Freetype API.

Why can d.font -l be reworked to do this on the fly and dispense with
freetypecap altogether?

If you eliminate the configuration file altogether, you eliminate the
possibility of configuration.

[Michael Barton]

I guess I'd disagree. I know that, in principal you'd be throwing away
information to remove duplicates on the basis of font face name. But there
are 2 possibilities to balance. One is the rather slim possibility that
someone would store different fonts under identical names but in different
directories. The other is the confusion of having the same font show up
multiple times (even as luxibi.1, luxibi.2, luxibi.3, for example, if a
suffix were added) making the font list even longer. I think that the second
circumstance is much more likely and the one to avoid.

Michael

Post by Glynn Clements

Post by Michael Barton

Post by Hamish
note the last act of tools/mkftcap is "| sort | uniq", so some of this
work is already done for you. Where do the duplicates come from then?

Same fonts in different directories. uniq sees them as different because
they have different paths, in spite of being the same font.

There's no way that mkftcap can determine that they are actually the
same font.
What it should do is to add a suffix to duplicate names, so that you
can select either one (at present, only the first one with any given
name can be selected). Realistically, that would require mkftcap to be
written in a real language.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

This should work automatically with the new GUI default font selection
mechanism provided that GRASS_FONT will accept the d.font -l output from
this new font list.

Michael

Post by William Kyngesburye
Yeah! That's more like it. Some samples from OSX (default 'new'
Arial Bold|1|/Library/Fonts/Arial|1|utf-8
Arial Bold Italic|1|/Library/Fonts/Arial|3|utf-8
Arial Italic|1|/Library/Fonts/Arial|2|utf-8
Arial Regular|1|/Library/Fonts/Arial|0|utf-8
Times Bold|1|/System/Library/Fonts/Times.dfont|9|utf-8
Times Bold|1|/System/Library/Fonts/Times.dfont|1|utf-8
Times Bold|1|/System/Library/Fonts/Times.dfont|5|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|11|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|3|utf-8
Times Bold Italic|1|/System/Library/Fonts/Times.dfont|7|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|2|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|10|utf-8
Times Italic|1|/System/Library/Fonts/Times.dfont|6|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|0|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|4|utf-8
Times Regular|1|/System/Library/Fonts/Times.dfont|8|utf-8
Strange - almost ALL the dfonts have tripled indexes for each style.
And always alternating indexes. I'm not sure what that's all about,
but with the dulicate names, only one of the triplet will be usable.
As a test I made the names unique for the Times styles in my
freetypecap file and drew each of them - they all work. So it
appears that only the first one of each triplet is needed.
One suggestion - make it useable outside of GRASS, or during the
startup process. (I tried it and got a segfault)
This would be useful for a first-time run of GRASS when an alternate
$GRASS_FT_CAP is used, and that doesn't exist yet. Maybe default to
stdout in this case, since GISBASE might not be set.
I'm thinking of a binary install (especially OSX) that will build a
user freetypecap to use in place of the built copy in the GRASS
binary, but not overwrite the GRASS binary copy, since the user might
not have admin privileges. Maybe run it in init.sh if GRASS_FT_CAP
is set and the referenced file does not exist yet. I guess if run in
init.sh, it could be run at a point when the necessary env vars are
set...
Postscript fonts - no worries there, if FreeType supports them,
they're listed (I have a couple in my /Library/Fonts folder).
Another possible option - write to $GRASS_FT_CAP, if set. Or to a
user-supplied file path.

Post by Paul Kelly
I've done that now. See attached for the prototype in case anybody
would like to try it. What it does is search through all the files
in the list of directories we gathered (hard-coded in main.c).
Rather than checking the file extension it examines each file using
Freetype functions to see if it is a font or not. This should work
for font files with no extension if they exist. It should also get
the multiple fonts in one file OK - would be especially interested
to see what it comes up with when run on a Mac system.
I haven't done anything yet about finding duplicate fonts - I don't
have any on either the Windows or Linux systems I tested this on.
The list is sorted first by font type (stroke or freetype) and
secondly name. I've just gone with a fully descriptive name,
including spaces for the names. The elegant simplicity of that
approach for the GUI font selection box seems to work quite well.
The version of the program (called g.mkfontcap for now) attached
can write a file in either the current freetypecap format, or the
proposed new fontcap format, which (in order to be Windows-
compatible) separates all the fields with a vertical bar - and
includes the index within each font file and the type of font
(stroke or freetype) as fields also. Hopefully this format should
be easily extendible to include PostScript fonts too?
I'm still not very sure at all about the meaning of the encoding
field or if it should be included, or even if it depends on the
fonts in any way at all and if there's any way it should be derived
from freetype?
If we can decide on a name - maybe g.mkfontcap is all right? - I
can submit it to CVS for further improvements.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Time is an illusion - lunchtime doubly so."
- Ford Prefect

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Whatever these names are, the gui will try to eliminate duplicates in the
list supplied by d.font -l

Michael

Post by Paul Kelly
I also changed the fontcap format to have a shortname and a long
descriptive name. The short name is made up of the filename with any
suffix stripped, and the index number added if it is greater than 0. For
the GUI font selection box to be as pretty as possible then I guess it
will need to use the short name internally as an index key to the list,
but display the long name for the user to select.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Paul Kelly]

Post by Michael Barton
In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Yes. If I understood Glynn's message correctly, right now it isn't showing
the stroke fonts but probably will again soon.

Post by Michael Barton
Whatever these names are, the gui will try to eliminate duplicates in the
list supplied by d.font -l

Ideally that shouldn't be necessary if we can generate the list correctly.
But it may still be a while until we sort that out (cf. William's e-mail
of this morning with the apparently unexplainable identical copies of
fonts in the same file).
However at least, once we change d.font -l to use the new fontcap file it
should no longer be necessary/desirable to sort the list in the GUI.

Paul

[Glynn Clements]

Post by Paul Kelly

Post by Michael Barton
In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Yes. If I understood Glynn's message correctly, right now it isn't showing
the stroke fonts but probably will again soon.

R_font_list() doesn't return the stroke fonts, but d.font adds them
manually.

Post by Paul Kelly

Post by Michael Barton
Whatever these names are, the gui will try to eliminate duplicates in the
list supplied by d.font -l

Ideally that shouldn't be necessary if we can generate the list correctly.
But it may still be a while until we sort that out (cf. William's e-mail
of this morning with the apparently unexplainable identical copies of
fonts in the same file).

Are they really identical?

It's possible that there may be differences which aren't immediately
obvious, e.g. designed for different sizes (in "real" typography, a
72-point glyph isn't quite identical to a 12-point glyph scaled up
6:1) or with different hinting.

[William Kyngesburye]

Post by Glynn Clements

Post by Paul Kelly

Post by Michael Barton
Whatever these names are, the gui will try to eliminate
duplicates in the
list supplied by d.font -l

Ideally that shouldn't be necessary if we can generate the list correctly.
But it may still be a while until we sort that out (cf. William's e-mail
of this morning with the apparently unexplainable identical copies of
fonts in the same file).

Are they really identical?
It's possible that there may be differences which aren't immediately
obvious, e.g. designed for different sizes (in "real" typography, a
72-point glyph isn't quite identical to a 12-point glyph scaled up
6:1) or with different hinting.

That's what I'm thinking - some sort of typography distinction. It's
transparent to the OS font handling. So far it's just in the dfonts,
but if it really is a typography thing, it could appear in OTF fonts
as well.

Could a debug option be added to g.mkfontcap? have it list ALL
available attributes from each face so we can see if FreeType sees
any difference besides face index?

Besides typography differences, another possibility is embedded
bitmaps for common sizes. The resource fonts (ie Arial) definitely
have these, but they are not causing duplicate listings. The dfonts
may have these, but I'm sure some have more sizes and some less than 3.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

[Glynn Clements]

Post by Michael Barton
In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Yes, although the mechanism has changed. d.font no longer reads the
freetypecap file directly. Instead, it uses R_font_list() to get the
list from the driver.

At present, R_font_list() only returns the fonts from the freetypecap
file, and d.font manually merges the list of stroke fonts. If
lib/driver is changed to use the new file (which includes stroke
fonts), d.font can have the stroke font handling removed; it can just
output whatever list R_font_list() returns.

All of this should be transparent to the GUI.

[Michael Barton]

I'm happy to reduce the code by not bothering to eliminate duplicate in the
GUI if this can be done in prior. Once this is sorted out, I can remove the
duplicate killing code.

Michael

Post by Paul Kelly

Post by Michael Barton
In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Yes. If I understood Glynn's message correctly, right now it isn't showing
the stroke fonts but probably will again soon.

Post by Michael Barton
Whatever these names are, the gui will try to eliminate duplicates in the
list supplied by d.font -l

Ideally that shouldn't be necessary if we can generate the list correctly.
But it may still be a while until we sort that out (cf. William's e-mail
of this morning with the apparently unexplainable identical copies of
fonts in the same file).
However at least, once we change d.font -l to use the new fontcap file it
should no longer be necessary/desirable to sort the list in the GUI.
Paul

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

That's what I was hoping. So in this case I can just sit back and wait until
the duplicates issue is removed and then take out that code from the GUI.

Michael

Post by Glynn Clements

Post by Michael Barton
In the GUI, I'm depending on d.font -l to supply font names in a valid
format useable by GRASS_FONT. Is this still happening?

Yes, although the mechanism has changed. d.font no longer reads the
freetypecap file directly. Instead, it uses R_font_list() to get the
list from the driver.
At present, R_font_list() only returns the fonts from the freetypecap
file, and d.font manually merges the list of stroke fonts. If
lib/driver is changed to use the new file (which includes stroke
fonts), d.font can have the stroke font handling removed; it can just
output whatever list R_font_list() returns.
All of this should be transparent to the GUI.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton