[GRASS5] g51 v.digit

[Glynn Clements]

John A. Preston wrote:

> Actually the GD library does support thick lines with various styles which
> I have modified d.vect to use.

OK. I was looking for something that mentioned "line", "width" or
"thickness"; gdImageSetBrush() didn't register. That won't play nicely
with dashed lines, though (i.e. the result will be significantly
different to how other graphics APIs handle thick, dashed lines).

> However the issue of the 
> style of the joints is not handled and GRASS itself 
> does not seem to optimise the output of vector display points to the
> driver.
> 
> Currently I see where to draw a line from point A to point B
> GRASS sends all the coordinates of the points that make up the line.

This doesn't appear to be a driver issue. Each call to
R_cont_{abs,rel} should result in a single call to gdImageLine()
within the PNG driver.

However, I don't think that e.g. d.vect will attempt to "optimise"
paths, i.e. merge adjacent colinear segments into a single line. So,
if the actual vector map is comprised of many small segments, that's
the way that it will get drawn.

> However all these points are in a lot of cases 1 pixel apart and thus to 
> implement a line style scheme I would have to drop various
> consecutive points while displaying the others. I don't find
> this particularly scalable, and was wondering whether
> the move to change the drawing API would address this case.
> 
> Also as most of my work with GRASS involves creating images
> for remote display or hardcopy I wanted to find out whether the
> new API for the drawing functions would work well for these cases.

The new API is currently at the drawing board stage.

My preference would be a framework, within which individual modules
would be free to generate arbitrary PostScript objects (in the sense
of %%BeginObject/%%EndObject). Others may have different views, and
I'm open to suggestions.

However, I am keen to ensure that hardcopy is well supported (which
basically boils down to ruling out anything which involves explicit
rasterisation, "pixel" coordinates, or "thin" lines).

-- 
Glynn Clements <glynn.clements at virgin.net>