[GRASS-dev] 7.x Status Update

GRASS GRASS developer
1

I have now completed the removal of the bulk of the deprecated
functionality, i.e. terminal interaction and standalone display
monitors.

The following functionality no longer exists:

curses, vask, G_ask_*, G_yes, R_get_location_with_*, R_pad_*, d.mon.

Anything which substantially depended upon any of those has either
been removed or disabled, or no longer compiles. A small number of
modules which only made minor use of those features have lost some
functionality (e.g. you can no longer use the mouse for placement in
d.legend, d.barscale etc).

AFAICT, the complete list of modules which have been removed,
disabled, or which won't compile is:

d.ask
d.colors
d.extend
d.extract
d.font
d.font.freetype
d.frame
d.measure
d.menu
d.mon
d.profile
d.rast.edit
d.save
d.what.rast
d.what.vect
d.where
d.zoom
g.ask
g.setproj
i.ask
i.class
i.ortho.photo
i.points
i.vpoints
r.digit
r.le.setup
r.le.trace
r.support

In addition, none of the display drivers exist; all d.* commands will
unconditionally use direct rendering.

The curses-based set_data program no longer exists, so "grass70 -text"
won't work. You need to use -gui or pass the complete path to the
mapset directory as an argument to the grass70 script.

I would appreciate comments as to which of the above need replacements
and which don't. E.g. d.rast.edit already has an adequate (AFAICT)
replacement. Does g.setproj need to be replaced, or is "g.proj -c"
sufficient? Which of the d.* commands already have equivalent
functionality built into the GUI?

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

2

Another potentially disruptive update: the raster library now uses
floating point values for coordinates.

Please help test d.* modules. With 120 modified files, the chances
that I managed to break something are relatively high.

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

3

On 09/08/08 09:08, Glynn Clements wrote:

Another potentially disruptive update: the raster library now uses
floating point values for coordinates.

Please help test d.* modules. With 120 modified files, the chances
that I managed to break something are relatively high.

There seems to be a problem with d.vect. Area fill varies according to zoom level. When you display an entire map (e.g. census_wake2000 in the NC demo data set), a lot of areas are not filled, and there are empty spaces between areas. Zooming in reduces the non-filled and empty areas until they seem to disappear when you zoom in really far.

Moritz

4

Moritz Lennert wrote:

> Another potentially disruptive update: the raster library now uses
> floating point values for coordinates.
>
> Please help test d.* modules. With 120 modified files, the chances
> that I managed to break something are relatively high.

There seems to be a problem with d.vect. Area fill varies according to
zoom level. When you display an entire map (e.g. census_wake2000 in the
NC demo data set), a lot of areas are not filled, and there are empty
spaces between areas. Zooming in reduces the non-filled and empty areas
until they seem to disappear when you zoom in really far.

I'll try to look into that later (the NC data set is 135MiB).

Does changing the render= option have any effect? I changed the
default from render=c to render=l, so this may suggest a bug in that
particular rendering mode (l should be more efficient, but it had
problems with XDRIVER).

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

5

Moritz Lennert wrote:

There seems to be a problem with d.vect. Area fill varies according to
zoom level. When you display an entire map (e.g. census_wake2000 in the
NC demo data set), a lot of areas are not filled, and there are empty
spaces between areas. Zooming in reduces the non-filled and empty areas
until they seem to disappear when you zoom in really far.

This should be fixed by r32659.

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

6

On 10/08/08 03:02, Glynn Clements wrote:

Moritz Lennert wrote:

There seems to be a problem with d.vect. Area fill varies according to zoom level. When you display an entire map (e.g. census_wake2000 in the NC demo data set), a lot of areas are not filled, and there are empty spaces between areas. Zooming in reduces the non-filled and empty areas until they seem to disappear when you zoom in really far.

This should be fixed by r32659.

Yep, rapid testing indicates that it is fixed.

Moritz

7

Glynn Clements wrote:

Another potentially disruptive update: the raster library now uses
floating point values for coordinates.

Next update: the cairo driver is now the default, assuming that GRASS
was built --with-cairo. If you haven't been enabling this, now is the
time to try, as the PNG driver may not be around for much longer.

It's still possible to force the PNG driver to be used by setting
GRASS_RENDER_IMMEDIATE=PNG.

At present, it uses the "toy" font backend, which means that it only
understands a limited set of fonts (AFAICT, it understands mono, serif
and sans, and -bold and -italic variants), although support for
FreeType and stroke fonts will be added soon.

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

