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

[Paul Kelly]

On Sun, 6 May 2007, Glynn Clements wrote:

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

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

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