Re: line corners with terminals for vector graphics

[Ethan A M. <merritt@u.washington.edu>]

Mojca Miklavec <moj...@gm...> wrote:

> > Or these call sites could also use the method above --
> > draw a polygon boundary as N + 1/2N segments and let the
> > driver merge these into a polyline if possible.

I have decided that I do not like this option, because it
will look bad on pen plotters.  Of course maybe no one has
a pen plotter any more...

> In the terminal I'm currently writing (which is almost the same as
> metapost) I did the same for the first & last point: I save the first
> point and when I draw the next line segment I check if the last point
> is the same as the first one. In that case I "close" the line. There
> might be exceptions to this rule of course where the results are only
> suboptimal, but this will at least draw the border properly in 99%
> cases.

I have been trying the same thing in the PostScript driver.
It works fine for rectangles, but I must have failed to consider
some reasonably common case because several of the demo plots
no longer work correctly.  If I get the demos working 100%, I'll put
the patch on SourceForge so everyone can try it out.

> However, adding a new function like polyline(int npoints, int
> points[n][2], bool closed) would still be a cleaner solution. If a
> driver doesn't support it, it can still be drawn with n separate
> lines.

That assumes the points are all known in advance of the driver call.
That is probably always true for rectangles, but not for a general
closed curve plot.  So we would have to add a layer in the core code
that accumulates a complete curve.  I think.  Maybe there's a clever
way around it.   But in any event, I suspect that adding new core code
and adding a new driver entry to N drivers is going to be more work
than teaching the few drivers who care to recognize short closed
paths on the fly.

> I still have to study the 3d drawing capabilities in gnuplot, but I
> have a feeling that there's no function yet for drawing a polygon with
> colors specified in the corners, so that smooth shading could be used
> to get proper feeling of 3d (without "annoying" steps in shading). See
> http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch14.pdf for example.

This has come up before, although there wasn't much discussion.
To the best of my knowledge, only the svg driver could easily support
this.  It would be possible in TrueColor png and jpeg output, but it
would require adding some pretty messy code to gd.trm. I did look into
that at one point, and decided it was far too much trouble. I am not
enough of a PostScript guru to know how one might do it there.

> With quite some additional effort the bitmap terminals could be
> improved in that sense as well (each pixel could have the "proper"
> color; not really ray-tracing, but something similar).

I am CC'ing Dan Sebald on this one, because it occurs to me there's
an off chance that one could implement this by piggy-backing on his
"with rgbimage" code.  It might be possible to use libgd
to create the desired gradient-filled rectangle in memory, and then
feed that pixmap to any driver with a term->image entry point.

Daniel, do you think that might work?  If so, it would have the
major advantage of being an almost entirely separate code module.
If we're lucky, we might not have to touch individual drivers at
all.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742