Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2005-11-09 20:44:07
|
Ethan, please tell me the cause why this plot file only plots two arrows in total and one partly? One is omitted totally in the postscript terminal. In x11 terminal, the arrows are okay. set terminal postscript eps set output 'asdf.eps' set arrow from graph -0.05,0 to graph 1,1 set arrow from graph 0.0,0 to graph 1,1 set arrow from graph 0.05,0 to graph 1,1 set arrow from screen 0,1 to screen 1,0 plot sin(x) set output set term x11 replot pause -1 All arrows are within the bounds of the canvas. It has to be my own decision if I want to plot arrows placed by "set arrow" only inside the plot or at an arbitrary position in the canvas. Of course, arrows produced by a plot command are supposed to be bounded by the graph boundaries. But 'set arrow' has to enable the user to put them everywhere within the canvas. Before you started to fiddle about the clipping and canvas stuff, everything worked fine. What is the cause for these "improvements" that restrain the user unnecessarily? If you want to, add an option 'bounded <coord>' to the 'set arrow' command, e.g. set arrow .... bounded graph to define boundaries for the arrow. But this may not be the default. Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-09 21:50:42
|
On Wednesday 09 November 2005 12:49 pm, Harald Harders wrote: > Ethan, > > please tell me the cause why this plot file only plots two arrows in > total and one partly? Damn. Well, I added a work-around for the clipping problem reported by Juergen Wieferink. The problem, and the work-around patch, were circulated. Juergen reported that the work-around was successful, so I put it in cvs, but it appears to have broken your intended use. I will revert the (1-line) patch that fixed Juergen's problem, leaving us where we were before. This is really hopeless. The postscript driver in particular is just plain broken. It does not correctly report back the current canvas size so that the core routines can do the clipping. But if the core routines do *not* do the clipping, then other drivers die horribly when you feed that same plot to them. > Of course, arrows produced by a plot command are supposed to be bounded by > the graph boundaries. But 'set arrow' has to enable the user to put them > everywhere within the canvas. Yes.... But how to do this when the postscript driver does not tell us how big its canvas is? > Before you started to fiddle about the clipping and canvas stuff, > everything worked fine. No. It did not. It is horribly inconsistent from one driver to another. You yourself may be happy with the way the postscript driver works, but there is no way you can say that it is "fine" that those same plots cause the pdf/cgm/svg/emf terminals to segfault. For that matter, you yourself have been complaining about buggy clipping and contributing patches to fix it. So how do you come around now to saying it all "worked fine"? > What is the cause for these "improvements" that > restrain the user unnecessarily? Trying to work around broken drivers, in particular the broken postscript driver. Trying to clear out long-standing bug reports that the pdf driver error-exits when arrows extend beyond the plot. Trying to fix the problem that the cgm and emf drivers also error-exit when objects of any sort are not clipped to the canvas. Trying to make the interactive terminals like x11, and the static terminals like postscript, act the same way so that you can preview your plots interactively before printing them. I welcome your help in fixing this mess. As we discussed, there needs to be a size option to the "set term post ..." command that lets you specify how big the bounding box is. Secondly, the postscript terminal calculates its own plotting limits internally but never tells the core code what they are. That needs to be fixed also. Finally, we need to agree on what is or is not enforced with regards to plotting outside the canvas limits. I continue to maintain that this should be categorically prevented, by clipping to the current canvas in the core routines. I.e. no more setting size greater than 1.0. But even if you all over-rule me on that one, we still need to get the different drivers to behave the same way with regard to size > 1. Ethan -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2005-11-09 22:26:51
|
On Wed, 9 Nov 2005, Ethan Merritt wrote: > On Wednesday 09 November 2005 12:49 pm, Harald Harders wrote: > > Ethan, > > > > please tell me the cause why this plot file only plots two arrows in > > total and one partly? > > Damn. Well, I added a work-around for the clipping problem > reported by Juergen Wieferink. The problem, and the work-around > patch, were circulated. Juergen reported that the work-around > was successful, so I put it in cvs, but it appears to have broken > your intended use. > > I will revert the (1-line) patch that fixed Juergen's problem, > leaving us where we were before. I have changed term_start_plot() locally to set far too big canvas coordinates and also reverted the patch. This works for me because I am only using Postscript-Based terminals. > > Of course, arrows produced by a plot command are supposed to be bounded by > > the graph boundaries. But 'set arrow' has to enable the user to put them > > everywhere within the canvas. > > Yes.... But how to do this when the postscript driver does not > tell us how big its canvas is? I once have provided a patch that worked, storing both the term boundaries as they are now and the canvas size. It wasn't applied to cvs. I remember that you were one of the people that complained that this was not the right way to do it. But it worked. > For that matter, you yourself have been complaining about buggy > clipping and contributing patches to fix it. So how do you come > around now to saying it all "worked fine"? It used to work fine with postscript ages ago. Then, some clipping routines were added that broke large plots. I have added a working patch. CVS was changed again and broke even more and made my patch not working anymore. I am not willing to do further work on this topic. I just want to get a working gnuplot that provides the usage of the hole canvas even if it has strange screen coordinate. And I want to preserve these strange screen coordinates (at least as an option) since a change would break hundreds of old scripts. (We do not have to discuss that a better size mechanism should be added, but added, not replaced). > I welcome your help in fixing this mess. As we discussed, > there needs to be a size option to the "set term post ..." > command that lets you specify how big the bounding box is. Yes, in addition to the current behaviour. First, the current behaviour has to be fixed. The only way to do this is to change the meaning of some variables and add more, unfortunately: term->xmax means the position, where the screen coordinate is 1 term->ymax means the position, where the screen coordinate is 1 term->xcanvas is the maximal screen coordinate in the canvas term->ycanvas is the second maximal screen coordinate in the canvas This has been provided by my rejected patch, to remind you once again. > Secondly, the postscript terminal calculates its own plotting > limits internally but never tells the core code what they are. > That needs to be fixed also. Has been available. > Finally, we need to agree on what is or is not enforced with > regards to plotting outside the canvas limits. I continue > to maintain that this should be categorically prevented, by > clipping to the current canvas in the core routines. I agree. > I.e. no more setting size greater than 1.0. I definitely do not agree. I agree that the default way should be to have upper right canvas corner has screen coordinates 1,1. And it is definitely nonsense to allow reduction of size below 1.0 but to disallow an increase. Either the upper right corner is 1,1 in all cases or everything is allowed. Since the old and current behaviour allows sizes different from one, this has to be preserved: To preserve the compatibility to old scripts, the old behaviour definitely has to be preserved. For me, this would mean that hundreds of old scripts would not work anymore. And I am sure that many many others would have the same problem. Beware that in Postscript this was the only possibility to produce plots in a different size than 1,1. Thus, every postscript plot in a non-default size would be affected. I propose to rename the command to change the canvas size to 'set size canvas' instead of 'set size' before 'set terminal' and to maintain the rest of the current behaviour. It would be okay to change one single line in all my scripts. > But even if you all over-rule me on that one, we still need > to get the different drivers to behave the same way with regard > to size > 1. With 'set size canvas' this would be no problem. > But even if you all over-rule me on that one, we still need > to get the different drivers to behave the same way with regard > to size > 1. Try asdf.gpl: In the first three examples, the canvas is changed to 1,2 and the plot scaled accordingly, without the recent one-line-change in gnuplot (and with ignored canvas clipping), the arrows are printed correctly. In xfig and png, the text above screen 1 is ignored. x11 scales the plot and and scales the screen coordinate system, but does not change the canvas, i.e., window size. It sounds strange that png produces a 320x480 picture after requesting a 320x240 picture. But it is consistent. Which other terminals do not work similarly? If it is not wanted to be able to change window sizes of interactive terminals from within gnuplot (why not?), they have to be exceptions. Best regards Harald PS: I still think that introducing absolute measures as mm, inch, etc. would be a good idea. But before starting work on that, the old behaviour has to be fixed. -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-09 23:07:59
|
Harald Harders wrote: > On Wed, 9 Nov 2005, Ethan Merritt wrote: >>Finally, we need to agree on what is or is not enforced with >>regards to plotting outside the canvas limits. I continue >>to maintain that this should be categorically prevented, by >>clipping to the current canvas in the core routines. > > > I agree. I don't know if I agree on that one. Are you saying that one can't have a fraction of an arrow at the edge of the canvas (i.e., say the tip extends just past the canvas limit, but is not visible)? That has to be allowed, otherwise one can't use the many features of PostScript. There is a bit of a conundrum with gnuplot's "terminal" concept. The throw back to the time it was conceptualized makes me think "rudimentary terminal". I don't know about other people's opinions, but I just don't like the idea of not striving to utilize the features of plotting utilities, like were mentioned, PostScript, png, jpg, pdf, etc. The philosophy (which really wasn't a big issue ten years ago because of limited utilities) seems to be implement things generically with the most rudimentary elements. If development slows down because people don't have the time, that's one thing. Bottlenecks is something different. As a brainstorm kind of thing, I sort of like the strategy of having a "fallback prototype". Use an arrow as an example. Say there is some legacy gnuplot code that draws an arrow using just lines and/or fill. But there are a number of drawing utilities that support arrows outright. It would be nice to set aside the legacy code as a "fallback prototype" and have a new terminal routine for arrows. The fallback prototype would have the same arguments as the new terminal routine. The concept would hold true for a large number of items in ever-evolving software. It'd basically be an organized way to allow new things to work their way into the code instead of running into these headaches. Maybe a "legacy terminal" is in order... something to prevent the need for coding up "if terminal has this feature, then this, otherwise that" all over the place in the core code. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-09 23:33:51
|
On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote: > > I don't know if I agree on that one. Are you saying that one > can't have a fraction of an arrow at the edge of the canvas > (i.e., say the tip extends just past the canvas limit, but is > not visible)? That has to be allowed, otherwise one can't use > the many features of PostScript. If you try this with the pdf terminal, it will crash. Therefore if you want a program that doesn't crash, you have to clip off the protruding piece of the arrow before sending it to the driver. Yes, I know PostScript won't crash if you draw outside the boundaries. But don't you think we should aim for code that works (or at least doesn't crash) on all the other terminal types as well? > Maybe > a "legacy terminal" is in order... something to prevent the need > for coding up "if terminal has this feature, then this, otherwise > that" all over the place in the core code. We have that now. These are the routines do_XXX() in term.c. They provide a generic fallback for terminals that don't supply their own routine to do XXX. In the case of arrows, the generic code is called do_arrow(), and is supposed to be usable by all terminals that do not provide their own specific arrow drawing routine. That is precisely what we are now fighting with; it isn't generic enough, because it causes some terminals to segfault, or abort, or draw garbage if the arrows go outside the current canvas. If you, or Harald, feel that the generic code is not appropriate for the PostScript driver, then of course you are free to write a terminal-specific PS_arrow() routine. I'm sure you could draw nicer looking arrows that way, just as the metapost driver does, for example. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2005-11-09 23:54:22
|
On Wed, 9 Nov 2005, Ethan Merritt wrote: > On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote: > > I don't know if I agree on that one. Are you saying that one > > can't have a fraction of an arrow at the edge of the canvas > > (i.e., say the tip extends just past the canvas limit, but is > > not visible)? That has to be allowed, otherwise one can't use > > the many features of PostScript. > > If you try this with the pdf terminal, it will crash. > Therefore if you want a program that doesn't crash, you have > to clip off the protruding piece of the arrow before sending > it to the driver. Yes, I know PostScript won't crash if you > draw outside the boundaries. But don't you think we should > aim for code that works (or at least doesn't crash) on all > the other terminal types as well? Why do so many routines have clipping? In my opinion we have about four things that have to be clipped, in most terminals: points lines filled polygons text Since arrows are produced by lines and filled polygons in most terminals, clipping would be done automatically by the routines producing the lines and the polygons. As a positive side effect, only the part of the arrow head would be cut off that is outside the canvas. But that does not solve the current problem that things are cut off which are inside the canvas. Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-10 01:26:12
|
Ethan Merritt wrote: > On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote: > >>I don't know if I agree on that one. Are you saying that one >>can't have a fraction of an arrow at the edge of the canvas >>(i.e., say the tip extends just past the canvas limit, but is >>not visible)? That has to be allowed, otherwise one can't use >>the many features of PostScript. > > > If you try this with the pdf terminal, it will crash. They are aware of this, I assume. (I guess I remember now that you wrote the developers.) That's clearly a bug in the utility. >>Maybe >>a "legacy terminal" is in order... something to prevent the need >>for coding up "if terminal has this feature, then this, otherwise >>that" all over the place in the core code. > > > We have that now. These are the routines do_XXX() in term.c. > They provide a generic fallback for terminals that don't > supply their own routine to do XXX. > > In the case of arrows, the generic code is called do_arrow(), > and is supposed to be usable by all terminals > that do not provide their own specific arrow drawing routine. > That is precisely what we are now fighting with; it isn't generic > enough, because it causes some terminals to segfault, or abort, > or draw garbage if the arrows go outside the current canvas. Oh, I see. Between a rock and a hard place, then. > If you, or Harald, feel that the generic code is not appropriate > for the PostScript driver, then of course you are free to write > a terminal-specific PS_arrow() routine. I'm sure you could draw > nicer looking arrows that way, just as the metapost driver does, > for example. Yeah. This is the way to go; solve the problem by avoiding it. Arrows in PostScript must be fairly easy. Dan |
|
From: Juergen W. <wie...@fr...> - 2005-11-10 08:02:47
|
Harald Harders wrote: > I definitely do not agree. I agree that the default way should be to have > upper right canvas corner has screen coordinates 1,1. And it is definitely > nonsense to allow reduction of size below 1.0 but to disallow an increase. As I see it, the screen coordinates just belong to the canvas, the latter being the overall drawing area. Then, sizes above 1.0 do not make any sense. Sizes smaller than 1.0 are essential for multiplots. Outside of multiplots, they are probably much less useful. Therefor, we indeed need some "set canvas" or "set size canvas". I like the idea of adding additional coordinate systems. Maybe the current "screen" could split in a backward compatible "screen" and a correct "canvas" coordinate system? Juergen |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-09 22:48:37
|
On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote: > > I once have provided a patch that worked, storing both the term boundaries > as they are now and the canvas size. It wasn't applied to cvs. I remember > that you were one of the people that complained that this was not the > right way to do it. But it worked. I do not recall seeing such a patch. Could you remind me which one that is? I don't see anything on SourceForge that seems to match your description. > term->xmax means the position, where the screen coordinate is 1 > term->ymax means the position, where the screen coordinate is 1 > term->xcanvas is the maximal screen coordinate in the canvas > term->ycanvas is the second maximal screen coordinate in the canvas > > This has been provided by my rejected patch, to remind you once again. I would be glad to look at such a patch. As I said, I don't recall seeing anything like that. So you extended the TERM_TABLE entries for all terminal types to hold canvas size values? That sounds like a lot more work than attempting to maintain the canvas size in the core code, but you may be right that in the long run it is the only approach that can succeed. Too bad it means revisiting every single terminal driver. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-11-09 22:59:41
|
Ethan Merritt wrote: > On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote: >>This has been provided by my rejected patch, to remind you once again. > > > I would be glad to look at such a patch. > As I said, I don't recall seeing anything like that. > So you extended the TERM_TABLE entries for all terminal types to hold > canvas size values? That sounds like a lot more work than attempting > to maintain the canvas size in the core code, but you may be right > that in the long run it is the only approach that can succeed. > Too bad it means revisiting every single terminal driver. This is just what I was trying to get at with my last entry! :-) Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-09 23:04:56
Attachments:
asdf.gpl
|
On Wed, 9 Nov 2005, Ethan Merritt wrote: > On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote: > > > > I once have provided a patch that worked, storing both the term boundaries > > as they are now and the canvas size. It wasn't applied to cvs. I remember > > that you were one of the people that complained that this was not the > > right way to do it. But it worked. > > I do not recall seeing such a patch. > Could you remind me which one that is? > I don't see anything on SourceForge that seems to match your description. #1104264, Fix buggy clipping of arrows in large splots #1105611, Introduce 'set pagesize' command > > term->xmax means the position, where the screen coordinate is 1 > > term->ymax means the position, where the screen coordinate is 1 > > term->xcanvas is the maximal screen coordinate in the canvas > > term->ycanvas is the second maximal screen coordinate in the canvas > > > > This has been provided by my rejected patch, to remind you once again. > > I would be glad to look at such a patch. I can imagine that these two patches do not cover all terminals, but they at least add a feedback out of the postscript terminal. > Too bad it means revisiting every single terminal driver. It looks like. I forgot to attach the example file I was talking about in the last mail. Here it comes. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-09 23:18:43
|
On Wednesday 09 November 2005 03:10 pm, Harald Harders wrote: > On Wed, 9 Nov 2005, Ethan Merritt wrote: > > > On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote: > > > > > > I once have provided a patch that worked, storing both the term boundaries > > > as they are now and the canvas size. It wasn't applied to cvs. I remember > > > that you were one of the people that complained that this was not the > > > right way to do it. But it worked. > > > > I do not recall seeing such a patch. > > Could you remind me which one that is? > > I don't see anything on SourceForge that seems to match your description. > > #1104264, Fix buggy clipping of arrows in large splots > #1105611, Introduce 'set pagesize' command > > > > term->xmax means the position, where the screen coordinate is 1 > > > term->ymax means the position, where the screen coordinate is 1 > > > term->xcanvas is the maximal screen coordinate in the canvas > > > term->ycanvas is the second maximal screen coordinate in the canvas > > > > > > This has been provided by my rejected patch, to remind you once again. Err, that feature is not found in either of the patches you mentioned. The "Fix buggy clipping" patch does not touch any terminal drivers. The "set pagesize" patch introduces a pair of global scaled values xpagesize and ypagesize, but does not add anything like term->canvas_xmin, term->canvas_xmax, term->canvas_ymin, term->canvas_ymax which is what you would need in order to do clipping. Although at this point I would prefer to add something like (BoundingBox *)(term->canvas) I.e., a structure containing all of the above that could be passed directly to the clipping routines as a pointer. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2005-11-09 23:35:02
|
On Wed, 9 Nov 2005, Ethan Merritt wrote:
> > > > I once have provided a patch that worked, storing both the term boundaries
> > > > as they are now and the canvas size. It wasn't applied to cvs. I remember
> > > > that you were one of the people that complained that this was not the
> > > > right way to do it. But it worked.
> > >
> > > I do not recall seeing such a patch.
> > > Could you remind me which one that is?
> > > I don't see anything on SourceForge that seems to match your description.
> >
> > #1104264, Fix buggy clipping of arrows in large splots
> > #1105611, Introduce 'set pagesize' command
> >
> > > > term->xmax means the position, where the screen coordinate is 1
> > > > term->ymax means the position, where the screen coordinate is 1
> > > > term->xcanvas is the maximal screen coordinate in the canvas
> > > > term->ycanvas is the second maximal screen coordinate in the canvas
> > > >
> > > > This has been provided by my rejected patch, to remind you once again.
>
> Err, that feature is not found in either of the patches you mentioned.
>
> The "Fix buggy clipping" patch does not touch any terminal drivers.
And what do the patches
/* EAM FIXME - Is this a sufficient test for out-of-bounds? */
- if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
+ if ((x < 0) ||
+ (multiplot && (x > term->xmax * global_xsize)) ||
+ (!multiplot && (x > term->xmax * xsize)) ||
+ (y < 0) ||
+ (multiplot && (y > term->ymax * global_ysize)) ||
+ (!multiplot && (y > term->ymax * ysize))) {
and
- if ((0 < x && x < term->xmax) && (0 < y && y < term->ymax))
+ FPRINTF((stderr,"on_page(): %d,%g %d,%g\n",
+ term->xmax,global_xsize,term->ymax,global_ysize));
+ if ((0 < x && x < term->xmax * global_xsize)
+ && (0 < y && y < term->ymax * global_ysize))
do? They affect clipping due to a 'set size' before 'set terminal'.
Or what does
- xleft += t->xmax * xoffset;
- xright += t->xmax * xoffset;
- ytop += t->ymax * yoffset;
- ybot += t->ymax * yoffset;
+ xleft += xpagemax * xoffset;
+ xright += xpagemax * xoffset;
+ ytop += ypagemax * yoffset;
+ ybot += ypagemax * yoffset;
and
- if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
+ if (*sx < 0 || *sx > xpagemax ||
+ *sy < 0 || *sy > ypagemax) {
+ FPRINTF((stderr,"place_arrow3d: skipping out-of-bounds arrow\n"));
do? Yes, clipping. They do not cover all problems we have now because at
the time I started with the patch only arrows in splots were clipped at
screen 1,1. But the maximal coordinate of set size before set terminal
already was stored independently on the term->xmax and term->ymax. They
worked. I did not say that they were elegant (which they for sure
weren't). But they could have served as a start into the right direction.
> The "set pagesize" patch introduces a pair of global scaled values
> xpagesize and ypagesize, but does not add anything like
> term->canvas_xmin,
> term->canvas_xmax,
> term->canvas_ymin,
> term->canvas_ymax
> which is what you would need in order to do clipping.
Yes, it would be more elegant to do it in the term struct. But, I say it
once again, the old approach exactly did what it was supposed do, but
outside of the struct term. This approach did not have the need to touch
the terminals.
I will be glad if sometimes a working clipping will be available.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-10 00:30:00
|
> >
> > The "Fix buggy clipping" patch does not touch any terminal drivers.
>
> And what do the patches
>
> /* EAM FIXME - Is this a sufficient test for out-of-bounds? */
> - if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
> + if ((x < 0) ||
> + (multiplot && (x > term->xmax * global_xsize)) ||
> + (!multiplot && (x > term->xmax * xsize)) ||
> + (y < 0) ||
> + (multiplot && (y > term->ymax * global_ysize)) ||
> + (!multiplot && (y > term->ymax * ysize))) {
>
> and
>
> - if ((0 < x && x < term->xmax) && (0 < y && y < term->ymax))
> + FPRINTF((stderr,"on_page(): %d,%g %d,%g\n",
> + term->xmax,global_xsize,term->ymax,global_ysize));
> + if ((0 < x && x < term->xmax * global_xsize)
> + && (0 < y && y < term->ymax * global_ysize))
>
> do? They affect clipping due to a 'set size' before 'set terminal'.
Well, they for sure do not corrent for the fact that term-xmax
and term->ymax do not in fact contain the correct clipping limits.
At least, not for post.trm.
> Or what does
>
> - xleft += t->xmax * xoffset;
> - xright += t->xmax * xoffset;
> - ytop += t->ymax * yoffset;
> - ybot += t->ymax * yoffset;
> + xleft += xpagemax * xoffset;
> + xright += xpagemax * xoffset;
> + ytop += ypagemax * yoffset;
> + ybot += ypagemax * yoffset;
>
> and
>
> - if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
> + if (*sx < 0 || *sx > xpagemax ||
> + *sy < 0 || *sy > ypagemax) {
> + FPRINTF((stderr,"place_arrow3d: skipping out-of-bounds arrow\n"));
>
> do? Yes, clipping.
but but but...
There is nothing in here that correctly sets the
canvas bounds for the current terminal.
Isn't that what we're talking about?
Multiplying a previous value by {xy}pagesize doesn't help if the
previous value is wrong to begin with.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-10 00:04:11
|
On Wednesday 09 November 2005 03:59 pm, Harald Harders wrote: > > Why do so many routines have clipping? In my opinion we have about four > things that have to be clipped, in most terminals: > > points gadgets.c:170:clip_point(unsigned int x, unsigned int y) > lines gadgets.c:192:draw_clip_line(int x1, int y1, int x2, int y2) > filled polygons We don't have this one > text term.c:941:write_multiline() > Since arrows are produced by lines and filled polygons in most terminals, > clipping would be done automatically by the routines producing the lines > and the polygons. As a positive side effect, only the part of the arrow > head would be cut off that is outside the canvas. Guess what? That is exactly the change I made to do_arrow() which you have been complaining about. It now uses the routine draw_clip_line() to draw all the lines in the arrow, which means that they get clipped automatically. What you are now finding is that this generic clipping doesn't always work the way you would like, because the individual terminal drivers are not consistent. I'm glad we are now in agreement :-) -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2005-11-10 00:08:41
|
On Wed, 9 Nov 2005, Ethan Merritt wrote: > What you are now finding is that this generic clipping doesn't always > work the way you would like, because the individual terminal drivers > are not consistent. But that's not caused by generic or specific clipping. It is caused by the fact that the clipping boundary is in the middle of the canvas in many cases. > I'm glad we are now in agreement :-) I hope so. The most important thing for me is to combine both correct clipping with saving compatibility with my old postscript/epslatex plots. Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-10 00:13:44
|
On Wednesday 09 November 2005 04:14 pm, Harald Harders wrote: > On Wed, 9 Nov 2005, Ethan Merritt wrote: > > > What you are now finding is that this generic clipping doesn't always > > work the way you would like, because the individual terminal drivers > > are not consistent. > > But that's not caused by generic or specific clipping. It is caused by the > fact that the clipping boundary is in the middle of the canvas in many > cases. Well, in this particular case it is caused by the fact that when post.trm expands its drawing limits, it does not change the values of term->xmax and term->ymax. Therefore if you clip against them, it doesn't work. So far as I know, other terminal drivers correctly report what their actual limiting coordinates are. > I hope so. The most important thing for me is to combine both correct > clipping with saving compatibility with my old postscript/epslatex plots. Good luck on that. As I keep pointing out, you cannot both have compability across terminals and compatibility with old versions, because in the old (and current) version the terminals themselves are not compatible. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-11-10 01:34:16
|
Ethan Merritt wrote: > On Wednesday 09 November 2005 04:14 pm, Harald Harders wrote: > >>On Wed, 9 Nov 2005, Ethan Merritt wrote: >> >> >>>What you are now finding is that this generic clipping doesn't always >>>work the way you would like, because the individual terminal drivers >>>are not consistent. >> >>But that's not caused by generic or specific clipping. It is caused by the >>fact that the clipping boundary is in the middle of the canvas in many >>cases. > > > > Well, in this particular case it is caused by the fact that when > post.trm expands its drawing limits, it does not change the values > of term->xmax and term->ymax. Therefore if you clip against them, > it doesn't work. So far as I know, other terminal drivers > correctly report what their actual limiting coordinates are. PostScript, I'm almost certain, will have better clipping than any other utility. > >>I hope so. The most important thing for me is to combine both correct >>clipping with saving compatibility with my old postscript/epslatex plots. > > > Good luck on that. As I keep pointing out, you cannot both have > compability across terminals and compatibility with old versions, > because in the old (and current) version the terminals themselves > are not compatible. Add a better do_arrow() to the PostScript terminal, that's all. Effort in that is more worthwhile. Dan |
|
From: Aapo L. <aap...@gm...> - 2005-11-11 11:41:27
|
On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote:
> Well, in this particular case it is caused by the fact that when
> post.trm expands its drawing limits, it does not change the values
> of term->xmax and term->ymax. Therefore if you clip against them,
> it doesn't work. So far as I know, other terminal drivers
> correctly report what their actual limiting coordinates are.
What is the exact reason that prevents fixing post.trm (and maybe other
broken terminals) so that it would correctly update term->xmax and
term->ymax? I would imagine that it wouldn't be terribly difficult to
change accordingly the values of these two variables when the postscript
internal canvas grow. Is it somehow a problem with backward
compatibility?
I wonder if the problem with the inconsistencies between different
terminals and backward compatibility is so severe that a new global
option "set terminalmode {old|new}" is needed. I believe that option
would be quite horrible from the maintaining point of view.
Aapo
|
|
From: Daniel J S. <dan...@ie...> - 2005-11-11 18:28:36
|
Aapo Lankinen wrote: > On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote: > >>Well, in this particular case it is caused by the fact that when >>post.trm expands its drawing limits, it does not change the values >>of term->xmax and term->ymax. Therefore if you clip against them, >>it doesn't work. So far as I know, other terminal drivers >>correctly report what their actual limiting coordinates are. > > > What is the exact reason that prevents fixing post.trm (and maybe other > broken terminals) so that it would correctly update term->xmax and > term->ymax? I would imagine that it wouldn't be terribly difficult to > change accordingly the values of these two variables when the postscript > internal canvas grow. Is it somehow a problem with backward > compatibility? I don't see why things have to be done this way. Does "canvas" have the same meaning as "view port". The thing is, in PostScript I don't think one has to worry at all about plotting beyond the "view port". (Sorry, P.S. terminology isn't fresh in my mind right now.) It automatically takes care of that, doesn't it? Why impose some inferior clipping method? Instead, in the case of P.S., interpret term->xmax and term->ymax as simply boundaries of where the plot is viewed. Or, if those aren't the appropriate variables, conceptually I hope you understand my point. Also, write a nicer do_arrow(), as Ethan suggests. I think I could do it fairly easily, but I simply don't have time now. It would have to wait until after the holidays. Now, although that doesn't seem too difficult, there is a similar thing with the new image code. One starts out writing a generic thing, but I now know--after having looked at PostScript books in the process of working on PostScript images--that eventually improvements can be made for PostScript images plotted at an angle. Believe it or not, PostScript can have a viewing angle for rectangular images. I think for now, the generic pixel (parallelogram) by pixel (parallelogram) method will have to do. [Ethan, I hope that adding a view angle or such to the image terminal routine down the road doesn't cause any problems. If so, perhaps we should think about that before the next release.] Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-11 22:02:22
|
On Fri, 11 Nov 2005, Aapo Lankinen wrote:
> On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote:
> > Well, in this particular case it is caused by the fact that when
> > post.trm expands its drawing limits, it does not change the values
> > of term->xmax and term->ymax. Therefore if you clip against them,
> > it doesn't work. So far as I know, other terminal drivers
> > correctly report what their actual limiting coordinates are.
>
> What is the exact reason that prevents fixing post.trm (and maybe other
> broken terminals) so that it would correctly update term->xmax and
> term->ymax? I would imagine that it wouldn't be terribly difficult to
> change accordingly the values of these two variables when the postscript
> internal canvas grow. Is it somehow a problem with backward
> compatibility?
The problem is that xmax and ymax are the positions of the screen
coordinates 1,1. And they are not equal to the upper right corner in all
cases. To change this would mean to do incompatible changes.
> I wonder if the problem with the inconsistencies between different
> terminals and backward compatibility is so severe that a new global
> option "set terminalmode {old|new}" is needed. I believe that option
> would be quite horrible from the maintaining point of view.
I would prefer to add a new coordinate system, e.g., canvas, that scales
with the canvas of the plot.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Harald H. <h.h...@tu...> - 2005-11-11 21:10:28
|
On Fri, 11 Nov 2005, Daniel J Sebald wrote: > > What is the exact reason that prevents fixing post.trm (and maybe other > > broken terminals) so that it would correctly update term->xmax and > > term->ymax? I would imagine that it wouldn't be terribly difficult to > > change accordingly the values of these two variables when the postscript > > internal canvas grow. Is it somehow a problem with backward > > compatibility? > > I don't see why things have to be done this way. Does "canvas" have the > same meaning as "view port". Yes. > The thing is, in PostScript I don't think > one has to worry at all about plotting beyond the "view port". (Sorry, > P.S. terminology isn't fresh in my mind right now.) It automatically > takes care of that, doesn't it? Why impose some inferior clipping > method? No, not really automatically. But it is fairly easy to define a clipping path inside the produced Postscript file. Thus, only for Postscript we would not have this problem. But the problem also applies for other terminals. Try set size 2,2 set terminal png set output 'asdf.png' plot sin(x) set output Have of the tic marks are missing. > Instead, in the case of P.S., interpret term->xmax and term->ymax as > simply boundaries of where the plot is viewed. Or, if those aren't the > appropriate variables, conceptually I hope you understand my point. The point is that term->xmax and term->ymax denote the position where the screen coordinate system has the values 1,1. They do not denote the upper right corner of the canvas (view port or BoundingBox). > Also, write a nicer do_arrow(), as Ethan suggests. I think I could do > it fairly easily, but I simply don't have time now. It would have to > wait until after the holidays. What do you want to improve? For me, the Postscript arrows are good enough. > [...] Believe it or not, > PostScript can have a viewing angle for rectangular images. I think for > now, the generic pixel (parallelogram) by pixel (parallelogram) method > will have to do. Yes, of course. Postscript can do nearly everything except translucent objects. For me, it would be much more interesting to enable gnuplot to read in common picture files as jpg or png. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-11-12 01:04:35
|
Harald Harders wrote: > On Fri, 11 Nov 2005, Daniel J Sebald wrote: > >>The thing is, in PostScript I don't think >>one has to worry at all about plotting beyond the "view port". (Sorry, >>P.S. terminology isn't fresh in my mind right now.) It automatically >>takes care of that, doesn't it? Why impose some inferior clipping >>method? > > > No, not really automatically. But it is fairly easy to define a clipping > path inside the produced Postscript file. Thus, only for Postscript we > would not have this problem. But the problem also applies for other > terminals. Try I don't know if it is even that complicated. Certainly one can do that. But I'm constantly making the mistake of creating a plot half off screen in ghostview, then I expand out to some other page size beside "encapsulated" and there is the rest of the plot. > > set size 2,2 > set terminal png > set output 'asdf.png' > plot sin(x) > set output > > Have of the tic marks are missing. Hmm. Not right of course, but this seems as though it may be a different bug. I see all the tic marks, but the annotation is what is missing. Furthermore, it is only the non-negative numbers that are missing (probably the key to the bug). But wouldn't the non-negative numbers take up less space than the negative numbers? And if so, wouldn't those extend toward or past the edge _less_ than the negative numbers. Anyone? > >>Also, write a nicer do_arrow(), as Ethan suggests. I think I could do >>it fairly easily, but I simply don't have time now. It would have to >>wait until after the holidays. > > > What do you want to improve? For me, the Postscript arrows are good > enough. I'd thought I'd read in the thread somewhere that better PostScript arrows clipped at the edge of the canvas were desired. Sorry. > > >>[...] Believe it or not, >>PostScript can have a viewing angle for rectangular images. I think for >>now, the generic pixel (parallelogram) by pixel (parallelogram) method >>will have to do. > > > Yes, of course. Postscript can do nearly everything except translucent > objects. (Really? I'd been guessing, or hoping, it would. Oh well.) For me, it would be much more interesting to enable gnuplot to > read in common picture files as jpg or png. Noted. (And list members should note.) The capability to do so exists as part of the code. But there is debate on whether to allow this. Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-12 12:02:44
|
On Fri, 11 Nov 2005, Daniel J Sebald wrote: > > set size 2,2 > > set terminal png > > set output 'asdf.png' > > plot sin(x) > > set output > > > > Have of the tic marks are missing. sed s/Have/Half/. > Hmm. Not right of course, but this seems as though it may be a > different bug. I see all the tic marks, but the annotation is what is > missing. That's what I meant. It's easy: All text that is requested with a screen coordinate above 1 is not printed. It does not have to do with negative or positive numbers. Just try another size than 2,2. > >>Also, write a nicer do_arrow(), as Ethan suggests. I think I could do > >>it fairly easily, but I simply don't have time now. It would have to > >>wait until after the holidays. > > > > What do you want to improve? For me, the Postscript arrows are good > > enough. > > I'd thought I'd read in the thread somewhere that better PostScript > arrows clipped at the edge of the canvas were desired. Sorry. If the line and the filled-path code supports correct clipping and the original arrow code uses these clipped lines and filled paths, parly clipping of arrow heads will be supported by every terminal. For postscript of course, no clipping code will be necessary at all: %!PS-Adobe-2.0 EPSF-2.0 %%BoundingBox: 0 0 100 100 %%EndProlog gsave % Introduce clipping newpath 30 30 moveto 70 30 lineto 70 70 lineto 30 70 lineto closepath clip % Some tests newpath 1 0 0 setrgbcolor 0 0 moveto 100 100 lineto stroke 10 50 moveto (Times-Roman) findfont 10 scalefont setfont (Hello world, this is clipped) show % Remove clipping again grestore showpage %%Trailer > > Yes, of course. Postscript can do nearly everything except translucent > > objects. > > (Really? I'd been guessing, or hoping, it would. Oh well.) Maybe it can't cook coffee. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-12 01:19:48
|
On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote:
>
> I don't know if it is even that complicated. Certainly one can do that.
> But I'm constantly making the mistake of creating a plot half off
> screen in ghostview, then I expand out to some other page size beside
> "encapsulated" and there is the rest of the plot.
And right there you have the reason why the PostScript driver is
different from all the others - it let's you draw "off the screen".
If you come to rely on that, you will eventually find that some
other driver will be extremely unhappy that you are trying to
draw outside the pre-allocated space.
> > set size 2,2
^^^^^^^^^^^^^
Don't do that.
> For me, it would be much more interesting to enable gnuplot to
> read in common picture files as jpg or png.
>
> Noted. (And list members should note.) The capability to do so exists
> as part of the code. But there is debate on whether to allow this.
Really? You have code that reads in a jpeg file?
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
