[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

S-Bören Gebbert wrote:-A

> >> I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are
> >> are smoothed by the PS driver.
> >>
> >> I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work,
> >> but i needed to add some memory allocation stuff, so the memory usage is a bit higher
> >> and it should be a bit slower than the G_plot_line approach (with move and cont functions).
> >>
> >> Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS.
> > 
> > Unfortunately, there's a bit more to it than that.
> > 
> > 1. G_plot_line handles longitude wrap-around (try plotting something
> > which crosses the 180th meridian).
> > 
> > 2. G_plot_line is using D_{move,cont}_abs(), which clip against the
> > frame (try using a square region, so that there are blank bands on the
> > left and right sides of the monitor).
> > 
> > I already had to deal with something similar for filled polygons; see
> > plot_polygon() at the top of plot1.c, and the render= option.
> > 
> > FWIW, I've already added a D_polyline_clip() function, which should
> > handle both of the above issues (although it hasn't been extensively
> > tested).
> > 
> > I would suggest adding a plot_polyline() function which uses either
> > the render= setting or a separate option (e.g. lrender=). That allows
> > people to compare the new implementation against the old one without
> > having to keep an old version of d.vect around.
> > 
> 
> Done. The patch is attached.

I intend to apply this, subject to a few changes:

plot_poly{gon,line} aren't declared "inline", as the "inline" keyword
isn't ANSI C89 (C99 and GCC extension), and there isn't much benefit
to inlining in this case.

The option descriptions use the ->descriptions field; embedding
formatting information in the ->description field is unsupported (e.g. 
it may not work with --tcltk, --html-description etc).

The G_plot_line() loop uses array indexing rather than pointer
arithmetic, as the former tends to be easier to read.

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