[GRASS5] symbol plotting

[Hamish]

Hi,

just having a quick look at what is involved with making d.vect's symbol
drawing code into a library function.

-- sorry about the mess, a few issues here.


I notice that d.vect's plot1.c uses G_plot_polygon():

/* Note: it may seem to be strange to calculate coor in pixels, then
   convert to E-N and plot. I hope that we get some D_polygon later. */

Were the ones in the raster lib just missed (R_polygon_abs(), etc.), or is
there another reason to do it this way?

e.g., when to use:

D_move_abs(x,y)
D_cont_abs(x,y)

and

R_move_abs(x,y)
R_cont_abs(x,y)

??

We could do D_() wapper fns for the other R_() fns, but is there a
point? Does clipping matter? If it does, make wrapper fns as needed?
Do we want a D_symbol() fn to be clipped (speed up plotting of LIDAR data)?
I finally realize that the raster lib has nothing to do with raster maps,
only rasterized drawing to the display.

---

To get a symbol drawing lib fn working I've called it S_plot(), not 
D_symbol():

int S_plot(SYMBOL *Symb, int x0, int y0, SYMBCOLOR *line_color, SYMBCOLOR *fill_color)

as I don't want the display lib to have to depend on the symbol.h header. 
Or is that ok?  (size, rotation are taken care of by S_stroke().)

any clean way to get/save current RGB color from the driver?

Currently the code is working, but too ugly to live.

---

in lib/gis/plot.c:

/* NOTE (shapiro):
 *   I think the adding of 0.5 in slowline is not correct
 *   the output window (left, right, top, bottom) should already
 *   be adjusted for this: left=-0.5; right = window.cols-0.5;
 */

.. for plot((int)(x+0.5), (int)(y+0.5)) style rounding.

so is all the (int)(x+0.5) stuff the in display modules wrong?
this stuff makes my head hurt.

---

lib/display/draw.c:  are the comments to D_set_clip_window() wrong?

  * Sets the clipping window to the pixel window that corresponds
- * to the current database region. This is the default.
+ * to the given display pixel coordinates.




thanks for any hints,
Hamish