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

[Glynn Clements]

Paul Kelly wrote:

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

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

-- 
Glynn Clements <glynn at gclements.plus.com>