Re: line corners with terminals for vector graphics

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

On 2/5/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > 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.
>
> There's no sane reason for implementing any "workaround" for this ---
> the terminal driver API already *has* a polyline function.  That's why
> we have two functions, term->move() and term->vect(), instead of a
> single term->draw_line(from,to).  Each term->move() conceptually starts
> a new polyline, each term->vect() extends it by one leg, any other call
> but term->vect() ends it.
>
> We don't need a term->polyline().  The only thing needed to complete
> the existing API in this area would be a term->closecycle() or some
> such, to distinguish between open and closed polylines.

Thanks. It should also be described in the documentation that way.
It's not mentioned anywhere that every command other than vect() ends
a line. I thouht that
    move(0,0)
    vect(1,2)
    linetype(2)
    vect(0,1)
or
    move(0,0)
    vect(1,2)
    put_text(3,3,"abc")
    vect(0,1)
was a valid sequence of commands (according to your description it's
not). I followed the code sample in metapost.trm, which handles that
case "properly" (breaks the line in first case and continues the line
in the second case). Also,
    move(0,0)
    vector(1,1)
    move(1,1)
    vector(2,1)
would draw a continuous line in metapost rather than two separate ones.


However, move() and vector() lead to much more dirty code in terminals
in comparison to polyline(). Move starts the line, which is OK, but
EVERY other command has to start with
    if(we're inside a line)
        finish that line first

After some thinking I figured out that polyline() instead of move()
and vector() would be less memory-efficient for extremely long lines,
but at least an "endline(bool closed)" could help cleaning up some
code. endline(false) would reduce the need for an additional "if" in
just about every function and endline(true) would be a magic
combination which would fix the reported "bug" without additional
trickery in the terminals.

(I'm sorry for a sking a stupid newbie question: how many bytes can be
assumed for int? IE: may xmax and ymax exceed 32000?)

Thanks,
    Mojca