8

On Aug 10, 2008, at 4:50 AM, Glynn Clements wrote:

Glynn Clements wrote:

Another potentially disruptive update: the raster library now uses
floating point values for coordinates.

Next update: the cairo driver is now the default, assuming that GRASS
was built --with-cairo. If you haven't been enabling this, now is the
time to try, as the PNG driver may not be around for much longer.

I guess I *really* need to figure out Cairo for OSX now :wink: Well, here's my current status as of a month ago:

- pixman: requires GCC 4.2 for SSE2 (for some stack alignment issue), but compiles OK without it. I need to try the new GCC 4.2 available in Xcode 3.1 (this is available on OSX 10.5 Leopard only).

I made a script to build pixman universal, and will put it on my site when I figure out the SSE2 stuff.

- cairo: requires pkg-config to configure. For OSX this is silly, so I hacked configure to disable pkg-config usage.

BUT, GRASS also uses pkg-config to get cairo config info (the only dep in GRASS that does this). I find this unreasonable (at least for OSX), so can we get alternative (and standard for GRASS) --with-cairo-includes and --with-cairo-libs flags, please?

- Cairo knows about OSX Intel for configuring endian stuff, but my notes say there is a problem with that on PPC. I need to look at it again.

At present, it uses the "toy" font backend, which means that it only
understands a limited set of fonts (AFAICT, it understands mono, serif
and sans, and -bold and -italic variants), although support for
FreeType and stroke fonts will be added soon.

- cairo also requires fontconfig to be used with freetype. GRASS is handling font paths and configuration itself, so I don't see the point of this. I built fonconfig for my old library binaries once, but it was never used in the GIS packages and there were some build problems (I forget what), so I removed it. OSX X11 has fontconfig (and freetype), but I don't want to depend on an X11 installation on OSX.

So, I'm disabling the freetype backend and looking at the Cairo quartz font backend. I don't know how GRASS passes font details to Cairo, so I don't know if this will work. In general, how do you specify the cairo backend to use (surface and font), from GRASS? From the GRASS docs, it looks like file extension sets surface backend.

I had one problem with 64bits with quartz font backend. But until the 64bit OSX bug in GRASS is fixed, this is not a big deal.

---

That's where I left off. I'll get a build script made for cairo and put it on my site as soon as I can.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

9

William Kyngesburye wrote:

>> Another potentially disruptive update: the raster library now uses
>> floating point values for coordinates.
>
> Next update: the cairo driver is now the default, assuming that GRASS
> was built --with-cairo. If you haven't been enabling this, now is the
> time to try, as the PNG driver may not be around for much longer.

I guess I *really* need to figure out Cairo for OSX now :wink: Well,
here's my current status as of a month ago:

- pixman: requires GCC 4.2 for SSE2 (for some stack alignment issue),
but compiles OK without it. I need to try the new GCC 4.2 available
in Xcode 3.1 (this is available on OSX 10.5 Leopard only).

I made a script to build pixman universal, and will put it on my site
when I figure out the SSE2 stuff.

- cairo: requires pkg-config to configure. For OSX this is silly, so
I hacked configure to disable pkg-config usage.

BUT, GRASS also uses pkg-config to get cairo config info (the only dep
in GRASS that does this). I find this unreasonable (at least for
OSX), so can we get alternative (and standard for GRASS) --with-cairo-
includes and --with-cairo-libs flags, please?

This would also be useful on Windows.

The only potential problem is that cairo might need some -l flags.
There's currently no way to provide those via configure, and with
high-level libraries, it starts getting impractical to enumerate
candidate libraries until the linking test succeeds.

OTOH, this is really only likely to be an issue if cairo is a static
library, or a dynamic library which lacks dependency information, both
of which are relatively unlikely.

> At present, it uses the "toy" font backend, which means that it only
> understands a limited set of fonts (AFAICT, it understands mono, serif
> and sans, and -bold and -italic variants), although support for
> FreeType and stroke fonts will be added soon.

- cairo also requires fontconfig to be used with freetype. GRASS is
handling font paths and configuration itself, so I don't see the point
of this. I built fonconfig for my old library binaries once, but it
was never used in the GIS packages and there were some build problems
(I forget what), so I removed it. OSX X11 has fontconfig (and
freetype), but I don't want to depend on an X11 installation on OSX.

