[GRASS-user] v.label utf8 possible?

Robert_Kuszinger · June 24, 2016, 3:10pm

Hello Everyone,

I’d like to create a label for a point vector map with point names to be utilized in map composer (ps.map).

Everything works except that I cannot use my UTF8 strings. They are rendered as latin1 as far as I can see.

Using d.vect strings are displayed correctly:

d.vect --quiet map=places@Duna where=“type=‘village’ OR type=‘town’” color=none fill_color=red width=1 icon=basic/circle attribute_column=name label_color=black label_size=9 font=LinBiolinum_R encoding=UTF-8

but there is no encoding option in v.label. I’ve found some links to v.label.sa which is not available in my Grass setup nor on the extension list.

Grass version is:

> g.version -bre
GRASS 7.0.4 (2016)

./configure --prefix=/opt/grass --with-freetype-includes=/usr/include/freetype2 --with-wxwidgets=/usr/bin/wx-config --with-readline --with-pthread --with-netcdf --with-liblas --with-blas --with-lapack --with-geos --with-nls --with-geos --with-postgres
libgis Revision: 67364
libgis Date: 2015-12-24 16:07:44 +0100 (Thu, 24 Dec 2015)
PROJ.4: 4.9.2
GDAL/OGR: 2.1.0
GEOS: 3.5.0
SQLite: 3.13.0

Is there a chance to create it at all? UTF-8 is essential and some characters I need to print are not available in latin1.

thanks

Robert

neteler · June 26, 2016, 9:46am

On Fri, Jun 24, 2016 at 5:10 PM, Robert Kuszinger <kuszinger@giscom.hu> wrote:

Hello Everyone,

I'd like to create a label for a point vector map with point names to be
utilized in map composer (ps.map).

Everything works except that I cannot use my UTF8 strings. They are rendered
as latin1 as far as I can see.

Using d.vect strings are displayed correctly:

d.vect --quiet map=places@Duna where="type='village' OR type='town'"
color=none fill_color=red width=1 icon=basic/circle attribute_column=name
label_color=black label_size=9 font=LinBiolinum_R encoding=UTF-8

but there is no encoding option in v.label.

AFAIK there is no encoding support available in v.labels at time.
Please open an enhancement ticket for this at

https://trac.osgeo.org/grass/newticket
(requires to register first at OSGeo, see there).

I've found some links to
v.label.sa which is not available in my Grass setup nor on the extension
list.

Unfortunately v.label.sa is not compliant with GRASS GIS 7, see
https://trac.osgeo.org/grass/ticket/1942

[...]

Is there a chance to create it at all? UTF-8 is essential and some
characters I need to print are not available in latin1.

Fully agreed! Let's follow up via ticket on this.

Markus

--
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

Robert_Kuszinger · June 26, 2016, 11:38am

Markus,

thanks for the notes. Finally I realized that in an UTF-8 environment what v.label does is ok, its generated files (pure text with pre-calculated placements) are identical to system codepage.

ps.map itself is the component which is limited to latin1.

Actually I haven’t stopped at this problem but started to make an alternative script for myself. In the near future I may have to create maps with khmer text on it.
As a workaround I’ve created a script and discovered that I could simulate the work done by ps.map with some handmade calculations.

The result is not worse (visually in terms of generated code) than my beloved ps.map definition files. I have full control on display, raster, vector and other map gadgets (north, scalebar, etc). I use GRASS_RENDER_* variables, and all d.* commands. Cairo driver with BMP output is very fast. I put each map “layer” into a different BMP files with identicatal resolutions.

Merging (stacking, layering, flattening or whatever you call it) and opacity are the only steps I need to use external command for which is imagemagick.

The resolution is currently a given dpi (300-600) bitmap but I’d like to test the toolchain with svg output as well to keep vectors for best print process.

Anyway, an oversampled bitmap (600 dpi for 300 dpi target) is usually enough so I’m ready for my own purposes.

I’m not too familiar with postcript but I’m also interested if it could be enhanced anyway to work with opentype/ttf unicode fonts and glyphs.

Thanks again

Robert

···

AFAIK there is no encoding support available in v.labels at time.
Please open an enhancement ticket for this at

https://trac.osgeo.org/grass/newticket
(requires to register first at OSGeo, see there).

I’ve found some links to
v.label.sa which is not available in my Grass setup nor on the extension
list.

Unfortunately v.label.sa is not compliant with GRASS GIS 7, see
https://trac.osgeo.org/grass/ticket/1942

[…]

Is there a chance to create it at all? UTF-8 is essential and some
characters I need to print are not available in latin1.

