Ps.map supports only english

[annakrat]

Postscript file generated by ps.map uses Latin1 and as a result I can't use czech language properly. I have no experience with postscript, so would it be possible to change it to utf8?

Another issue relating to other languages is the label of scalebar units. It would be nice if the user could customize the label. There is a closed ticket #64 dealing with this problem a bit.

Thanks Anna

[hamish]

Replying to annakrat:

Postscript file generated by ps.map uses Latin1 and as a result I can't use czech language properly. I have no experience with postscript, so would it be possible to change it to utf8?

from the help page:

For users wanting to use special characters (such as accented char-
acters) it is important to note that ps.map uses ISO-8859-1  encod-
ing.   This  means  that  your  instructions  file  will have to be
encoded in this encoding. If  you  normally  work  in  a  different
encoding  environment  (such  as UTF-8), you have to transform your
file to the ISO-8859-1 encoding, for example  by  using  the  iconv
utility:
iconv -f UTF-8 -t ISO_8859-1 utf_file > iso_file

from the mailing list archive:

​http://thread.gmane.org/gmane.comp.gis.grass.devel/15881

Another issue relating to other languages is the label of scalebar units. It would be nice if the user could customize the label.

do you wish to have a translated version of one of the existing distance formats, or to use one not on the current list? I'd rather have it start from a fixed list of names+conv_to_meter values, but translated names of units is possible:

Index: ps/ps.map/do_scalebar.c
===================================================================
--- ps/ps.map/do_scalebar.c     (revision 46046)
+++ ps/ps.map/do_scalebar.c     (working copy)
@@ -1,9 +1,8 @@
-/* Function to draw scalebar on page 
- * **
- */
+/* Function to draw scalebar on page */
 
 #include <string.h>
 #include <math.h>
+#include <grass/glocale.h>
 #include "local_proto.h"
 #include "distance.h"
 
@@ -192,15 +191,15 @@
     if (sb.units == SB_UNITS_AUTO)
        strcpy(num, G_database_unit_name(TRUE));
     else if(sb.units == SB_UNITS_METERS)
-       strcpy(num, "meters");
+       strcpy(num, _("meters"));
     else if(sb.units == SB_UNITS_KM)
-       strcpy(num, "kilometers");
+       strcpy(num, _("kilometers"));
     else if(sb.units == SB_UNITS_FEET)
-       strcpy(num, "feet");
+       strcpy(num, _("feet"));
     else if(sb.units == SB_UNITS_MILES)
-       strcpy(num, "miles");
+       strcpy(num, _("miles"));
     else if(sb.units == SB_UNITS_NMILES)
-       strcpy(num, "nautical miles");
+       strcpy(num, _("nautical miles"));
     
     text_box_path(72.0 * (x + length/2), 72.0 * (PS.page_height - (sb.y + 0.075)),
        CENTER, UPPER, num, sb.fontsize, 0);

I don't think I bothered with that last time, beyond discussing if meters vs. metres should be taken from 'g.proj -p'. I'm totally ignorant how and if those unit names are called in non-latin languages so didn't take it further.

In general I'm not much of a fan of hard-results depending on the locale setting (harms ability to rely on reproducible results), but the above patch seems reasonable enough to me. does it solve the wish?

Hamish

[mlennert]

Replying to hamish:

Replying to annakrat:

Postscript file generated by ps.map uses Latin1 and as a result I can't use czech language properly. I have no experience with postscript, so would it be possible to change it to utf8?

from the help page:

For users wanting to use special characters (such as accented char-
acters) it is important to note that ps.map uses ISO-8859-1  encod-
ing.   This  means  that  your  instructions  file  will have to be
encoded in this encoding. If  you  normally  work  in  a  different
encoding  environment  (such  as UTF-8), you have to transform your
file to the ISO-8859-1 encoding, for example  by  using  the  iconv
utility:
iconv -f UTF-8 -t ISO_8859-1 utf_file > iso_file

from the mailing list archive:

​http://thread.gmane.org/gmane.comp.gis.grass.devel/15881

The problem is that

iconv -f UTF-8 -t ISO_8859-1 utf_file > iso_file

will not work if the utf_file contains special caracters which are defined in ISO-8859-2.

I don't know how/if Postscript handles UTF-8. a2ps and enscript can create Postscript files from text encoded in ISO-8859-2, but they cannot transform UTF-8 text into Postscript files.

This seems to be a more structural issue than just the iconv conversion. I don't know how other projects handle this issue.

Moritz

[glynn]

Replying to mlennert:

The problem is that

iconv -f UTF-8 -t ISO_8859-1 utf_file > iso_file

will not work if the utf_file contains special caracters which are defined in ISO-8859-2.

I don't know how/if Postscript handles UTF-8. a2ps and enscript can create Postscript files from text encoded in ISO-8859-2, but they cannot transform UTF-8 text into Postscript files.

The real problem is that PostScript's handling of encodings is an unmitigated fiasco.

PostScript itself defines precisely 2 encodings: StandardEncoding is a decidedly non-standard encoding used by PostScript alone, while !ISOLatin1Encoding is ISO-8859-1.

The PostScript Language Reference Manual also describes some additional encodings which aren't actually part of the language: CE (Central European) is Windows codepage 1250, Symbol was designed mainly for the Zapf Dingbats symbol font (similar to Wingdings on Windows), while Expert and ExpertSubset are basically ASCII plus an entirely arbitrary set of symbols. These additional encodings aren't part of the language or the implementation; they're just recommendations for font creators.

StandardEncoding and !ISOLatin1Encoding are predefined names in systemdict, whose values are encoding vectors (arrays of names, usable as the Encoding property in a font dictionary). If you want to use any other encoding, you first have to define the encoding vector yourself (which requires knowing the PostScript names for the various glyphs).

You also have to know the name of a font which has those glyphs and which you can reasonably expect to be provided by the implementation (i.e. the printer or the user's Ghostscript installation). The language only requires the existence of Times, Helvetica, and Courier (and bold and italic or oblique versions thereof) plus Symbol, and only requires those fonts to provide the glyphs required for StandardEncoding and ISOLatin1Encoding (or, for the Symbol font, the Symbol encoding).

Version 3 of the reference manual also documents CID-keyed fonts, which are required for languages with many glyphs (i.e. Chinese, Japanese, Korean). However, it only documents the overall mechanism, not any particular encodings. It's also rather incomplete, directing the reader to Adobe technical notes on several occasions. Anyone who actually understands this stuff probably works for either Adobe or a Japanese printer manufacturer.

[annakrat]

Replying to hamish:

do you wish to have a translated version of one of the existing distance formats, or to use one not on the current list?

I meant the translated version.

In general I'm not much of a fan of hard-results depending on the locale setting (harms ability to rely on reproducible results), but the above patch seems reasonable enough to me. does it solve the wish?

I'm not sure about this solution. If it would be dependend on locale settings and I would like to create map output in different language than in locale settings, is there a way to set language?

Another problem is that now I can't write czech labels to map because latin1 doesn't support some accented characters. And if I understand the previous comments well, this problem is not going to be fixed. As a result there's no need to have translated units. But users speaking other languages (where Latin1 is OK) may appreciate this.

What about adding the possibility of custom unit label (given by user), which would solve the problems with translation and enables to use abbreviations (like m, km)?