Cairo provides two functions to obtain a "handle" to a FreeType font;
one uses an FcPattern* while the other takes an FT_Face. However,
AFAICT, you don't have the option of building without fontconfig, even
if you only want the FT_Face version.

So, I'm disabling the freetype backend and looking at the Cairo quartz
font backend. I don't know how GRASS passes font details to Cairo, so
I don't know if this will work. In general, how do you specify the
cairo backend to use (surface and font), from GRASS? From the GRASS
docs, it looks like file extension sets surface backend.

There's no inherent reason why it can't support multiple font
back-ends. Each provides a different mechanism to obtain a
cairo_font_face_t* which can be passed to cairo_set_font_face().

The main issue is that each back-end needs corresponding
platform-specific code to get the platform's font handle.

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

10

On Sun, 10 Aug 2008, William Kyngesburye wrote:

[...]

- cairo also requires fontconfig to be used with freetype. GRASS is handling font paths and configuration itself, so I don't see the point of this. I built fonconfig for my old library binaries once, but it was never used in the GIS packages and there were some build problems (I forget what), so I removed it. OSX X11 has fontconfig (and freetype), but I don't want to depend on an X11 installation on OSX.

ISTR a report that g.mkfontcap found some fonts on OS X that fontconfig didn't detect (that was a pleasant surprise at the time). Is that still the case and, if so, is it relevant? Probably avoiding too much "DIY" is best - if g.mkfontcap just duplicates what fontconfig does it can be done away with and Cairo can find the fonts itself - but OTOH it does seem to have worked very well as a cross-platform solution to finding available fonts.

Paul

11

On Aug 10, 2008, at 4:32 PM, Glynn Clements wrote:

BUT, GRASS also uses pkg-config to get cairo config info (the only dep
in GRASS that does this). I find this unreasonable (at least for
OSX), so can we get alternative (and standard for GRASS) --with-cairo-
includes and --with-cairo-libs flags, please?

This would also be useful on Windows.

The only potential problem is that cairo might need some -l flags.
There's currently no way to provide those via configure, and with
high-level libraries, it starts getting impractical to enumerate
candidate libraries until the linking test succeeds.

And there will be OSX-specific system frameworks needed for cairo.

OTOH, this is really only likely to be an issue if cairo is a static
library, or a dynamic library which lacks dependency information, both
of which are relatively unlikely.

Dynamic lib may be the way to go - at least my attempt to build a static cairo today failed. It looks like it only has one library target, and it's tailored to a shared lib since it passes -lpixman as a flag. When I build pixman as static also, libtool tries to ar that into cairo, but can't because it's not an object file.

So, I'm disabling the freetype backend and looking at the Cairo quartz
font backend. I don't know how GRASS passes font details to Cairo, so
I don't know if this will work. In general, how do you specify the
cairo backend to use (surface and font), from GRASS? From the GRASS
docs, it looks like file extension sets surface backend.

There's no inherent reason why it can't support multiple font
back-ends. Each provides a different mechanism to obtain a
cairo_font_face_t* which can be passed to cairo_set_font_face().

The main issue is that each back-end needs corresponding
platform-specific code to get the platform's font handle.

I'll see what you come up with for freetype fonts. Maybe I can make sense of the OSX font API(s) and add Cairo/Quartz support. But it will probably mean a complete overhaul of the fontcap setup:

On Aug 10, 2008, at 4:47 PM, Paul Kelly wrote:

ISTR a report that g.mkfontcap found some fonts on OS X that fontconfig didn't detect (that was a pleasant surprise at the time). Is that still the case and, if so, is it relevant? Probably avoiding too much "DIY" is best - if g.mkfontcap just duplicates what fontconfig does it can be done away with and Cairo can find the fonts itself - but OTOH it does seem to have worked very well as a cross-platform solution to finding available fonts.

mkfontcap detects font files in known system, and user-specified, locations. This is much different than detecting "enabled" fonts in the system, which is what the Cairo Quartz font support will want. A font in OSX can be "installed" in one of many standard locations, but is "enabled" by API calls. Normally, fonts are automatically enabled when installed, but they can be disabled. Fonts can also be enabled from random locations, which is what font managers do (Suitcase, Linotype Fontexplorer, ...) and apps with internal fonts.

We may need to revise the fontcap setup for more platform-specific behavior. On OSX it would have to detect "enabled" fonts at runtime, and not installed fonts when g.mkfontcap is run. This may be easy to do with python, since it (directly or wx?) probably already has some such feature or extension.

