[GRASS-dev] [GRASS GIS] #1349: Ps.map supports only english

#1349: Ps.map supports only english
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.5.0
Component: Ps.map | Version: unspecified
Keywords: encoding | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1349&gt;
GRASS GIS <http://grass.osgeo.org>

#1349: Ps.map supports only english
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.5.0
Component: Ps.map | Version: unspecified
Keywords: encoding | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by hamish):

Replying to [ticket:1349 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1349#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#1349: Ps.map supports only english
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.5.0
Component: Ps.map | Version: unspecified
Keywords: encoding | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by mlennert):

Replying to [comment:1 hamish]:
> Replying to [ticket:1349 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1349#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#1349: Ps.map supports only english
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.5.0
Component: Ps.map | Version: unspecified
Keywords: encoding | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by glynn):

Replying to [comment:2 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1349#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#1349: Ps.map supports only english
-------------------------+--------------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.5.0
Component: Ps.map | Version: unspecified
Keywords: encoding | Platform: Unspecified
      Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by annakrat):

Replying to [comment:1 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)?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1349#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>