Re: line corners with terminals for vector graphics

[Mojca M. <moj...@gm...>]

On 2/2/06, Ethan A Merritt wrote:
> On Wednesday 01 February 2006 06:22 pm, Mojca Miklavec wrote:
> >
> > I experienced some problems with MetaPost driver recently when drawing
> > a function similar to sin(1000*x), ie. with sharp turns up and down.
> > MetaPost draws a continuous line instead of isolated line segments,
> > which is OK and even much better in most cases. But it uses "sharp"
> > corners (instead of the rounded ones) which then stick out way above
> > and below the line where the function passes through. (I have to check
> > how this is solved in PostScript.)
>
> Postscript has a command "setlinejoin" which selects either
> mitred, rounded, or beveled corners.
>         http://www.capcode.de/help/setlinejoin
>
> Gnuplot's postscript driver allows you to select either
> "rounded" or "butt" (really mitred) in the "set term" command.
> Mike Sutton recently contributed an equivalent for the png/gif/jpeg
> driver.  The plan is to add the same option to additional terminal
> types if they can support it.

(Metapost should support that option too: currently it's hardcoded.)

One of my question was also: is it possible to set different linejoin
for different elements? It's for example best if rectangular elements
keep "mitered" linejoins, while function could be drawn with rounded
linejoins if needed. This is one of the things that a terminal can't
do. A terminal can solve the problem with closed paths (below), but
can't guess if the line being drawn is a function or a frame (unless I
try to draw the lines of type -1 and -2 with mitered linejoin and the
rest with the rounded ones).


On 2/2/06, Ethan Merritt wrote:
> On Thursday 02 February 2006 10:44 am, Hans-Bernhard Br=F6ker wrote:
> > Ethan Merritt wrote:
> > > I understand.  However, if you choose
> > >     set term post rounded
> > > then this corner is rendered identically to the others.
> > > This is one advantage of choosing the rounded joins and caps.
> >
> > It's also a rather indirect approach that only fixes the symptom, not
> > the problem.  Why should people be restricted to using round joins
> > just to get a non-silly display of the graph box?
>
> [shrug]
> Different problems may require different solutions.
>
> I took Mojca's question to be along the lines of "what could the
> metapost driver do differently?".  So I gave a driver-oriented
> answer.  For the very specific case of drawing the plot border,
> we could of course have the core code draw 1 + 1/8 of the
> way around the perimeter, which should give a clean join at
> all 4 corners.  That change would not help any other line joins,
> however.
>
> We could think about adding a new terminal entry
> point term->polyline(), which could handle this case and also
> draw nice boundaries around term->filled_polygon() areas.
> 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.
>
> On the other hand, even if we did this the joins at
> the endpoints of separately drawn vectors would be a problem.
> E.g. when 2 or 3 zero-axis lines meet at the origin.
> E.g. when different segments of a continuous line plot are
>         drawn separately so that they can have different colors.

If three lines of different color meet in the same point, there's no
solution anyway, I'm afraid.

At the very beginning I wanted to ask for an additional function
(polyline), but then I figured out that the Metapost terminal has a
nice workaround for it: it always saves the last point and if the next
line continues in the same point (without changing line type or color
inbetween), it draws a continuous path rather than two separate lines.

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.

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.

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.
Not many terminals could make use of it (perhaps PostScript-based
ones, PDF and ConTeXt if author of ConTeXt's adds some trickery), but
I guess that the source wouldn't need so many changes to calculate the
color in edges of polygons.

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).

Thanks a lot,
    Mojca