Fully agreed! Let’s follow up via ticket on this.

Markus

–
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

annakrat · June 26, 2016, 7:35pm

On Sun, Jun 26, 2016 at 7:38 AM, Robert Kuszinger <kuszinger@giscom.hu> wrote:

Markus,

thanks for the notes. Finally I realized that in an UTF-8 environment what
v.label does is ok, its generated files (pure text with pre-calculated
placements) are identical to system codepage.

ps.map itself is the component which is limited to latin1.

Actually I haven't stopped at this problem but started to make an
alternative script for myself. In the near future I may have to create maps
with khmer text on it.
As a workaround I've created a script and discovered that I could simulate
the work done by ps.map with some handmade calculations.
The result is not worse (visually in terms of generated code) than my
beloved ps.map definition files. I have full control on display, raster,
vector and other map gadgets (north, scalebar, etc). I use GRASS_RENDER_*
variables, and all d.* commands. Cairo driver with BMP output is very fast.
I put each map "layer" into a different BMP files with identicatal
resolutions.

Merging (stacking, layering, flattening or whatever you call it) and opacity
are the only steps I need to use external command for which is imagemagick.

The resolution is currently a given dpi (300-600) bitmap but I'd like to
test the toolchain with svg output as well to keep vectors for best print
process.
Anyway, an oversampled bitmap (600 dpi for 300 dpi target) is usually enough
so I'm ready for my own purposes.

I'm not too familiar with postcript but I'm also interested if it could be
enhanced anyway to work with opentype/ttf unicode fonts and glyphs.

Thanks again
Robert

See related ticket:
https://trac.osgeo.org/grass/ticket/1349

AFAIK there is no encoding support available in v.labels at time.
Please open an enhancement ticket for this at

https://trac.osgeo.org/grass/newticket
(requires to register first at OSGeo, see there).

> I've found some links to
> v.label.sa which is not available in my Grass setup nor on the extension
> list.

Unfortunately v.label.sa is not compliant with GRASS GIS 7, see
https://trac.osgeo.org/grass/ticket/1942

[...]
> Is there a chance to create it at all? UTF-8 is essential and some
> characters I need to print are not available in latin1.

Fully agreed! Let's follow up via ticket on this.

Markus

--
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

wenzeslaus · June 27, 2016, 4:50pm

On Sun, Jun 26, 2016 at 7:38 AM, Robert Kuszinger <kuszinger@giscom.hu>
wrote:

As a workaround I've created a script and discovered that I could simulate
the work done by ps.map with some handmade calculations.
The result is not worse (visually in terms of generated code) than my
beloved ps.map definition files. I have full control on display, raster,
vector and other map gadgets (north, scalebar, etc). I use GRASS_RENDER_*
variables, and all d.* commands. Cairo driver with BMP output is very fast.
I put each map "layer" into a different BMP files with identicatal
resolutions.

This sounds good. Perhaps you can share your work at some point. It would
be a good contribution to the discussion about the future of ps.map and d.
commands.

The resolution is currently a given dpi (300-600) bitmap but I'd like to
test the toolchain with svg output as well to keep vectors for best print
process.

Please see:

https://trac.osgeo.org/grass/ticket/3033

Vaclav

Glynn_Clements1 · June 27, 2016, 10:06pm

Robert Kuszinger wrote:

I'd like to create a label for a point vector map with point names to be
utilized in map composer (ps.map).

Everything works except that I cannot use my UTF8 strings. They are
rendered as latin1 as far as I can see.

Using d.vect strings are displayed correctly:

d.vect --quiet map=places@Duna where="type='village' OR type='town'"
color=none fill_color=red width=1 icon=basic/circle attribute_column=name
label_color=black label_size=9 font=LinBiolinum_R encoding=UTF-8

but there is no encoding option in v.label. I've found some links to
v.label.sa which is not available in my Grass setup nor on the extension
list.
Grass version is:

AIUI, v.label simply sets the labels as byte strings. Their
interpretation is determined by the program which actually renders the
labels, either by an explicit call to D_encoding(), or from the
environment variable GRASS_ENCODING, or from the font's default
encoding from the fontcap file.

UTF-8 text should work with d.vect and d.labels if you use a FreeType
font (but not for a stroke font, which only provide glyphs for the
ASCII range). I wouldn't expect it to work with anything which
generates PostScript.

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

Robert_Kuszinger · June 28, 2016, 12:16pm

Glynn,

thanks for the answer.

“I wouldn’t expect it to work with anything which
generates PostScript.”

I also tested it not only with ps.map but also cairo ps output and ps driver.

