Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-07 22:56:35
|
On Fri, 5 Dec 2003, Daniel J Sebald wrote: > Did anyone have any ideas for getting the > width of a line in terms of plot units from the > terminal? I don't think there is any generic way of doing that. There's an awful lot of copy-pasted code in the terminal drivers which just has different variable names, and no generic data structure for internal variables even for cases like this that could use common basic routines like "do_linewidth_by_saving_value()" as their term->linewidth() API implementation. It may not even be the case that all relevant drivers _have_ the linewidth stored in any variable in the first place. PostScript-like ones could just have written out a postscript command that sets the linewidth and forgot about it... This may need a re-design of at least the arrow-drawing part of the terminal API to work it out. |
|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-08 12:35:25
|
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.
|
|
From: Daniel J S. <dan...@ie...> - 2003-12-08 15:04:58
|
Hans-Bernhard Broeker wrote: >>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. > That's a good idea. Dan |
|
From: Daniel J S. <dan...@ie...> - 2003-12-08 02:23:10
|
Hans-Bernhard Broeker wrote: >On Fri, 5 Dec 2003, Daniel J Sebald wrote: > > > >>Did anyone have any ideas for getting the >>width of a line in terms of plot units from the >>terminal? >> >> > >I don't think there is any generic way of doing that. There's an >awful lot of copy-pasted code in the terminal drivers which just has >different variable names, and no generic data structure for internal >variables even for cases like this that could use common basic routines >like "do_linewidth_by_saving_value()" as their term->linewidth() API >implementation. > >It may not even be the case that all relevant drivers _have_ the linewidth >stored in any variable in the first place. PostScript-like ones could >just have written out a postscript command that sets the linewidth and >forgot about it... > >This may need a re-design of at least the arrow-drawing part of the >terminal API to work it out. > I think your assessment is correct. 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. It might be wise to see how they all perform before concluding on the best approach. 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"? It could remain "1 2 3 4" from the users' perspective, but first translate those to plot units before calling the (*term)->linewidth() function. 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. Dan |
Thanks for helping keep SourceForge clean.
X