[GRASS-user] ps.map character encoding problems

Dear List,

I have trouble with the ps.map module and character encoding in the legend. I
have french characters (é,è and others) as a layer label. The layer itself
was imported from a postgis database, which has a unicode encoding. As far as
I understand the manual for ps.map, you need your mapping instructions file
encoded to ISO-8859-1. At the end of the manual is the appropriate command
listed. so far so good.
But I use a condition for my vector layer, which has the layer name as where
clause term. Converting my mapping instructions file to ISO-8859-1 gives me
another error, with the result that the layer cannot be drawn and ps.map
exits. Here's the error:

ps.map -e input=print.txt output=print.ps
PS-PAINT: scale set to 1 : 360512.
PS-PAINT: reading raster file <dgm in PERMANENT> ...
PS-PAINT: reading vector points file <sites in PERMANENT> ...DBMI-Postgres
driver error:
Cannot select:
SELECT id FROM sites WHERE epoch = 'M�solithique'
ERROR: invalid byte sequence for encoding "UTF8": 0xe9736f
HINT: This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by "client_encoding".

Any help is greatly appreciated

Frank

Frank Broniewski wrote:

I have trouble with the ps.map module and character encoding in the legend. I
have french characters (é,è and others) as a layer label. The layer itself
was imported from a postgis database, which has a unicode encoding. As far as
I understand the manual for ps.map, you need your mapping instructions file
encoded to ISO-8859-1. At the end of the manual is the appropriate command
listed. so far so good.
But I use a condition for my vector layer, which has the layer name as where
clause term. Converting my mapping instructions file to ISO-8859-1 gives me
another error, with the result that the layer cannot be drawn and ps.map
exits. Here's the error:

ps.map -e input=print.txt output=print.ps
PS-PAINT: scale set to 1 : 360512.
PS-PAINT: reading raster file <dgm in PERMANENT> ...
PS-PAINT: reading vector points file <sites in PERMANENT> ...DBMI-Postgres
driver error:
Cannot select:
SELECT id FROM sites WHERE epoch = 'M�solithique'
ERROR: invalid byte sequence for encoding "UTF8": 0xe9736f
HINT: This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by "client_encoding".

Any help is greatly appreciated

ps.map itself doesn't care about encodings; it's all just bytes.

Any text which is meant to appear in the output is embedded verbatim
in the PostScript file. The prolog automatically re-encodes any fonts
to ISOLatin1Encoding (PostScript's default encoding isn't much use, as
nothing other than PostScript uses it), so any text needs to use that
encoding.

Similarly, any strings which are passed to library functions etc are
passed without any conversions.

In this particular case, it should suffice to use ISO-8859-1 for
displayed text and UTF-8 for the WHERE clause. The reference to
client_encoding suggests that it may be possible for the DBMS to
perform encoding conversions, but I don't know how, or if it's even
possible from GRASS.

It would theoretically be possible to modify ps.map to convert
displayed text from a user-defined encoding to ISO-8859-1. However,
this could require a significant amount of work. As ps.map will be
superseded in 7.x, I'm not sure that it's worth the effort.

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

On Monday 12 November 2007 17:29:07 Glynn Clements wrote:

Frank Broniewski wrote:
> I have trouble with the ps.map module and character encoding in the
> legend. I have french characters (é,è and others) as a layer label. The
> layer itself was imported from a postgis database, which has a unicode
> encoding. As far as I understand the manual for ps.map, you need your
> mapping instructions file encoded to ISO-8859-1. At the end of the manual
> is the appropriate command listed. so far so good.
> But I use a condition for my vector layer, which has the layer name as
> where clause term. Converting my mapping instructions file to ISO-8859-1
> gives me another error, with the result that the layer cannot be drawn
> and ps.map exits. Here's the error:
>
> ps.map -e input=print.txt output=print.ps
> PS-PAINT: scale set to 1 : 360512.
> PS-PAINT: reading raster file <dgm in PERMANENT> ...
> PS-PAINT: reading vector points file <sites in PERMANENT>
> ...DBMI-Postgres driver error:
> Cannot select:
> SELECT id FROM sites WHERE epoch = 'M�solithique'
> ERROR: invalid byte sequence for encoding "UTF8": 0xe9736f
> HINT: This error can also happen if the byte sequence does not match the
> encoding expected by the server, which is controlled by
> "client_encoding".
>
> Any help is greatly appreciated

ps.map itself doesn't care about encodings; it's all just bytes.

Any text which is meant to appear in the output is embedded verbatim
in the PostScript file. The prolog automatically re-encodes any fonts
to ISOLatin1Encoding (PostScript's default encoding isn't much use, as
nothing other than PostScript uses it), so any text needs to use that
encoding.

Similarly, any strings which are passed to library functions etc are
passed without any conversions.

In this particular case, it should suffice to use ISO-8859-1 for
displayed text and UTF-8 for the WHERE clause. The reference to
client_encoding suggests that it may be possible for the DBMS to
perform encoding conversions, but I don't know how, or if it's even
possible from GRASS.

It would theoretically be possible to modify ps.map to convert
displayed text from a user-defined encoding to ISO-8859-1. However,
this could require a significant amount of work. As ps.map will be
superseded in 7.x, I'm not sure that it's worth the effort.

Hi Glynn,

I must admit, I didn't understand fully what your post was up to. But! it
helped me to sort my problem somehow. You mentioned, that text is "embedded
verbatim in the PostScript file.". Well, so I opened my postscript file in my
editor, changed the encoding to ISO-8859-1 and replaced the character garbage
with my desired ones. Et Voila, here it works now.
Many thanks to you.

You mentioned, ps.map will be superseded in the future, but what will the
replacement be? I just ask, because today I had lots of trouble getting my
GIS data printed in a good quality with all the elements a map needs;
legends, north arrows and scalebars and such. I tried QGIS, but there is an
export error in relation to QT making labels and lines oversized. And there
are more problems concerning classification of data. I tried uDig, but I
really don't understand the workflow there and customizing is so xml'ish. So
I remembered my days at university where we were working with the Arcinfo
equivalent of ps.map, whatever it name was, don't remember anymore. ps.map
just made my day today.

Well, thanks again for your tipps.

Frank

Frank Broniewski wrote:

You mentioned, ps.map will be superseded in the future, but what will the
replacement be?

Eventually, d.* commands will be able to generate decent PostScript.

You can already do that to an extent with the PS driver, but
architectural issues (e.g. the fact that coordinates and sizes are
specified in pixels) mean that the results are less than ideal.

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