Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-18 01:35:36
|
> >remember that just because gnuplot thinks the output > >resolution is 300 pixels per something, that doesn't > >mean the actual display device will have that resolution. > > This only applies to screen terminals. Screen terminals as > x11 should read the system-wide value as default. There is no such thing as a system-wide default for x11. It is different for every display session. > But for all pixel-based terminals (png, gif, ...), the > resolution can be written into the output file. Actually, it can't. Or at least, not using libgd. That is a failing of libgd but we are stuck with it at present. And I don't see a way to do it for pbm output either. > - A patch exists that fixes clipping for many (or all?) > terminals. You are referring to patch #1104264? That patch does not fix the root problem at all. It just multiplies the reported screen limits by a factor large enough to let the arrows escape clipping. This works for PostScript because it doesn't really care that you are drawing outside of the limits it previously reported. On terminals that do care, your patch could make things worse rather than better. I would much rather the problem, if it is one, be fixed by having the terminals correctly report a legal range of x and y values. That would make the current clipping code work for all terminals, rather than having to special-case terminals that report silly values. But if we *do* have to special-case post.trm, it's better to just turn off clipping altogether rather than "fix" it by describing an over-large drawing area. Please try the patch I sent you earlier today. -- 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-22 20:14:20
|
On Thu, 17 Nov 2005, Ethan Merritt wrote: > > >remember that just because gnuplot thinks the output > > >resolution is 300 pixels per something, that doesn't > > >mean the actual display device will have that resolution. > > > > This only applies to screen terminals. Screen terminals as > > x11 should read the system-wide value as default. > > There is no such thing as a system-wide default for x11. > It is different for every display session. > > > But for all pixel-based terminals (png, gif, ...), the > > resolution can be written into the output file. > > Actually, it can't. Or at least, not using libgd. > That is a failing of libgd but we are stuck with it at present. If I remember correctly, the developer of libgd has worked together with the gnuplot developers several times. I we ask him to include resolution support, he probably will add it in future. > And I don't see a way to do it for pbm output either. I do not know the pbm format well enough to say anything about it. > > - A patch exists that fixes clipping for many (or all?) > > terminals. > > You are referring to patch #1104264? > That patch does not fix the root problem at all. It just > multiplies the reported screen limits by a factor large > enough to let the arrows escape clipping. This works for > PostScript because it doesn't really care that you are drawing > outside of the limits it previously reported. > On terminals that do care, your patch could make things worse > rather than better. No, I am talking about patch #1353539. The thing is that term->xmax and term->ymax are not what they seem. They are the internal coordinate values for the position on the screen where the screen coordinates are 1. In many situations, this position is identical with the upper right corner of the canvas. But there are also many situations where this is not the case. For example when using 'set offset' or 'set size' in postscript, png, jpg, fig (may be more, I have not tested more). This test adds "BoundingBox canvas;" to "struct TERMENTRY". By default, the canvas boundaries and xmax,ymax are identical. They are only changed when 'set size' or 'set origin' is used in terminals which support a change of the plot and canvas by this. It maybe also should rename xmax and ymax to something that fits better what these variables mean. But I have decided not to touch every file. Have a look at the newly uploaded patch, compile it with DEBUG defined, and try out the attached script. It shows that clipping works correctly for postscript, png, and x11. For fig, clipping isn't done at all (but the clipping routines are not invoked. Thus it cannot work with any existing code, but the new code issues a warning). > I would much rather the problem, if it is one, be fixed > by having the terminals correctly report a legal range of > x and y values. That would make the current clipping code > work for all terminals, rather than having to special-case > terminals that report silly values. Do you agree that this patch fulfills this? With it, all terminals report the position of screen 1,1 in term->xmax,term->ymax and the size and position of the canvas in term->canvas. > But if we *do* have to special-case post.trm, it's better to > just turn off clipping altogether rather than "fix" it > by describing an over-large drawing area. > Please try the patch I sent you earlier today. This sounds like a good idea. Does this also apply to libgd? Or does it produce core dumps when trying to produce a pixel outside of the picture canvas? But still terminals as fig have to be able to place labels and arrows everywhere where other elements of the plots can also appear. I have had a look to your Postscript clipping patch. I think this could be useful in addition. I am preparing an extension because Postscript does not do the clipping by default but can be told to do it. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: V. <gae...@no...> - 2005-11-22 20:46:44
|
On Tue, Nov 22, 2005 at 09:20:04PM +0100, Harald Harders wrote:
> > But if we *do* have to special-case post.trm, it's better to
> > just turn off clipping altogether rather than "fix" it
> > by describing an over-large drawing area.
> > Please try the patch I sent you earlier today.
What about adding a terminal flag to choose weather gnuplot should
do the clipping, or not ? Other terminals would use this flag.
--=20
Ga=EBl
|
|
From: Harald H. <h.h...@tu...> - 2005-11-22 21:23:38
|
On Tue, 22 Nov 2005, Ga=EBl Varoquaux wrote: > On Tue, Nov 22, 2005 at 09:20:04PM +0100, Harald Harders wrote: > > > But if we *do* have to special-case post.trm, it's better to > > > just turn off clipping altogether rather than "fix" it > > > by describing an over-large drawing area. > > > Please I got some error opening your mail (Non-hexadecimal character). Was this everything you have posted? For postscript, clipping by postscript should be switched of totally. But it also applies for png, jpg, fig, for example. Thus, clipping stays an important topic. Best regards Harald --=20 Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-22 22:56:52
|
On Tuesday 22 November 2005 12:46 pm, Ga=EBl Varoquaux wrote: >=20 > What about adding a terminal flag to choose weather gnuplot should > do the clipping, or not ? Other terminals would use this flag. There is one. TERM_CAN_CLIP I added it some while ago in an attempt to keep the postscript driver happy. =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-11-24 11:41:55
|
What about embedding all these new commands into a single "set" command, e.g. set allterms resolution 300 set allterms size 5, 7 so that when setting a new terminal afterwards, such as "set term png", it would take the above values as default. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-24 14:31:14
|
Petr Mikulik wrote: > What about embedding all these new commands into a single "set" command, > e.g. > > set allterms resolution 300 > set allterms size 5, 7 > > so that when setting a new terminal afterwards, such as "set term png", > it would take the above values as default. No need for a new command --- 'set termoption' already exists. |