Or, since it will still be possible to use freetype and native font APIs together, leave the fontcap for use by freetype, and have a new font list function for use by OS native font routines.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?

-HitchHiker's Guide to the Galaxy

12

William Kyngesburye wrote:

>> So, I'm disabling the freetype backend and looking at the Cairo
>> quartz
>> font backend. I don't know how GRASS passes font details to Cairo,
>> so
>> I don't know if this will work. In general, how do you specify the
>> cairo backend to use (surface and font), from GRASS? From the GRASS
>> docs, it looks like file extension sets surface backend.
>
> There's no inherent reason why it can't support multiple font
> back-ends. Each provides a different mechanism to obtain a
> cairo_font_face_t* which can be passed to cairo_set_font_face().
>
> The main issue is that each back-end needs corresponding
> platform-specific code to get the platform's font handle.
>
I'll see what you come up with for freetype fonts. Maybe I can make
sense of the OSX font API(s) and add Cairo/Quartz support.

The support for FreeType fonts via Fontconfig was simple enough.

[Most of the effort was spent tracking down why it wouldn't scale the
font correctly even though it would rotate it. It turns out that it
was a bitmap font, and cairo won't scale bitmap fonts even though it
will rotate them.]

That should suffice for most purposes, although we can add the option
to use a TTF file via an explicit path if there's a need for it
(AFAICT, the ability to bypass Fontconfig is mainly for cases such as
web fonts, fonts embedded in documents, etc).

For Quartz, you need to figure out how to get either a CGFontRef or an
ATSUFontID:

cairo_font_face_t* cairo_quartz_font_face_create_for_cgfont(CGFontRef font);
cairo_font_face_t* cairo_quartz_font_face_create_for_atsu_font_id(ATSUFontID font_id);

Similarly, Windows needs a LOGFONTW* and/or an HFONT:

cairo_font_face_t* cairo_win32_font_face_create_for_logfontw(LOGFONTW *logfont);
cairo_font_face_t* cairo_win32_font_face_create_for_hfont(HFONT font);
cairo_font_face_t* cairo_win32_font_face_create_for_logfontw_hfont(LOGFONTW *logfont, HFONT font);

But it will probably mean a complete overhaul of the fontcap setup:

Well, it would probably be better to dispense with the fontcap file
altogether and just make the driver use the appropriate font
management APIs.

Given that cairo's FreeType back-end requires Fontconfig, we may as
well use that to enumerate the available fonts.

We may need to revise the fontcap setup for more platform-specific
behavior. On OSX it would have to detect "enabled" fonts at runtime,
and not installed fonts when g.mkfontcap is run. This may be easy to
do with python, since it (directly or wx?) probably already has some
such feature or extension.

Or, since it will still be possible to use freetype and native font
APIs together, leave the fontcap for use by freetype, and have a new
font list function for use by OS native font routines.

Personally, I doubt that it's worth going beyond whatever the "system"
API provides. Well, other than providing the ability to use the stroke
fonts. At present, the driver's Font_{list,info} methods override the
generic methods. Ultimately, they should be merged, so that stroke
fonts are implemented by the driver library using the driver's
polyline method while other fonts are implemented within the driver.

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

13

On 10/08/08 11:50, Glynn Clements wrote:

Glynn Clements wrote:

Another potentially disruptive update: the raster library now uses
floating point values for coordinates.

Next update: the cairo driver is now the default, assuming that GRASS
was built --with-cairo. If you haven't been enabling this, now is the
time to try, as the PNG driver may not be around for much longer.

It's still possible to force the PNG driver to be used by setting
GRASS_RENDER_IMMEDIATE=PNG.

At present, it uses the "toy" font backend, which means that it only
understands a limited set of fonts (AFAICT, it understands mono, serif
and sans, and -bold and -italic variants), although support for
FreeType and stroke fonts will be added soon.

Seems to work great on the command line (aside a few questions below), however, there seems to be problems in the guis:

- tcltk gui (gis.m): I cannot display any vector maps; raster map display becomes very slow when zooming out, with memory usage rising steadily

- wxpython gui: I can display vector maps, but as soon as I ask not to display centroids, nothing is displayed at all

And here a few questions:

- How do I configure which format the cairo driver writes to (i.e. other than PNG) ? GRASS_CAIROFILE doesn't seem to work:

