[GRASS-dev] 7.x Status Update

[Glynn Clements]

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 at 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 at gclements.plus.com>