Menu
▾
▴
gnuplot-beta
|
From: Alan G I. <ai...@am...> - 2003-10-21 07:54:03
|
On Mon, 20 Oct 2003 08:32:53 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > I thought some more about the issue of where an arrow should > terminate, and I have decided that I disagree with Alan's premise. > It is not correct that the tip of the arrowhead should terminate > immediately before the (x,y) coordinate it is drawn "to". > I can see two cases to be considered: > 1) The arrow exists for the purpose of indicating a certain (x,y) > point with great precision. In this case an arrow is entirely the > wrong visual aid. Instead one should place a dot, cross, or > circle on the point being indicated > 2) The arrow is pointing toward some feature of interest on the plot. > In this case it is proper for the arrow head to stop well before the > actual point being indicated, since it is best not to obscure the > immediate neighborhood of the point itself. > Arrows are not special. All line segments should have the same > properties, and all other line segments terminate precisely on > top of the (x,y) points they connect, where "on top of" means that > the finite thickness of the line causes it to extend beyond the > precise (x,y) coordinates in all directions. If I understand Ethan, he thinks arrows should be shortened even more than I do. But I still disagree. Basic user interface issue: set arrow from ptA to ptB will be expected to do precisely that: start at ptA and end at ptB. *If* this is the provided behavior, the user can always adjust these points appropriately to achieve the effects Ethan mentions in 2). Basic issue of cooperation: let the user apply arrows however they desire. Just make it easy to do so. (E.g., let the user decide if an arrow is an appropriate visual aid for his/her purpose.) Example: 'plot with vectors' will be badly screwed up if the vectors do not start and stop exactly where they should. Basic implementation issue: there should be no ambiguity about what "from" and "to" mean. Additionally, for filled arrows (and on capable terminals *all* heads can be drawn as filled) this keeps the drawing computations as simple a possible. (Related to this: an arrow without a head should start and stop and the same precise location as an arrow with a head!) Finally, on the interpretation of where an arrow goes, I am not proposing an idiosyncratic interpretation. To the contrary, I believe it is very standard. (Compare e.g. the LaTeX picture environment.) And contrary to Ethan's claim, I argue that this provide a good match for how lines are handled. Lines are generally expected *not* to project beyond the path endpoint. Using PostScript terminology, the natural presumption is a butt cap, and this is the natural default. Ethan seems to be suggesting that choosing a projecting square cap should be the default. I cannot recognize this as a standard practice. But after all is said and done, they key issue is: what will users expect, and what makes it easiest for them to achieve precisely what they desire in a predictable fashion? I was personally startled to find that arrows project past their assigned end point, so my view is obviously that this is unexpected and undesirable behavior. What is more, with this behavior it is essentially impossible for me to make an arrow terminate precisely where I wish it to. This too is very undesirable. Finally, with the new flexibility for arrowheads, the termination of the arrowhead will become even harder for a user to anticipate since it will change with the angle used for the arrowhead. If there were implementation issues that spoke against this, I would understand some hesitancy. But implementation is actually simplified for filled heads. (And *all* heads can be filled on capable terminals.) For nofilled heads it is basically a matter of computing the mitre to offset the head and the shaft length. Cheers, Alan Isaac |
|
From: Hans-Bernhard B. <br...@ph...> - 2003-11-01 17:32:49
|
On Fri, 31 Oct 2003, Alan G Isaac wrote: > I found two widespread conventions: > i. The arrowhead ink ends right at the point the arrow is > drawn to. This is the convention that I have been pushing > for. > ii. The arrowhead ink ends right at the edge of a filled > circle, the center of which is the point that the arrow > is drawn "to". I find this odd conceptually, but I confess > it does produce some nice looking graphics. These two conventions aren't necessarily all that different as they appear. Think of the first as a special case of the second, with the curve radius of the tip reduced to zero --- or more precisely to some value too small to be visible as a round tip, so it appears sharp. Obviously, this also requires to interpret the tip radius as a feature independent of the arrow linewidth. Summing it up, the core problem all around is that arrows shouldn't ever have been drawn using wide lines in the first place. > However due to case (ii) above---a case that Ethan first > drew my attention to---it seems it would also be useful to > introduce a new option for set arrow: "point", which would > work like similarly to how it does for label. Or, more generally, consider a global terminal-wide option like the postscript one for mitered vs. rounded joins of polyline, and work from there onward. Note that quite a collection of terminal drivers don't even offer a choice like that. IOW: we're looking at a pile of work here. > "offset" (interpreted as a shortening of the arrowlength) > which would be specified in pointsize units. That offset would be to specific. > (I guess one > might be wanted at each end, in which case there could also > be an option "points" that accepts two numbers an offset, > one for each end.) > > fwiw, > Alan > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Alan G I. <ai...@am...> - 2003-11-01 19:22:30
|
> On Fri, 31 Oct 2003, Alan G Isaac wrote: >> I found two widespread conventions: >> i. The arrowhead ink ends right at the point the arrow is >> drawn to. This is the convention that I have been pushing >> for. >> ii. The arrowhead ink ends right at the edge of a filled >> circle, the center of which is the point that the arrow >> is drawn "to". I find this odd conceptually, but I confess >> it does produce some nice looking graphics. On Sat, 01 Nov 2003, () Hans-Bernhard Broeker apparently wrote: > These two conventions aren't necessarily all that different as they > appear. Think of the first as a special case of the second, with the > curve radius of the tip reduced to zero --- or more precisely to some > value too small to be visible as a round tip, so it appears sharp. > Obviously, this also requires to interpret the tip radius as a feature > independent of the arrow linewidth. You appear to be describing a 3rd case, that I didn't come across. Here is what I hear you saying: iii. arrowhead has a rounded rather than sharp tip. If (iii) is what you meant, I would still expect the ink not to pass the point the arrow is drawn "to" (in the direction of the arrow). What I meant by (ii) is perhaps better captured by: (ii') a filled circle with radius 'r' centered on the "to" point 'ptB' is drawn, and then the arrow from ptA to ptB is drawn so that its very tip ends at the edge of the filled circle. Thus the arrow length will be 'r' less than the distance from ptA to ptB. As I said, I personally find the practice a bit odd, bit it appears reasonably common. (I also came across this practice for headless arrows. E.g., construct a line segment between two points.) It is still the case that (i) is a special case of (ii') with r=0. > Summing it up, the core problem all around is that arrows > shouldn't ever have been drawn using wide lines in the > first place. I agree with this principle, but of course on terminals that do not support filling one can still draw thick lines but then shorten the arrow by the miter length. One odd thing about the current PostScript terminal is that it draws a filled head and then "outlines" it with a thick line, and it is only the superfluous outline that causes ink to extend past the "to" point. If this is true of all terminals supporting filling, then filled arrowheads at least will be simple to fix. (Of course, as you have indicated, on such terminals *all* arrowheads could be drawn as filled outlines.) Cheers, Alan PS One last thing I just want to mention again since I do not recall any discussion of it: the 'vectors' plotting style will only produce sensible results if the ink for each vector starts and stops at exactly the specified points. I suppose this is currently addressed to a certain extent by refusing to honor 'linewidth' for plots in the 'vectors' style. (But shouldn't 'linetype' be allowed for color selection?) |
|
From: Hans-Bernhard B. <br...@ph...> - 2003-11-01 19:41:11
|
On Sat, 1 Nov 2003, Alan G Isaac wrote: > > On Fri, 31 Oct 2003, Alan G Isaac wrote: > >> I found two widespread conventions: > >> i. The arrowhead ink ends right at the point the arrow is > >> drawn to. This is the convention that I have been pushing > >> for. > >> ii. The arrowhead ink ends right at the edge of a filled > >> circle, the center of which is the point that the arrow > >> is drawn "to". I find this odd conceptually, but I confess > >> it does produce some nice looking graphics. > > On Sat, 01 Nov 2003, () Hans-Bernhard Broeker apparently wrote: > > These two conventions aren't necessarily all that different as they > > appear. Think of the first as a special case of the second, with the > > curve radius of the tip reduced to zero --- or more precisely to some > > value too small to be visible as a round tip, so it appears sharp. > > Obviously, this also requires to interpret the tip radius as a feature > > independent of the arrow linewidth. > > You appear to be describing a 3rd case, that I didn't come > across. Here is what I hear you saying: > iii. arrowhead has a rounded rather than sharp tip. Sort of. The tip is *always* rounded, because truly sharp objects don't exist in the real world. The only question is the radius of the rounded tip. In your listing: (i) radius << linewidth, and too small to be visible (ii) radius == linewidth (iii) radius somewhere in between > If (iii) is what you meant, I would still expect the ink not > to pass the point the arrow is drawn "to" (in the direction > of the arrow). I don't think so. The question is why you drew an arrow, and how the average reader would read the resulting plot. If the tip is visibly rounded, the most obvious position to be read out of it would indeed be the center of that arc, not some point on it, because it'd be hard to tell where on the arc that should be. > What I meant by (ii) is perhaps better captured by: > (ii') a filled circle with radius 'r' centered on the "to" > point 'ptB' is drawn, and then the arrow from ptA to ptB is > drawn so that its very tip ends at the edge of the filled > circle. I don't think I've seen anything like that, nor did I understand your earlier description to mean this. Rather like this: draw the arrowhead as two wide lines with a round join vertex at the 'to' position, i.e. the outer flanks of the arrowhead end tangentially on the arc that forms the very tip, and connects the two flanks. > I agree with this principle, but of course on > terminals that do not support filling one can > still draw thick lines but then shorten the arrow > by the miter length. Odds are such simplistic terminal drivers would *still* get it wrong --- Esp. if they don't really support polylines at all, and thus cannot possible create a miter join. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Alan G I. <ai...@am...> - 2003-11-03 06:07:46
|
> On Sat, 1 Nov 2003, Alan G Isaac wrote: >> I would still expect the ink not >> to pass the point the arrow is drawn "to" (in the direction >> of the arrow). On Sat, 01 Nov 2003, Hans-Bernhard Broeker apparently wrote: > I don't think so. The question is why you drew an arrow, and how the > average reader would read the resulting plot. If the tip is visibly > rounded, the most obvious position to be read out of it would indeed be > the center of that arc, not some point on it, because it'd be hard to tell > where on the arc that should be. If we were talking about headless arrows with rounded caps, I would agree with this. (In otherwords, I am certainly not arguing that the caps should be offset for a line segment.) But an arrowhead pins down a sense of direction that eliminates the problem you raise. Consider the attached EPS file. Cheers, Alan %!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 71 49 313 149 %%Pages: 1 %%EndComments %%Page: 1 1 %%BeginDocument: C:/temp.ps %!PS /Helvetica 20 selectfont 72 120 moveto (Which line do I point to?)show 72 72 moveto 288 72 lineto 72 100 moveto 288 100 lineto 6 setlinewidth stroke 288 72 moveto 0 setgray gsave currentpoint translate 0 -12 lineto 24 0 0 12 4 arct 0 12 lineto closepath fill grestore 288 100 moveto 0 -12 rlineto 24 12 rlineto -24 12 rlineto closepath fill 312 50 moveto 0 100 rlineto 307.2 50 moveto 0 100 rlineto 305.5 50 moveto 0 100 rlineto 0.1 setlinewidth 0.5 setgray [3 2] 0 setdash stroke showpage %%EndDocument %%Trailer |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-10-22 04:42:20
|
On Monday 20 October 2003 23:14, Alan G Isaac wrote: > Basic user interface issue: > set arrow from ptA to ptB > will be expected to do precisely that: > start at ptA and end at ptB. Gnuplot does that now. What we are disagreeing about is the meaning of the word "precisely". > Basic implementation issue: > there should be no ambiguity about what "from" and "to" mean. > Additionally, for filled arrows (and on capable terminals > *all* heads can be drawn as filled) this keeps the drawing > computations as simple a possible. (Related to this: > an arrow without a head should start and stop and the > same precise location as an arrow with a head!) But all of this is true right now, so far as I know. You may not like the behavior, but that doesn't mean it is ambiguous. > Finally, on the interpretation of where an arrow goes, I am > not proposing an idiosyncratic interpretation. To the > contrary, I believe it is very standard. (Compare e.g. the > LaTeX picture environment.) =20 But TeX conceives of arrows as characters, and as such they are entirely enclosed within a conceptual character cell. If you want to embed TeX/LaTeX arrows in your gnuplot figure, you can do so using 'set term post enhanced' By contrast think of line segments in gnuplot as a connect-the-dots process: place a dot at the "from" position, place another at the "to" position, then connect them. > And contrary to Ethan's claim, > I argue that this provide a good match for how lines are > handled. Lines are generally expected *not* to project > beyond the path endpoint. Using PostScript terminology, the > natural presumption is a butt cap, and this is the natural > default.=20 People's expectations obviously vary, and this leads to complaints from time to time. In particular, the PostScript and X11=20 implementation of butt caps causes the line segment to terminate along a line perpendicular to the direction of the line segment itself. This means that in general it overshoots the x-coordinate, the y-coordinate, or both, of the "to" specification. There was, for example, a recent complaint here that line segments=20 should never extend beyond the x-coordinate specified; i.e. the line segment fill should always be clipped against a vertical boundary at the endpoints. Furthermore, butt caps cause very ugly line joins. See previous discussions about the use of polylines=20 rather than individual line segments in X11. > Ethan seems to be suggesting that choosing a > projecting square cap should be the default. I cannot > recognize this as a standard practice. No. I personally think that rounded ends are best. But it should be left up to the user, as it is now. =20 > But after all is said and done, they key issue is: what will > users expect, and what makes it easiest for them to achieve > precisely what they desire in a predictable fashion? I was > personally startled to find that arrows project past their > assigned end point But they don't. They extend exactly to the specified=20 endpoint *** to the resolution of the pen used ***. > What is more, with > this behavior it is essentially impossible for me to make an > arrow terminate precisely where I wish it to. I don't see why. Can't you just specifiy a very thin pen width and a filled arrowhead? Stroke the tail of the arrow separately if you want that part thicker. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
|
From: Alan G I. <ai...@am...> - 2003-10-22 04:39:16
|
> On Monday 20 October 2003 23:14, Alan G Isaac wrote: >> Basic user interface issue: >> set arrow from ptA to ptB >> will be expected to do precisely that: >> start at ptA and end at ptB. On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > Gnuplot does that now. What we are disagreeing about is the > meaning of the word "precisely". Actually I think we are disagreeing on the more basic words 'start' and 'end'. I have not been able to understand your apparent suggestion (?) that the user will expect ink past ptB (in the direction of the arrow). On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > You may not like the behavior, but that doesn't mean it > is ambiguous. I think you are giving a programmer's perspective rather than a user's perspective on ambiguity here. Of course, the code says what it says. But a user has no simple way to tell where an arrow will end. (I.e., where the ink will end.) On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > think of line segments in gnuplot as a > connect-the-dots process: place a dot at the "from" > position, place another at the "to" position, then connect > them. I accept that if I draw several independent (i.e., unjoined) line segments end to end that round caps will produce a better looking line. But this is not how people use arrows. Or rather, I don't know anyone using arrows this way. And those who do have a round caps option available to them. > I personally think that rounded ends are best. > But it should be left up to the user, as it is now. No, it isn't. Not for arrows with heads. Selecting butt caps does not cause arrowhead ink to terminate at the specified end point. > But they don't. They extend exactly to the specified > endpoint *** to the resolution of the pen used ***. >> What is more, with >> this behavior it is essentially impossible for me to make an >> arrow terminate precisely where I wish it to. > I don't see why. Can't you just specifiy a very thin > pen width and a filled arrowhead? Stroke the tail of > the arrow separately if you want that part thicker. Stroke the tail to where, exactly? (That is the user interface issue!) A picture is worth a thousand words. How can the sript below be considered to produce desirable output for these script commands? I still say the key issue is: what will users expect, and what makes it easiest for them to achieve precisely what they desire in a predictable fashion? When the user wants an arrow from ptA to ptB, that really ends at ptB (i.e., no ink past ptB), s/he should not have to make length adjustments everytime s/he changes the linewidth or arrowhead angle. Yet that is the current situation. I cannot see that this behavior (in the sample script) can meet the goal of being predictable for the user. And I add to that a personal query: thinking back over your own use of arrows in gnuplot, can you really claim that your *intent* when you first think of drawing an arrow from ptA to ptB is for the ink to extend past ptB? Alan Isaac ############################################################## set term post eps color solid butt set output 'c:\temp3.eps' set xrange [0:4] set yrange [0:5] set style arrow 1 front head size 0.2,15 nofilled lt -1 set style arrow 2 front nohead lt -1 set style arrow 3 front nohead lw 5 lt -1 set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1 set arrow from 1,1 to 3,1 as 1 set arrow from 1,2 to 3,2 as 2 set arrow from 1,3 to 3,3 as 3 set arrow from 1,4 to 3,4 as 4 plot '-' with points ps 1 pt 7 lt 1 3 1 3 2 3 3 e ############################################################## |
|
From: Ethan M. <merritt@u.washington.edu> - 2003-10-22 00:52:53
|
On Tuesday 21 October 2003 13:42, Alan G Isaac wrote: > A picture is worth a thousand words. How can the sript > below be considered to produce desirable output for these > script commands? > ############################################################## > set term post eps color solid butt > set output 'c:\temp3.eps' > set xrange [0:4] > set yrange [0:5] > set style arrow 1 front head size 0.2,15 nofilled lt -1 > set style arrow 2 front nohead lt -1 > set style arrow 3 front nohead lw 5 lt -1 > set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1 > set arrow from 1,1 to 3,1 as 1 > set arrow from 1,2 to 3,2 as 2 > set arrow from 1,3 to 3,3 as 3 > set arrow from 1,4 to 3,4 as 4 > plot '-' with points ps 1 pt 7 lt 1 > 3 1 > 3 2 > 3 3 > e > ############################################################## If you change that first line to=20 'set term post eps color solid round' then it looks just fine to me. The ugliness comes from requesting butt ends. Nonetheless, let me suggest a couple of possible code modifications. Please consider whether these would address your concerns. 1) The tail of a filled-head arrow could be drawn to reach only to the back of the head, not all the way to the tip. This would make=20 your sample arrow 4 much less ugly 2) There could be an offset parameter, expressed in screen coordinates I suppose, applied to the tip positioning of arrows. The arrow would be shortened by shifting the nominal "to" position back along the direction = of the arrow by this amount. This would allow you to use fat arrows (thick lines) for emphasis without obscuring the feature being pointed to. I think both of these could be implemented fairly easily in the device-independent code, and so would apply to all terminal types. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2003-10-22 09:25:47
|
Alan G Isaac wrote: > A picture is worth a thousand words. How can the sript > below be considered to produce desirable output for these > script commands? A couple comments. First, I see Alan's point from his example. That top arrowhead does seem to have the feel of not ending in the right spot. It looks like the increased thickness of the line causes the front tip of the arrowhead to be a little ways past the point. In other words, if you think of the outside edges of the lines, those thin edges criss-cross not at the "to" point, but somewhere beyond it. It seems to me that a nice behavior would be that no matter what type of butt/rounding style is used those outer edges should criss-cross right at the "to" point. Even if the tip is rounded, I'm guessing that would still look nice. (There would probably be a little bit of white space between the rounded tip and the "to" point.) It shouldn't be too difficult to write a little routine to compensate for that sort of thing. It is probably something involving vector math and trig. (To get the rounded tip to stop right at the point would require a bit more tricky computations.) Draw two extremely wide lines on a sheet of paper criss-crossing. The vector relationships should become clear from that. The second comment is that yes, user expectations are something to consider. But also you should weigh in any preceding standards. My guess is that there have been long discussions amongst graphics people about the topic and some standard may have emerged over the years. I would consider using that as a guide. Of course, I don't know where one would look for that. Perhaps a PostScript manual. Dan Alan G Isaac wrote: >>On Monday 20 October 2003 23:14, Alan G Isaac wrote: >> >> >>>Basic user interface issue: >>>set arrow from ptA to ptB >>>will be expected to do precisely that: >>>start at ptA and end at ptB. >>> >>> > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>Gnuplot does that now. What we are disagreeing about is the >>meaning of the word "precisely". >> >> > >Actually I think we are disagreeing on the more basic words >'start' and 'end'. I have not been able to understand your >apparent suggestion (?) that the user will expect ink past >ptB (in the direction of the arrow). > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>You may not like the behavior, but that doesn't mean it >>is ambiguous. >> >> > >I think you are giving a programmer's perspective rather >than a user's perspective on ambiguity here. Of course, >the code says what it says. But a user has no simple >way to tell where an arrow will end. (I.e., where the >ink will end.) > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>think of line segments in gnuplot as a >>connect-the-dots process: place a dot at the "from" >>position, place another at the "to" position, then connect >>them. >> >> > >I accept that if I draw several independent (i.e., unjoined) >line segments end to end that round caps will produce a >better looking line. But this is not how people use arrows. >Or rather, I don't know anyone using arrows this way. >And those who do have a round caps option available to them. > > > >>I personally think that rounded ends are best. >>But it should be left up to the user, as it is now. >> >> > >No, it isn't. Not for arrows with heads. Selecting butt >caps does not cause arrowhead ink to terminate at the >specified end point. > > > > >>But they don't. They extend exactly to the specified >>endpoint *** to the resolution of the pen used ***. >> >> > > > >>>What is more, with >>>this behavior it is essentially impossible for me to make an >>>arrow terminate precisely where I wish it to. >>> >>> > > > >>I don't see why. Can't you just specifiy a very thin >>pen width and a filled arrowhead? Stroke the tail of >>the arrow separately if you want that part thicker. >> >> > >Stroke the tail to where, exactly? (That is the >user interface issue!) > >A picture is worth a thousand words. How can the sript >below be considered to produce desirable output for these >script commands? I still say the key issue is: what will >users expect, and what makes it easiest for them to achieve >precisely what they desire in a predictable fashion? When >the user wants an arrow from ptA to ptB, that really ends at >ptB (i.e., no ink past ptB), s/he should not have to make >length adjustments everytime s/he changes the linewidth or >arrowhead angle. Yet that is the current situation. I >cannot see that this behavior (in the sample script) can >meet the goal of being predictable for the user. And I add >to that a personal query: thinking back over your own use of >arrows in gnuplot, can you really claim that your *intent* >when you first think of drawing an arrow from ptA to ptB >is for the ink to extend past ptB? > >Alan Isaac > >############################################################## >set term post eps color solid butt >set output 'c:\temp3.eps' >set xrange [0:4] >set yrange [0:5] >set style arrow 1 front head size 0.2,15 nofilled lt -1 >set style arrow 2 front nohead lt -1 >set style arrow 3 front nohead lw 5 lt -1 >set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1 >set arrow from 1,1 to 3,1 as 1 >set arrow from 1,2 to 3,2 as 2 >set arrow from 1,3 to 3,3 as 3 >set arrow from 1,4 to 3,4 as 4 >plot '-' with points ps 1 pt 7 lt 1 >3 1 >3 2 >3 3 >e >############################################################## > > > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >gnuplot-beta mailing list >gnu...@li... >https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > -- Dan Sebald email: d a n i e l . s e b a l d @ i e e e . o r g URL: ht tp://acer-access.c om/~dsebald @ acer-access.co m/ |
|
From: Alan G I. <ai...@am...> - 2003-10-31 17:58:35
|
On Wed, 22 Oct 2003, Daniel J Sebald apparently wrote: > user expectations > are something to consider. But also you should weigh > in any preceding standards. My guess is that there > have been long discussions amongst graphics people > about the topic and some standard may have emerged > over the years. I would consider using that as a guide. I have not been able to find an answer at this level, so I took a different approach: I looked in a number of nicely done math books to see how arrows are drawn. I found two widespread conventions: i. The arrowhead ink ends right at the point the arrow is drawn to. This is the convention that I have been pushing for. ii. The arrowhead ink ends right at the edge of a filled circle, the center of which is the point that the arrow is drawn "to". I find this odd conceptually, but I confess it does produce some nice looking graphics. I did *not* find cases where the arrowhead ink extends beyond the point the arrow is drawn to, which is the current gnuplot convention. So I not only remain convinced that current gnuplot practice is wrong at the conceptual level, it also does not appear to be a common practice (based on my limited "survey"). So I still think that the right thing for gnuplot to do is ensure that the very tip of the arrowhead ink is at the point that the arrow is drawn to. As I have argued, it is what the user expects, and based on a little looking around, it seems this user expectation is in line with established practice. However due to case (ii) above---a case that Ethan first drew my attention to---it seems it would also be useful to introduce a new option for set arrow: "point", which would work like similarly to how it does for label. Specifically, it would place a point and then allow for a single number "offset" (interpreted as a shortening of the arrowlength) which would be specified in pointsize units. (I guess one might be wanted at each end, in which case there could also be an option "points" that accepts two numbers an offset, one for each end.) fwiw, Alan |
|
From: Daniel J S. <dan...@ie...> - 2003-11-03 05:20:47
|
Alan G Isaac wrote: >On Wed, 22 Oct 2003, Daniel J Sebald apparently wrote: > > >> user expectations >>are something to consider. But also you should weigh >>in any preceding standards. My guess is that there >>have been long discussions amongst graphics people >>about the topic and some standard may have emerged >>over the years. I would consider using that as a guide. >> >> > > >I have not been able to find an answer at this >level, so I took a different approach: I looked >in a number of nicely done math books to see >how arrows are drawn. > Actually, this is probably just as good. Quality publishers hire out work to professional graphics companies who, I assume, know appropriate conventions. I think i and ii below are preferrable to the current arrowhead. When I find some time, I could draw the vector relationships and come up with the formula for compensenting for pen width at the arrow tip. (Perhaps digitize the drawing and make it available in a PDF file.) Dan >I found two widespread conventions: >i. The arrowhead ink ends right at the point the arrow is >drawn to. This is the convention that I have been pushing >for. >ii. The arrowhead ink ends right at the edge of a filled >circle, the center of which is the point that the arrow >is drawn "to". I find this odd conceptually, but I confess >it does produce some nice looking graphics. > >I did *not* find cases where the arrowhead ink extends >beyond the point the arrow is drawn to, which is the current >gnuplot convention. So I not only remain convinced that >current gnuplot practice is wrong at the conceptual level, >it also does not appear to be a common practice (based on my >limited "survey"). > >So I still think that the right thing for gnuplot to do is >ensure that the very tip of the arrowhead ink is at the >point that the arrow is drawn to. As I have argued, it is >what the user expects, and based on a little looking around, >it seems this user expectation is in line with established >practice. > >However due to case (ii) above---a case that Ethan first >drew my attention to---it seems it would also be useful to >introduce a new option for set arrow: "point", which would >work like similarly to how it does for label. Specifically, >it would place a point and then allow for a single number >"offset" (interpreted as a shortening of the arrowlength) >which would be specified in pointsize units. (I guess one >might be wanted at each end, in which case there could also >be an option "points" that accepts two numbers an offset, >one for each end.) > >fwiw, >Alan > > |
|
From: Daniel J S. <dan...@ie...> - 2003-11-22 21:18:30
|
Alan, Ethan, I've drawn up a diagram illustrating the tip of an arrow and how to compensate for the line ending so that the tip lands right at the desired end point. It is in PDF format at: http://acer-access.com/~ds...@ac.../ under "gnuplot stuff". The formula is actually quite simple given the angle of the tip "wings" as specified in Gnuplot. Basically a small vector opposite the direction of the vector from start (S) to end (E) is added to the end point (E). Here is a small chunk of code that implements the formula intended for the "place_arrows" routine in graphics.c. But THIS DOESN'T WORK currently (read below) so just illustrates the simplicity of the formula. apply_head_properties(&(this_arrow->arrow_properties)); /* A correction factor for the line so that the arrow head does * not extend past the ending point of the line. * * THIS IS CURRENTLY JUST A DEMONSTRATION AND DOESN'T ACCOUNT * FOR ALL THE SPECIAL CONDITIONS LIKE headlength < 0, alpha = 0, * ETC. */ if (this_arrow->arrow_properties.head_length > DBL_EPSILON) { double dx = (double) sx - (double) ex; double dy = (double) sy - (double) ey; double len_arrow = sqrt(dx * dx + dy * dy); double alpha = this_arrow->arrow_properties.head_angle * DEG2RAD; double w = this_arrow->arrow_properties.lp_properties.l_width; double factor = w/(2*len_arrow*sin(alpha)); ex += dx*factor; ey += dy*factor; } (*t->arrow) (sx, sy, ex, ey, this_arrow->arrow_properties.head); OK. This doesn't work because THE LINE WIDTH IS NOT KNOWN IN TERMS OF PLOT UNITS. That is, in the formula above, "w" should be the line width in terms of plot units not in terms of "unity" units. You see, the line width properties are sent all the way down to the driver level and I think it is there that the value of "lp_properties.l_width" takes on a meaning. So there are a couple significant problems here in compensating for the tip of the arrow. 1) Where should the compensation for the arrow tip be done? The options are inside the Gnuplot "place_arrow" routine, inside the default terminal "do_arrow" function, or inside each individual driver's "arrow" function. There are pluses and minuses for all. 2) Somewhere the width of a line must be known in terms of plot units in order to compensate for the arrow tip. I don't see where this information can be gotten easily and this could be some major driver level coding to send back such information. (Ethan, is this similar to the problems you've come across with getting font height information back from the driver?) Dan Alan G Isaac wrote: >>On Monday 20 October 2003 23:14, Alan G Isaac wrote: >> >> >>>Basic user interface issue: >>>set arrow from ptA to ptB >>>will be expected to do precisely that: >>>start at ptA and end at ptB. >>> >>> > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>Gnuplot does that now. What we are disagreeing about is the >>meaning of the word "precisely". >> >> > >Actually I think we are disagreeing on the more basic words >'start' and 'end'. I have not been able to understand your >apparent suggestion (?) that the user will expect ink past >ptB (in the direction of the arrow). > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>You may not like the behavior, but that doesn't mean it >>is ambiguous. >> >> > >I think you are giving a programmer's perspective rather >than a user's perspective on ambiguity here. Of course, >the code says what it says. But a user has no simple >way to tell where an arrow will end. (I.e., where the >ink will end.) > >On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote: > > >>think of line segments in gnuplot as a >>connect-the-dots process: place a dot at the "from" >>position, place another at the "to" position, then connect >>them. >> >> > >I accept that if I draw several independent (i.e., unjoined) >line segments end to end that round caps will produce a >better looking line. But this is not how people use arrows. >Or rather, I don't know anyone using arrows this way. >And those who do have a round caps option available to them. > > > >>I personally think that rounded ends are best. >>But it should be left up to the user, as it is now. >> >> > >No, it isn't. Not for arrows with heads. Selecting butt >caps does not cause arrowhead ink to terminate at the >specified end point. > > > > >>But they don't. They extend exactly to the specified >>endpoint *** to the resolution of the pen used ***. >> >> > > > >>>What is more, with >>>this behavior it is essentially impossible for me to make an >>>arrow terminate precisely where I wish it to. >>> >>> > > > >>I don't see why. Can't you just specifiy a very thin >>pen width and a filled arrowhead? Stroke the tail of >>the arrow separately if you want that part thicker. >> >> > >Stroke the tail to where, exactly? (That is the >user interface issue!) > >A picture is worth a thousand words. How can the sript >below be considered to produce desirable output for these >script commands? I still say the key issue is: what will >users expect, and what makes it easiest for them to achieve >precisely what they desire in a predictable fashion? When >the user wants an arrow from ptA to ptB, that really ends at >ptB (i.e., no ink past ptB), s/he should not have to make >length adjustments everytime s/he changes the linewidth or >arrowhead angle. Yet that is the current situation. I >cannot see that this behavior (in the sample script) can >meet the goal of being predictable for the user. And I add >to that a personal query: thinking back over your own use of >arrows in gnuplot, can you really claim that your *intent* >when you first think of drawing an arrow from ptA to ptB >is for the ink to extend past ptB? > >Alan Isaac > >############################################################## >set term post eps color solid butt >set output 'c:\temp3.eps' >set xrange [0:4] >set yrange [0:5] >set style arrow 1 front head size 0.2,15 nofilled lt -1 >set style arrow 2 front nohead lt -1 >set style arrow 3 front nohead lw 5 lt -1 >set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1 >set arrow from 1,1 to 3,1 as 1 >set arrow from 1,2 to 3,2 as 2 >set arrow from 1,3 to 3,3 as 3 >set arrow from 1,4 to 3,4 as 4 >plot '-' with points ps 1 pt 7 lt 1 >3 1 >3 2 >3 3 >e >############################################################## > > > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >gnuplot-beta mailing list >gnu...@li... >https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > > > -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
Thanks for helping keep SourceForge clean.
X