GRASS 7.0.svn (nc_spm_06):~ > export GRASS_CAIROFILE=map.ps
GRASS 7.0.svn (nc_spm_06):~ > d.rgb r=blend.r b=blend.b g=blend.g
cairo: collecting to file: map.png

- How to tell it to read from an existing file ? Again, GRASS_CAIRO_READ doesn't seem to work.

Moritz

14

Moritz Lennert wrote:

>> Another potentially disruptive update: the raster library now uses
>> floating point values for coordinates.
>
> Next update: the cairo driver is now the default, assuming that GRASS
> was built --with-cairo. If you haven't been enabling this, now is the
> time to try, as the PNG driver may not be around for much longer.
>
> It's still possible to force the PNG driver to be used by setting
> GRASS_RENDER_IMMEDIATE=PNG.
>
> At present, it uses the "toy" font backend, which means that it only
> understands a limited set of fonts (AFAICT, it understands mono, serif
> and sans, and -bold and -italic variants), although support for
> FreeType and stroke fonts will be added soon.

Seems to work great on the command line (aside a few questions below),
however, there seems to be problems in the guis:

- tcltk gui (gis.m): I cannot display any vector maps; raster map
display becomes very slow when zooming out, with memory usage rising
steadily

- wxpython gui: I can display vector maps, but as soon as I ask not to
display centroids, nothing is displayed at all

Can you get the GUI to display the exact commands being used, and
check whether the problem exists when the command is run from the
shell?

And here a few questions:

- How do I configure which format the cairo driver writes to (i.e. other
than PNG) ? GRASS_CAIROFILE doesn't seem to work:

GRASS 7.0.svn (nc_spm_06):~ > export GRASS_CAIROFILE=map.ps
GRASS 7.0.svn (nc_spm_06):~ > d.rgb r=blend.r b=blend.b g=blend.g
cairo: collecting to file: map.png

- How to tell it to read from an existing file ? Again, GRASS_CAIRO_READ
doesn't seem to work.

I changed it to use the same variables as the PNG driver, i.e.
GRASS_PNGFILE, GRASS_PNG_READ, etc. Specifically:

  GRASS_CAIRO_DRAWABLE
  GRASS_CAIRO_VISUAL
  GRASS_PNGFILE
  GRASS_PNG_MAPPED
  GRASS_PNG_READ
  GRASS_BACKGROUNDCOLOR
  GRASS_TRANSPARENT
  GRASS_PNG_AUTO_WRITE

