Re: arrow head adjustment

[Hans-Bernhard B. <br...@ph...>]

On Sun, 7 Dec 2003, Daniel J Sebald wrote:

> In my opinion, if arrow tips were to be compensated for,
> it would be nice to have the formula at a high level  so that
> it doesn't need to be implemented multiple times in the
> various drivers.  Perhaps some drivers have an option for
> where the tip should land.  

I don't expect any of them does, at this time.  The majority of them rely
on the common fallback implementation term.c:do_arrow() for this.  It's
mainly the vector graphics file format drivers have their own
implementation.  cscope reports:

../term/debug.trm .*[^o]_arrow 245 DEBUG_arrow(sx, sy, ex, ey, head)
../term/dumb.trm .*[^o]_arrow 385 DUMB_arrow(sx, sy, ex, ey, head)
../term/eepic.trm .*[^o]_arrow 366 EEPIC_arrow(sx, sy, ex, ey, head)
../term/epslatex.trm .*[^o]_arrow 892 EPSL_arrow(xstart, ystart, xend, yend, head)
../term/fig.trm .*[^o]_arrow 771 FIG_arrow(sx, sy, ex, ey, head)
../term/gpic.trm .*[^o]_arrow 217 GPIC_arrow(sx, sy, ex, ey, head)
../term/grass.trm .*[^o]_arrow 618 GRASS_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 639 LATEX_arrow(sx, sy, ex, ey, head)
../term/latex.trm .*[^o]_arrow 650 best_latex_arrow(sx, sy, ex, ey, who, head)
../term/metafont.trm .*[^o]_arrow 466 MF_arrow(sx, sy, ex, ey, head)
../term/metapost.trm .*[^o]_arrow 675 MP_arrow(unsigned int sx, unsigned int sy, unsigned int ex, unsigned int ey, TBOOLEAN head)
../term/pstricks.trm .*[^o]_arrow 399 PSTRICKS_arrow(sx, sy, ex, ey, head)
../term/texdraw.trm .*[^o]_arrow 282 TEXDRAW_arrow(sx, sy, ex, ey, head)
../term/tgif.trm .*[^o]_arrow 569 TGIF_arrow(sx, sy, ex, ey, head)
../term/tpic.trm .*[^o]_arrow 628 TPIC_arrow(sx, sy, ex, ey, head)
../term/vws.trm .*[^o]_arrow 463 VWS_arrow(sx, sy, ex, ey, head)

To top it off, the current way arrow head options are handled is
atrocious.  There is *no* terminal API entry to pass arrow options
through, though there definitely should be.  While adding that, it
should be reasonably easy to pass on the line width to the arrow
drawing routines, too.  It *is* part of the arrow options structure,
after all.  term_api.h on arrow_style_type says:

typedef struct arrow_style_type {    /* contains all Arrow properties */
    int layer;                       /* 0 = back, 1 = front */
    struct lp_style_type lp_properties;
[...]

and the line width is part of struct lp_style_type.

> But it isn't worth doing unless there is some way of addressing
> the line width issue.  Getting back line width information might
> be tough.  However, would it be possible to slightly alter the
> terminal line command so that the line width is specified in plot
> units rather than the somewhat arbitrary "1, 2, 3, 4"?  

No.  That would break plot script compatibility, while being almost
certainly un-necessary.  As far as I'm aware, all terminal drivers already
do have default-line width == 1 terminal unit anyway (with exceptions for
the border line type that's usually 2 units wide).

> It could remain "1 2 3 4" from the users' perspective, but first
> translate those to plot units before calling the (*term)->linewidth()
> function.

That's none of the 'set term' command's business to do, nor does it have
the information needed for doing it.  I think not all terminals supporting
variable-width lines even *have* a linewidth option in their terminal
options to begin with. 

The only somewhat reasonable ways I see would be to add a new API function
term->get_linewidth() that reports the current width, in plot units, or to
append to the semantics of term->linewidth(), adding that it should modify
some global variable accordingly, which is initialized by the caller so
most implementations can remain unchanged.  This shouldn't be overly hard,
as term->linewidth() is only called in rather few places to begin with.  
According to cscope:
 
6 mouse.c      event_buttonrelease      1522 (term->linewidth) (border_lp.l_width);
7 term.c       term_apply_lp_properties  615 (*term->linewidth) (lp->l_width);
a term.c       test_term                1592 (*t->linewidth) (1.0);
b term.c       test_term                1717 (*t->linewidth) (1.0);
c term.c       test_term                1740 (*t->linewidth) ((float)(i));
d term.c       test_term                1754 (*t->linewidth) ((float)(1));

> The question then is, will the terminal achieve the specified line
> width, or will it only approximate it?  In the latter case, we are no
> further along.

If the terminal doesn't do an accurate job, that's too bad.  I don't think
it's worth bothering about such terminals in terms of how to manage nicely
drawn arrows for them.  The risk of making already inaccurate outputs even
worse are essentially negligible, I'd say.  If all else fails, they could
still be fixed by reporting an effective linewidth of zero plot units, and
thus reverting to the current behaviour.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.