[GRASS-dev] fonts and character encoding

[Glynn Clements]

Hamish wrote:

> > Tcl and Python both use Unicode internally, and automatically convert
> > to the locale's encoding when calling system functions. So if the user
> > types a value for e.g. "d.text text=..." into the GUI, the sequence of
> > bytes which end up in the corresponding argv[] will be in the locale's
> > encoding.
> ..
> > But, in general, the GUI should probably stick with the locale's
> > encoding, as that's what external commands will normally be expecting.
> ..
> > Needless to say, this won't work on Windows. You can get the Windows
> > codepage by parsing the output from "mode con cp /status", although
> > there might be better solutions. iconv appears to accept cp??? for
> > most of the common ones (e.g. cp437 = US, cp850 = western Europe,
> > etc).
> 
> 
> I was thinking about this with WRT to the meta-data systems.
> 
> e.g. say a raster map's units are °C or kg/m³ or µg/l.
> 
> Could "r.support units=" support that or would a user have to edit the
> cell_misc/$MAP/units file themselves?

No reason why not.

> And if they did edit it by hand,
> would the (new) file be compatible with what GRASS expects?

What does GRASS expect?

> Would
> d.legend, GUI profile tool, etc, transfer the degree symbol (or whatever)
> unharmed? Could the map be transfered to another (foreign) system intact?

d.* commands will work so long as the encoding used in the units file
matches the current font encoding ($GRASS_FT_ENCODING or "d.font
charset=...").

If the strings are used by the GUI, they'll probably need to be in the
locale's encoding. If they are simply passed through, they need to at
least be valid in the locale's encoding (everything is valid in
ISO-8859-1, but not all strings are valid in UTF-8).

Most of GRASS doesn't deal with characters, just bytes. The only time
that the encoding matters is when passing strings to something which
wants to convert them to Unicode, e.g. FreeType, Tcl, Python.

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