[GRASS5] g51 v.digit

[Glynn Clements]

John A. Preston wrote:

> > 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.
> 
> But I think that some component of the display architecture should have
> this to be able to provide good quality output .

For most graphics APIs, it wouldn't make any difference to the
quality, although it might make a difference to the performance.

AFAICT, the problem which you are reporting is specific to the way
that GD handles line drawing. Most "real" graphics APIs support
drawing "polylines" in such a way that properties such as the dash
phase carry over between line segments, so it wouldn't make any
difference.

> > 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.
> 
> I like that. Would it be possible to include the capabiity of merging adajacent segments
> somewhere here?

Well, you could add such an option to d.vect easily enough; that
wouldn't depend upon any particular graphics API.

The main problem is that such a feature would have to be under user
control, particularly if you start supporting vector formats such as
PostScript. Two line segments may appear colinear on a 75 DPI screen
but have a distinct corner on a 600 DPI hardcopy.

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