[GRASS5] g51 v.digit

[Glynn Clements]

John A. Preston wrote:

> > > I really would like to join a task force for the implementation of 
> > > a) a Generic Display API (GAPI)
> > > b) the gtk+ Display System (GDS)
> > > 	e.g. it may be possible to revamp some NVIZ togl code for 
> > > 	GDS
> > > 
> > > What I personally don't want to see is some kind of monster application
> > > that needs 5 minutes to start just to change location
> > > so we should keep the console based variants as well (grass scripting 
> > > is really fun and beats most of the commercial click-ware interfaces
> > > both in routine (production) and experimental work)
> > > 
> > > It should be more like the tcltkgrass toolbar with plugins/modules
> > > for each grass command
> > > 
> > > like d.rast,v,rast,d.dm,nviz,d.* etc  -> main display routine
> > > with helper plugins/modules for typical console work
> > > 
> > > (just to keep the single system feeling)
> > 
> > Output-only programs (i.e. most of the d.*) commands aren't really a
> > problem; they will fit into any architecture.
> 
> What about the case of the CELL and PNG drivers where you want to
> generate an image?

What about it? I don't really understand the question.

> I currently use a version of the PNG driver to do
> this and I wish to add features for the display of vectors in other
> than single solid line (size, style etc).

The PNG driver relies upon the GD library, which doesn't support
"thick" lines. More generally, allowing thick lines introduces a lot
of issues which don't apply to thin lines, e.g. corner and end styles
(round, butt, mitred) and whether/how those styles apply to dashed
lines etc.

That's part of the reason for my initial preference for PostScript. It
has a high level of functionality and can be used for display,
hardcopy and image output. The down side is that there is some
functionality which is available in display/image drawing APIs which
can't be implemented in PostScript due to the write-only framebuffer.

Most graphics APIs follow a similar pattern; a set of drawing
primitives, plus a set of parameters which modify the effect of
drawing primitives. The overall nature of the APIs doesn't differ
much.

Provided that the underlying graphics API provided the necessary
functionality, it wouldn't be particularly difficult to add more
functions to the raster library (e.g. R_set_line_width()).

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