[You can ignore the first two; I don't even know if that feature works.]

It is supposed to be a drop-in replacement for the PNG driver, but
there may well be factors which I have overlooked.

Also, the changes to the display library may have broken stuff. If you
find a command which doesn't work as expected, it's worth trying it
withe GRASS_RENDER_IMMEDIATE=PNG to determine whether the problem is
caused by the cairo driver or by the changes to the display library.

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

15

On 12/08/08 02:22, Glynn Clements wrote:

Moritz Lennert wrote:

Seems to work great on the command line (aside a few questions below), however, there seems to be problems in the guis:

- tcltk gui (gis.m): I cannot display any vector maps; raster map display becomes very slow when zooming out, with memory usage rising steadily

Have to correct this: the behaviour is exactly the same as with the wxpython gui: only if centroids are asked for, the map is displayed. The difference was that the wx-gui displays centroids by default, whereas the tcltk gui doesn't.

- wxpython gui: I can display vector maps, but as soon as I ask not to display centroids, nothing is displayed at all

Can you get the GUI to display the exact commands being used, and
check whether the problem exists when the command is run from the
shell?

Nope, everything runs fine from the shell, with e.g. the following command:

d.vect map=boundary_county@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

But nothing shows up in the tcltk Map Display.

Looking at the different layers which are input into g.pnmcomp:

g.pnmcomp in=24212.2.ppm mask=24212.2.pgm opacity=1.00 background=255:255:255 width=642 height=256 output=24212.1.ppm

both 24212.2.ppm and 24212.2.pgm show up completely black and 24212.1.ppm completely white.

Idem with a line layer:

d.vect map=elev_contour_3m@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,centroid,area,face icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

works perfectly on the command line, but cannot display in either gui. What I do see, though is a straight vertical line at the far right of the display area.

I changed it to use the same variables as the PNG driver, i.e.
GRASS_PNGFILE, GRASS_PNG_READ, etc. Specifically:

  GRASS_CAIRO_DRAWABLE
  GRASS_CAIRO_VISUAL
  GRASS_PNGFILE
  GRASS_PNG_MAPPED
  GRASS_PNG_READ
  GRASS_BACKGROUNDCOLOR
  GRASS_TRANSPARENT
  GRASS_PNG_AUTO_WRITE

Ok, thanks. Tried GRASS_PNG_READ and it works perfectly.

[You can ignore the first two; I don't even know if that feature works.]

It is supposed to be a drop-in replacement for the PNG driver, but
there may well be factors which I have overlooked.

So, nothing else but PNG for now ?

Also, the changes to the display library may have broken stuff. If you
find a command which doesn't work as expected, it's worth trying it
withe GRASS_RENDER_IMMEDIATE=PNG to determine whether the problem is
caused by the cairo driver or by the changes to the display library.

Ok.

Moritz

16

Moritz Lennert wrote:

> Can you get the GUI to display the exact commands being used, and
> check whether the problem exists when the command is run from the
> shell?

Nope, everything runs fine from the shell, with e.g. the following command:

d.vect map=boundary_county@PERMANENT color=0:0:0 lcolor=0:0:0
fcolor=170:170:170 display=shape type=point,line,boundary,area
icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

This produces a blank image with the cairo driver, but works with the
PNG driver. I'll look into it today.

Idem with a line layer:

d.vect map=elev_contour_3m@PERMANENT color=0:0:0 lcolor=0:0:0
fcolor=170:170:170 display=shape
type=point,line,boundary,centroid,area,face icon=basic/circle size=5
layer=1 lsize=8 xref=left yref=center llayer=1

ERROR: Vector map <elev_contour_3m@PERMANENT> not found

works perfectly on the command line, but cannot display in either gui.
What I do see, though is a straight vertical line at the far right of
the display area.

I suspect that's just the code which draws a border around the current
frame.

> It is supposed to be a drop-in replacement for the PNG driver, but
> there may well be factors which I have overlooked.

So, nothing else but PNG for now ?

It supports PPM/PGM, BMP (32-bpp, can be mapped) and PNG image
formats, as well as PDF, PS and SVG vector formats, and output to an
X11 drawable. I haven't tested the last one, but all of the file
output cases work. For the above test case, the vector formats work
even without the centroids.

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

17

Glynn Clements wrote:

> > Can you get the GUI to display the exact commands being used, and
> > check whether the problem exists when the command is run from the
> > shell?
>
> Nope, everything runs fine from the shell, with e.g. the following command:
>
> d.vect map=boundary_county@PERMANENT color=0:0:0 lcolor=0:0:0
> fcolor=170:170:170 display=shape type=point,line,boundary,area
> icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

This produces a blank image with the cairo driver, but works with the
PNG driver. I'll look into it today.

It turns out that the polgon/polyline operations weren't setting the
"modified" flag, so the completed image wasn't written to the file.
The centroids were drawn using individual line segments, which do set
the flag.

Fixed in r32731.

For the above test case, the vector formats work even without the
centroids.

Vector formats are written sequentially; a FILE* is specified when the
"surface" is created, and each operation appends data to the stream.

Raster output involves drawing to a framebuffer, which needs to be
explicitly written to a file.

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

18

On 13/08/08 00:43, Glynn Clements wrote:

Moritz Lennert wrote:

Can you get the GUI to display the exact commands being used, and
check whether the problem exists when the command is run from the
shell?

Nope, everything runs fine from the shell, with e.g. the following command:

d.vect map=boundary_county@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

This produces a blank image with the cairo driver, but works with the
PNG driver. I'll look into it today.

So this means that I've been working with the PNG driver ?
IIUC, to switch to cairo, I have to set GRASS_RENDER_IMMEDIATE=cairo ?

Idem with a line layer:

d.vect map=elev_contour_3m@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,centroid,area,face icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1

ERROR: Vector map <elev_contour_3m@PERMANENT> not found

Sorry, must have created that one myself, don't know how this slipped into PERMANENT.
But it was the same for any line layer.

Everything works perfectly now. Thanks !

works perfectly on the command line, but cannot display in either gui. What I do see, though is a straight vertical line at the far right of the display area.

I suspect that's just the code which draws a border around the current
frame.

Now that you put my nose onto it, yes, I can see it in the PNG images also. However, it only shows on the bottom and right, not top and left sides.

Anyhow, do we really want a border to be drawn by default ?

It is supposed to be a drop-in replacement for the PNG driver, but
there may well be factors which I have overlooked.

So, nothing else but PNG for now ?

It supports PPM/PGM, BMP (32-bpp, can be mapped) and PNG image
formats, as well as PDF, PS and SVG vector formats, and output to an
X11 drawable. I haven't tested the last one, but all of the file
output cases work. For the above test case, the vector formats work
even without the centroids.

Works beautifully.

Might be nice option for the GUI: render everything which is listed for display in the Display window into an svg or ps file...

Moritz

19

Moritz Lennert wrote:

>>> Can you get the GUI to display the exact commands being used, and
>>> check whether the problem exists when the command is run from the
>>> shell?
>> Nope, everything runs fine from the shell, with e.g. the following command:
>>
>> d.vect map=boundary_county@PERMANENT color=0:0:0 lcolor=0:0:0
>> fcolor=170:170:170 display=shape type=point,line,boundary,area
>> icon=basic/circle size=5 layer=1 lsize=8 xref=left yref=center llayer=1
>
> This produces a blank image with the cairo driver, but works with the
> PNG driver. I'll look into it today.

So this means that I've been working with the PNG driver ?

If you got a valid image from the above command, it would have been
using the PNG driver. If it was blank, it would be the cairo driver.
Neither will produce error messages; you need to look at the images to
see if it worked.

Also, unless you use --quiet, each driver will display a message upon
startup:

cairo:
  cairo: collecting to file: map.png,
  GRASS_WIDTH=640, GRASS_HEIGHT=480

PNG:
  PNG: GRASS_TRUECOLOR status: TRUE
  PNG: collecting to file: map.png,
  GRASS_WIDTH=640, GRASS_HEIGHT=480

IIUC, to switch to cairo, I have to set GRASS_RENDER_IMMEDIATE=cairo ?

No, cairo is the default. You have to set GRASS_RENDER_IMMEDIATE=PNG
(or build without cairo) to get the PNG driver.

>> works perfectly on the command line, but cannot display in either gui.
>> What I do see, though is a straight vertical line at the far right of
>> the display area.
>
> I suspect that's just the code which draws a border around the current
> frame.

Now that you put my nose onto it, yes, I can see it in the PNG images
also. However, it only shows on the bottom and right, not top and left
sides.

The code adjusts the top and left out by one pixel, but leaves the
bottom and right intact. This was probably done so that the border
would only be visible if the frame was smaller than the "screen".

But the cairo driver doesn't "adjust" coordinates to pixel
boundaries[1], so the bottom and right edges are drawn exactly along
the edge of the window, resulting in a half-pixel-wide line (i.e. a
50%-opacity line due to anti-aliasing).

[1] The older drivers would inherently shift lines half a pixel down
and to the right;. an endpoint at (0,0) would be moved to the middle
of the top-left pixel, i.e. at (0.5,0.5).

Anyhow, do we really want a border to be drawn by default ?

I doubt it. It may have made sense back when multiple frames were
common, but not any more.

I have kept D_show_window() (the function which draws the border) in
case modules want to call it explicitly (only r.le.trace does, and
that doesn't compile at present), but the D_* functions which manage
windows no longer call it.

>>> It is supposed to be a drop-in replacement for the PNG driver, but
>>> there may well be factors which I have overlooked.
>> So, nothing else but PNG for now ?
>
> It supports PPM/PGM, BMP (32-bpp, can be mapped) and PNG image
> formats, as well as PDF, PS and SVG vector formats, and output to an
> X11 drawable. I haven't tested the last one, but all of the file
> output cases work. For the above test case, the vector formats work
> even without the centroids.

Works beautifully.

Might be nice option for the GUI: render everything which is listed for
display in the Display window into an svg or ps file...

There is a separate PS driver (GRASS_RENDER_IMMEDIATE=PS) for
PostScript (which can be converted to PDF with Ghostscript), which
will probably produce better results.

If cairo is presented with anything which can't be represented in
PostScript (e.g. translucency), it falls back to rasterising it and
dumping the raster to a PostScript file. Unfortunately, it sometimes
does this in cases where it doesn't need to.

Also, GRASS_PNG_READ doesn't work with cairo's vector output formats;
it always overwrites $GRASS_PNGFILE, rather than appending.

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