ps.map and ps driver fails with utf-8 vector using Biolinum font.

Ghostscript drops the an error on the resulting ps (see e-mail end)

Good news:

Cairo ps output generates even utf-8 d.vect correctly (with rasterized font glyphs), but ignores

export GRASS_RENDER_PS_HEADER=FALSE
export GRASS_RENDER_PS_TRAILER=FALSE

settings. Well, this is understandable since these are PS driver options. A beautiful combination would be to use the cairo PS output with the options above… I know, it is something cairo internal…

thanks again

Robert

--------------------------------------gs all.ps

GPL Ghostscript 9.19 (2016-03-23)
Copyright (C) 2016 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /rangecheck in --imagemask–
Operand stack:
17354512 0 true --nostringval-- --nostringval–
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1983 1 3 %oparray_pop 1982 1 3 %oparray_pop 1966 1 3 %oparray_pop 1852 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 1880 5 3 %oparray_pop
Dictionary stack:
–dict:1200/1684(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)–
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 10807894
GPL Ghostscript 9.19: Unrecoverable error, exit code 1

···

2016-06-28 0:06 GMT+02:00 Glynn Clements <glynn@gclements.plus.com>:

Robert Kuszinger wrote:

I’d like to create a label for a point vector map with point names to be
utilized in map composer (ps.map).

Everything works except that I cannot use my UTF8 strings. They are
rendered as latin1 as far as I can see.

Using d.vect strings are displayed correctly:

d.vect --quiet map=places@Duna where=“type=‘village’ OR type=‘town’”
color=none fill_color=red width=1 icon=basic/circle attribute_column=name
label_color=black label_size=9 font=LinBiolinum_R encoding=UTF-8

but there is no encoding option in v.label. I’ve found some links to
v.label.sa which is not available in my Grass setup nor on the extension
list.
Grass version is:

AIUI, v.label simply sets the labels as byte strings. Their
interpretation is determined by the program which actually renders the
labels, either by an explicit call to D_encoding(), or from the
environment variable GRASS_ENCODING, or from the font’s default
encoding from the fontcap file.

UTF-8 text should work with d.vect and d.labels if you use a FreeType
font (but not for a stroke font, which only provide glyphs for the
ASCII range). I wouldn’t expect it to work with anything which
generates PostScript.

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

Robert_Kuszinger · June 28, 2016, 7:16pm

Dear Vaclav,

thanks I’read the whole discussion (ticket 3033). This is very similar to my problem so I added a note.

Yes, I’ll publish what I achieve once it is mature enough for public use.

QUESTION: Is Python a must or could I live on bash/grep and other NX tools? Now it is in bash. I don’t really know python. Well not even bash but at least I have some practice with that. (Normally I work in Smalltalk but that won’t help here )

thanks

Robert

···

2016-06-27 18:50 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

On Sun, Jun 26, 2016 at 7:38 AM, Robert Kuszinger <kuszinger@giscom.hu> wrote:

As a workaround I’ve created a script and discovered that I could simulate the work done by ps.map with some handmade calculations.

The result is not worse (visually in terms of generated code) than my beloved ps.map definition files. I have full control on display, raster, vector and other map gadgets (north, scalebar, etc). I use GRASS_RENDER_* variables, and all d.* commands. Cairo driver with BMP output is very fast. I put each map “layer” into a different BMP files with identicatal resolutions.

This sounds good. Perhaps you can share your work at some point. It would be a good contribution to the discussion about the future of ps.map and d. commands.

The resolution is currently a given dpi (300-600) bitmap but I’d like to test the toolchain with svg output as well to keep vectors for best print process.

Please see:

https://trac.osgeo.org/grass/ticket/3033

Vaclav

wenzeslaus · June 28, 2016, 8:33pm

On Tue, Jun 28, 2016 at 3:16 PM, Robert Kuszinger <kuszinger@giscom.hu>
wrote:

QUESTION: Is Python a must or could I live on bash/grep and other *N*X
tools? Now it is in bash. I don't really know python. Well not even bash
but at least I have some practice with that.

It depends what is the end goal. If the goal is to supply other users with
starting point for their scripts, then Bash is fine. Same applies if the
goal is to provide developers with ideas about what can be developed.
However, if you would like to create a ready-to-use tool which can be
published in GRASS GIS Addons, distributed to users on various operating
systems, and maintained in the long term by various people, then Python is
a better a basically a necessary choice. I think that the Addons option has
additional advantages; one being creation of a better interface on the way.

(Normally I work in Smalltalk but that won't help here )

In that case, Bash is better