Menu
▾
▴
gnuplot-beta
|
From: Don T. <dt...@to...> - 2005-10-04 16:20:09
|
Various terminals the size of whose output can be changed with 'set size' have a bug in current cvs. When the size is increased by setting the size with factors greater than one, any labels outside the original size (from 'set terminal xxx size n,m') do not appear. The happens in png, jpeg, gif and pbm (and perhaps others I don't know about.) A demo script follows. In the 'bad' output the title, key labels, and half the [xy]tic labels are missing. set term png set output 'good.png' plot sin(x), cos(x) set size 1.5, 1.5 set output 'bad.png' replot Don Taber |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-04 16:58:46
|
On Tuesday 04 October 2005 09:19 am, Don Taber wrote: > Various terminals the size of whose output can be changed with > 'set size' have a bug in current cvs. When the size is increased > by setting the size with factors greater than one, So don't do that. Neither the png/jpeg/gif terminal driver nor the pdf terminal driver can do anything useful with size>1. You are basically telling it to draw outside of the legal drawing area. Other terminals may also belong on that list. Basically, size should never be > 1, although some terminal types may handle this case more gracefully than others. In the case of the png terminal, you should define the image size directly and leave "size" equal to 1. set term png size 1234, 2345 > any labels outside > the original size (from 'set terminal xxx size n,m') do not > appear. The happens in png, jpeg, gif and pbm (and perhaps others > I don't know about.) A demo script follows. In the 'bad' output > the title, key labels, and half the [xy]tic labels are missing. > > set term png > set output 'good.png' > plot sin(x), cos(x) > set size 1.5, 1.5 > set output 'bad.png' > replot > > Don Taber > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Don T. <dt...@to...> - 2005-10-04 19:54:59
|
> > Various terminals the size of whose output can be changed with > > 'set size' have a bug in current cvs. When the size is increased > > by setting the size with factors greater than one, > > So don't do that. > It's not that easy for several reasons. 1. This resizing technique *used* to work and there are scripts out there (some of which are mine) that rely on it. 2. For 'set term pbm' there is no size argument and a subsequent 'set size' command is the only way to change the size. Try 'help set term pbm' and you will find that you are advised to use size > 1. 3. For other terminals, the documentation specifically states that the size may be changed with 'set size'. No warning that size > 1 won't work. And it still *does* work for the plots. It is only reasonable that it should work for the labels too. I did not try to fix this myself because I am not sufficiently familiar with the terminal driver code. But my suspicion is that it would be easier to restore the previous behavior than to fix all the documentation to reflect the new behavior. Don Taber |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-04 20:11:20
|
On Tuesday 04 October 2005 12:54 pm, Don Taber wrote: > > > Various terminals the size of whose output can be changed with > > > 'set size' have a bug in current cvs. When the size is increased > > > by setting the size with factors greater than one, > > > > So don't do that. > > > > It's not that easy for several reasons. > > 1. This resizing technique *used* to work and there are scripts out there > (some of which are mine) that rely on it. Several of gnuplot's terminal drivers have been entirely replaced or re-written, for good reason. I can believe that the old (5 years+) png driver used to behave differently, but it's now dead and buried. > 2. For 'set term pbm' there is no size argument and a subsequent > 'set size' command is the only way to change the size. Try > 'help set term pbm' and you will find that you are advised to > use size > 1. OK. So let's fix the pbm terminal. That sounds easy. > 3. For other terminals, the documentation specifically states > that the size may be changed with 'set size'. No warning that > size > 1 won't work. That also can be fixed. > And it still *does* work for the plots. > It is only reasonable that it should work for the labels too. I can assure you that it does not work reliably (in the sense of working for all terminals) for the plots either. > I did not try to fix this myself because I am not sufficiently > familiar with the terminal driver code. But my suspicion > is that it would be easier to restore the previous behavior > than to fix all the documentation to reflect the new behavior. No. It is not fixable in either png or pdf drivers, since it is the underlying library rather than any gnuplot code that causes a problem. pdflib in particular is ridiculously prone to segfaults if you try to draw or write outside of the pre-defined plot boundaries. I have not looked in detail at other drivers, but I think it's only luck that size>1 ever worked. My [one] vote would be to fix the terminal drivers that have no separate size option, and then limit the global size parameter to the range 0<size<1. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Jonathan T. <jt...@ae...> - 2005-10-04 17:03:37
|
On Tue, 4 Oct 2005, Ethan Merritt wrote:
[[set size to a value > 1]]
> So don't do that.
>
> Neither the png/jpeg/gif terminal driver nor the pdf terminal
> driver can do anything useful with size>1. You are basically
> telling it to draw outside of the legal drawing area.
> Other terminals may also belong on that list.
>
> Basically, size should never be > 1, although some terminal
> types may handle this case more gracefully than others.
I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
isn't 'set size 2,2' the only way to get a postscript file twice as large
as the default size?
ciao,
--
-- Jonathan Thornburg <jt...@ae...>
Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-04 17:14:34
|
On Tuesday 04 October 2005 10:03 am, Jonathan Thornburg wrote: > > I'm not disagreeing with Ethan for bitmap terminals, but for postscript, > isn't 'set size 2,2' the only way to get a postscript file twice as large > as the default size? What exactly do you mean by "twice as large"? The default postscript output fills a US Letter page. I can understand griping about not having an A4 option, but are you really trying to print something to a 15" x 22" piece of paper? Note that if you do say set size 2,2 set term post It produces an output file containing the lines %%BoundingBox: -454 50 554 1490 %%Orientation: Landscape While this is legal PostScript, it is unlikely to print correctly on a real output device since the x coordinate go negative. In general I would say the better choice is to select eps output, and then scale the resulting eps figure to whatever size you like in the final document. But perhaps I am misunderstanding the intended use. -- 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-10-04 20:07:32
|
On Tue, 4 Oct 2005, Ethan Merritt wrote:
> On Tuesday 04 October 2005 10:03 am, Jonathan Thornburg wrote:
> >
> > I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
> > isn't 'set size 2,2' the only way to get a postscript file twice as large
> > as the default size?
>
> What exactly do you mean by "twice as large"?
[...]
> In general I would say the better choice is to select eps
> output, and then scale the resulting eps figure to whatever
> size you like in the final document. But perhaps I am
> misunderstanding the intended use.
Definitely not. If you want to have consistent plots in a document, you
really should use the same linewidth and the same font size. Thus, all
plots in a document should be scaled by the same amount while of course
not scaling is most elegant. For example \includegraphics{figure} is more
elegant than \includegraphics[scale=2]{figure}.
And I do not see a reason why gnuplot shall not be able to generate plots
with a size larger than 1 x 1. If it is valid to reduce the size of a plot
by using 'set size' before 'set terminal' (which has been agreed in a
former discussion where I complained about cropped arrows in splots larger
than 1 x 1), an increase of the size to a measure larger than 1 x 1 should
also be possible. For the arrow bug, I have a patch that still seems to
work for me (I haven't tested it since a long time), patch #1104264. But
for the bug concerning the labels, I also do not have a solution.
I still do not understand the arguments why a plot larger than 1 x 1
should not be used. It seems ignorant to me. The bug also does not apply
to pixel based plots if you want to have the same font sizes and
linewidths in two different plots with a different size.
It should be easy to adapt my patch also to labels.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-04 22:39:01
|
On Tuesday 04 October 2005 01:12 pm, Harald Harders wrote: > > And I do not see a reason why gnuplot shall not be able to generate plots > with a size larger than 1 x 1. Because "1 x 1" means "the full plotting area". By definition, if you plot outside that area then you are asking for trouble. > If it is valid to reduce the size of a plot > by using 'set size' before 'set terminal' (which has been agreed in a > former discussion where I complained about cropped arrows in splots larger > than 1 x 1), an increase of the size to a measure larger than 1 x 1 should > also be possible. No. See above. It makes perfect sense to ask for the current plot to fill only 1/4 of the plotting area. That's the normal use of multiplot mode. You are making, say, 4 plots on the same page, and each one should occupy 1/4 of the area. Asking to fill *more* than the plotting area makes no sense and should not be allowed IMHO. > I still do not understand the arguments why a plot larger than 1 x 1 > should not be used. It seems ignorant to me. The bug also does not apply > to pixel based plots if you want to have the same font sizes and > linewidths in two different plots with a different size. I do not follow which side of the argument you are pursuing in these sentences. Are you proposing that we change the meaning of "size" for pixel-based terminals, so that in the future it would mean "use this as a multiplier for # of pixels, all font sizes, line widths, point sizes, etc"? That would make some sense, since it would effectively be changing the resolution of the output image. But it would be a major change from the way things work now. It also does exactly the opposite of what you said you wanted PostScript output to do in the case of scaling up the output size. Could someone explain to me what is the actual use intended for one of these larger-than-full-page plots? Is the idea to make a posterboard-sized plot using PostScript? But in that case you probably *do* want to scale up the line widths and fonts, so that they remain readable at normal poster-viewing distance. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Robert H. <en...@no...> - 2005-10-05 10:17:50
|
On Tue, 4 Oct 2005, Ethan Merritt wrote:
> Because "1 x 1" means "the full plotting area".
> By definition, if you plot outside that area then you are asking for
> trouble.
In many cases though, it means "the default plotting area". For example
the epslatex terminal now has a default of "5 x 3.5 inches". It is quite
conceivable to need an epslatex plot that is larger than this.
> Could someone explain to me what is the actual use intended for one
> of these larger-than-full-page plots? Is the idea to make a
> posterboard-sized plot using PostScript? But in that case you
> probably *do* want to scale up the line widths and fonts, so that
> they remain readable at normal poster-viewing distance.
Again, using the epslatex terminal as an example: The default size is
based on a typical page width, and a reasonable aspext ratio. Personally I
prefer a slightly taller plot, (because I tend to put the key below) and
my page width isn't exactly 5 inches, so I have:
set size (345.0/72.27)/5.0, 4.0/3.5;
in all my gnuplot files. Secondly however when I use multiplot, I often
want two plots one above the other but keeping the total width to be the
page width, so you then need a:
set size 1,2;
This seems perfectly reasonable, and as far as I can tell works.
Basically your argument only makes sense if each terminal allows an
explicit size argument in the term options. Then the "set size" option
simply allows you to scale the plot within those bounds.
--
___ ____ ____
______/ \__// \__/____\ Robert Hart
_/ \_/ : //____\\ 15 Benington Drive
/| : : .. / \ Wollaton
| | :: :: \ / Nottingham
| | :| || \ \______/ NG8 2TF
| | _ || || __ |\ / |
\| || || | / | \ en...@no...
| ___ || ___ || ____ | / /_\ \
| _ || _ || __ | / / \ http://www.nott.ac.uk/~enxrah
\___/ \___/ | |/__/ \
_\____/ \ /
/____ /
/ \ /
\______\_________/
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-05 16:55:38
|
On Wednesday 05 October 2005 03:17 am, Robert Hart wrote: > Basically your argument only makes sense if each terminal allows an > explicit size argument in the term options. Then the "set size" option > simply allows you to scale the plot within those bounds. I agree. So let's add a "size XX,YY" option to those terminals where it is currently missing. For pixel-based terminals this is trivial. I've just done so for PBM. [*] For PostScript-like terminals it is a bit more complicated, since the output file eventually needs the 4 corners of a bounding box rather than just a width and height. What would you prefer: set term post eps size XX,YY more consistent with pixel-based terminals, but no explicit control over placement on page set term post eps boundingbox x1,y1,x2,y2 corresponds exactly to what will appear in the *.eps file For PostScript proper (as opposed to eps), I would prefer a different approach. I propose instead to update the patch #908040 that almost made it into version 4.0, which breaks out the PostScript prolog text into an external file that can be locally customized. Then you could have an A4 prolog, a USLetter prolog, and so on. This mechanism allows great flexibility in locally configuring the PostScript output without having to modify gnuplot itself. The main stumbling block at the time was figuring out where to store such an external file on a MSWin box. I am the wrong person to sort this out, but I can't believe it's an insurmountable hurdle. [*] Side Note: the generic bit-map routines in bitmap.c are in serious need of clipping tests. Right now if you select a too-small bitmap dimension, the use of unsigned ints to represent coordinates bites in a big way. Any coordinate that tries to go negative wraps to a ridiculously large number instead, essentially sending the code into an infinite loop. Try "set size .1,.1; set term pbm; test". One more example of why I think we should try to rid the core routines of using "unsigned int" for coordinates. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Juergen W. <wie...@fr...> - 2005-10-06 07:42:41
|
Ethan Merritt wrote: > For PostScript-like terminals it is a bit more complicated, since the > output file eventually needs the 4 corners of a bounding box rather > than just a width and height. What would you prefer: > > set term post eps size XX,YY > > more consistent with pixel-based terminals, > but no explicit control over placement on page > > set term post eps boundingbox x1,y1,x2,y2 > > corresponds exactly to what will appear in the *.eps file I'd like the option to set it using arbitrary dimensions. Something like set term post eps size 8cm, 5cm set term post eps size 5in, 3in really should be possible. Personally, I don't see any need for an explicit bounding box specification. But if someone does, I'm fine with it -- as long as there is also some "size" option. Juergen |
|
From: Aapo L. <aap...@gm...> - 2005-10-06 08:43:49
|
On Thu, 2005-10-06 at 09:42 +0200, Juergen Wieferink wrote: > I'd like the option to set it using arbitrary dimensions. Something > like > > set term post eps size 8cm, 5cm > set term post eps size 5in, 3in > > really should be possible. Personally, I don't see any need for an > explicit bounding box specification. But if someone does, I'm fine > with it -- as long as there is also some "size" option. Yes, that would be a good thing. One thing that Gnuplot is very good at is its ability to produce very clean and good-looking plots for inclusion in documents. Unfortunately, it's little difficult to have plot canvas in an exact arbitrary size, as you described. Of course, scaling of the image is not feasible, as linewidths and font sizes in the document wouldn't be consistent after the scaling. The obvious workaround (which works for me anyway) is to fiddle around with the size parameter, which as discussed can quite freely be choosed in range [0,1]. But for a newcomer it surely is irritating that you can't set the explicit bounding box in the unit of your choice. That makes integration with LaTeX documents a little more difficult, but not impossible. One difficult thing is a0 posters: it is not possible to make big enough eps images with Gnuplot to be included into an a0 poster. Of course, there is a workaround; one just plots everything in smaller scale in Gunplot (a4 vs a0), and scales the result back into a0. However, the calculations with font sizes and linewidths are something that a user shouldn't need to do. Many fellow students around here rather use Origin (a windows GUI driven plotting program), because it seems not to have such limitation. However, Origin is not a solution for me, because a) Origin eps files are crap b) usually Origin plots look hideous c) I rather use Linux d) I'm (usually) able to workaround the Gnuplot oddities. Anyway, because there are different paper sizes possible in postscript and because eps figures are of different size by their nature, there really should be such a size option as you suggested. But I think its name should not be "size", because the "size" is already a reserved keyword for "set" and it would cause confusion. How would e.g. set term post eps canvas 8cm, 5cm set term post canvas a0 sound? Is this kind of behaviour possible to implement for just one terminal driver without touching others? This way there would be no need to change the "set size" behaviour at all, and by choosing default a4 size canvas for postscript, there would be perfect backward compatibility. Aapo |
|
From: V. <gae...@no...> - 2005-10-06 11:20:54
|
On Thu, Oct 06, 2005 at 11:43:34AM +0300, Aapo Lankinen wrote:
> > set term post eps size 8cm, 5cm
> > set term post eps size 5in, 3in
> The obvious workaround (which works for me anyway) is to fiddle around
> with the size parameter, which as discussed can quite freely be choosed
> in range [0,1]. But for a newcomer it surely is irritating that you
> can't set the explicit bounding box in the unit of your choice. =20
I must say I fully agree. Such an option would be extremely useful.
And adding it to epslatex and metapost terminals could be useful too.
--
Ga=EBl
|
|
From: Juergen W. <wie...@fr...> - 2005-10-06 11:42:17
|
Aapo Lankinen wrote: > Anyway, because there are different paper sizes possible in postscript > and because eps figures are of different size by their nature, there > really should be such a size option as you suggested. But I think its > name should not be "size", because the "size" is already a reserved > keyword for "set" and it would cause confusion. How would e.g. > > set term post eps canvas 8cm, 5cm > set term post canvas a0 Well, there is a "size" option for the bitmap drivers, as noted upthread. So I think "size" is the right way to go. It might be a good idea to rename these option to the more meaningful "canvas". I'm not sure. > sound? Is this kind of behaviour possible to implement for just one > terminal driver without touching others? This way there would be no > need to change the "set size" behaviour at all, and by choosing default > a4 size canvas for postscript, there would be perfect backward > compatibility. I'm pretty sure this is possible. The terminal drivers are almost completely independent from each other, even in parsing their terminal options. But the "set size" behaviour would have to change, I think. Something like set size 1/sqrt(2), sqrt(2) set term post eps to change to portrait EPS wouldn't work no more. Well, one could use the "set size" setting at the time of the "set term" command as default canvas size (relative to the hardwired default) if no other size is given. ... Did I mention that I don't like the command line syntax of gnuplot very much? Juergen |
|
From: Harald H. <h.h...@tu...> - 2005-10-06 19:12:01
|
[... a lot of discussion about sizes above 1 ...]
In my opinion, there are two mutually exclusive solutions:
1.) 'set size' before 'set terminal' can affect the canvas size. Then,
sizes below and above 1 have to be valid because then 'size 1,1' means the
default size. Partly, this is the current state while sizes > 1 only work
partly.
2.) 'set size' only affects the size of the plot within the current
canvas while the canvas (or bouding box or what ever) is influenced by
another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
possible values can be different for different terminals, e.g.,
set terminal postscript size 5cm,3cm
set terminal postscript eps size 300pt,200pt
set terminal postscript eps size 300,200 # could default to pt
set terminal postscript eps size 300,200 offset 100,150
# results in %%BoundingBox: 100 150 400 350
set terminal gif size 300,200 # defaults to pixel
set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi
To me it was nonsense to use 'set size' to reduce the canvas size and to
forbid to enlarge the canvas size using it.
For compatibility reasons, the first solution could be useful, while the
second solution is more clear and introduces a new important feature.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: V. <gae...@no...> - 2005-10-06 19:18:54
|
On Thu, Oct 06, 2005 at 09:17:04PM +0200, Harald Harders wrote:
> 2.) 'set size' only affects the size of the plot within the current
> canvas while the canvas (or bouding box or what ever) is influenced by
> another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> possible values can be different for different terminals, e.g.,
> set terminal postscript size 5cm,3cm
> set terminal postscript eps size 300pt,200pt
> set terminal postscript eps size 300,200 # could default to pt
> set terminal postscript eps size 300,200 offset 100,150
> # results in %%BoundingBox: 100 150 400 350
> set terminal gif size 300,200 # defaults to pixel
> set terminal gif size 1in,1in resolution 300 # =3D 300 x 300 pixel, 3=
00dpi
> For compatibility reasons, the first solution could be useful, while th=
e
> second solution is more clear and introduces a new important feature.
I vote for 2nd solution.
--
Ga=EBl
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-06 19:46:47
|
On Thursday 06 October 2005 12:17 pm, Harald Harders wrote:
>
> [... a lot of discussion about sizes above 1 ...]
>
> In my opinion, there are two mutually exclusive solutions:
>
> 1.) 'set size' before 'set terminal' can affect the canvas size. Then,
> sizes below and above 1 have to be valid because then 'size 1,1' means the
> default size. Partly, this is the current state while sizes > 1 only work
> partly.
I am being educated about this use of "set size". It's not the way I
have been using it, but I fully understand the argument about not
necessarily wanting to scale line widths and font sizes with the
graph size. So I retract my previous claim that sizes greater than 1
are never correct.
But, as you say, it only partly works now.
For instance, setting the size to something other than 1,1 before
setting the terminal seems to break multiplot layouts.
> 2.) 'set size' only affects the size of the plot within the current
> canvas while the canvas (or bouding box or what ever) is influenced by
> another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> possible values can be different for different terminals, e.g.,
> set terminal postscript size 5cm,3cm
> set terminal postscript eps size 300pt,200pt
> set terminal postscript eps size 300,200 # could default to pt
> set terminal postscript eps size 300,200 offset 100,150
> # results in %%BoundingBox: 100 150 400 350
> set terminal gif size 300,200 # defaults to pixel
> set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi
That is the way I would prefer to have it work.
The range of reasonable canvas sizes is clearly terminal-dependent,
so choosing a size should done in the terminal-specific initialization.
It will mean modifying drivers, but it seems straightforward.
Next problem:
The harder task related to this is the larger issue of remedying
the lack of line and text clipping in the core routines.
Right now "set size 0.1,0.1; set term <foo>; test"
will crash on many terminal types because the various
lines and text on the test page are not clipped against the
reduced canvas size. Regular plotting is somewhat better, since
the actual plot elements are properly clipped. But elements such
as the key, title, and individually placed arrows or labels are
not clipped and still prone to cause segfaults. The pdf terminal
is particularly sensitive to this, but all drivers that use
the shared routines in bitmap.c suffer the same problem.
The code in the current clipping routines would do the job,
except currently it explicitly clips to the plot area, not the canvas.
I think the way forward is to:
1) move xright, xleft, ytop, ybot into a new structure, e.g.
struct {int xright; int xleft; int ytop; int ybot;} bounding_box.
2) create and maintain two global instances of such a structure;
one that describes the plot area, another that describes the
whole canvas.
3) modify the clip_line() and clip_point() to clip against whichever
bounding_box structure is currently active
4) Existing calls to the clipping routines will continue to
work as always, and clip against the plot area.
Any code that needs to place elements outside the plot (key, title,
arrows, axis lables, ...) would change the active bounding_box
to the entire canvas, clip, and then restore the bounding_box.
At that point we would have protected all drivers against
out-of-range vectors and moves. Text clipping would not be
perfect, but better than it is now.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Petr M. <mi...@ph...> - 2005-10-06 21:41:07
|
Shouldn't there be "set term post eps scale nx,ny" to scale the canvas to a given size? (Gnuplot could be used for making highway billboards :-) Further, what I miss is a "scale", mainly for an inset figure inside another figure (i.e., in multiplot). It would scale the figure with all linewidth, fonts etc. Or rather "fontscale"... --- PM |
|
From: Harald H. <h.h...@tu...> - 2005-10-06 22:32:58
|
On Thu, 6 Oct 2005, Ethan Merritt wrote:
> On Thursday 06 October 2005 12:17 pm, Harald Harders wrote:
> >
> > [... a lot of discussion about sizes above 1 ...]
> >
> > In my opinion, there are two mutually exclusive solutions:
> >
> > 1.) 'set size' before 'set terminal' can affect the canvas size. Then,
> > sizes below and above 1 have to be valid because then 'size 1,1' means the
> > default size. Partly, this is the current state while sizes > 1 only work
> > partly.
>
> I am being educated about this use of "set size". It's not the way I
> have been using it, but I fully understand the argument about not
> necessarily wanting to scale line widths and font sizes with the
> graph size. So I retract my previous claim that sizes greater than 1
> are never correct.
>
> But, as you say, it only partly works now.
> For instance, setting the size to something other than 1,1 before
> setting the terminal seems to break multiplot layouts.
Do you mean the automatic ones? I always to multiplots by hand and they
also work for plots with sizes greater than 1.
> > 2.) 'set size' only affects the size of the plot within the current
> > canvas while the canvas (or bouding box or what ever) is influenced by
> > another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> > possible values can be different for different terminals, e.g.,
> > set terminal postscript size 5cm,3cm
> > set terminal postscript eps size 300pt,200pt
> > set terminal postscript eps size 300,200 # could default to pt
> > set terminal postscript eps size 300,200 offset 100,150
> > # results in %%BoundingBox: 100 150 400 350
> > set terminal gif size 300,200 # defaults to pixel
> > set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi
>
> That is the way I would prefer to have it work.
> The range of reasonable canvas sizes is clearly terminal-dependent,
> so choosing a size should done in the terminal-specific initialization.
> It will mean modifying drivers, but it seems straightforward.
I agree. Sounds like a plan and a lot of work.
> Next problem:
>
> The harder task related to this is the larger issue of remedying
> the lack of line and text clipping in the core routines.
> Right now "set size 0.1,0.1; set term <foo>; test"
> will crash on many terminal types because the various
> lines and text on the test page are not clipped against the
> reduced canvas size. Regular plotting is somewhat better, since
> the actual plot elements are properly clipped. But elements such
> as the key, title, and individually placed arrows or labels are
> not clipped and still prone to cause segfaults. The pdf terminal
> is particularly sensitive to this, but all drivers that use
> the shared routines in bitmap.c suffer the same problem.
>
> The code in the current clipping routines would do the job,
> except currently it explicitly clips to the plot area, not the canvas.
> I think the way forward is to:
>
> 1) move xright, xleft, ytop, ybot into a new structure, e.g.
> struct {int xright; int xleft; int ytop; int ybot;} bounding_box.
>
> 2) create and maintain two global instances of such a structure;
> one that describes the plot area, another that describes the
> whole canvas.
>
> 3) modify the clip_line() and clip_point() to clip against whichever
> bounding_box structure is currently active
>
> 4) Existing calls to the clipping routines will continue to
> work as always, and clip against the plot area.
> Any code that needs to place elements outside the plot (key, title,
> arrows, axis lables, ...) would change the active bounding_box
> to the entire canvas, clip, and then restore the bounding_box.
>
> At that point we would have protected all drivers against
> out-of-range vectors and moves. Text clipping would not be
> perfect, but better than it is now.
May be we should start with this task of two different clipping boxes
(plot and canvas). Then, the rest could be done sequencially.
I still have the idea that there should be a terminal-independent option
that changes the size of the canvas by a factor. I am aware that this
would be difficult to explain because a thing like
set canvasscale 1.5,1.5
set terminal png size 640,480
would lead to a picture of the size 960 x 720 which seams pretty
unlogical. But in some cases such a function could be useful. For some
terminals this new function would then do the same as a 'set size' before
'set terminal' does now. But I think, this functionality could be added
after providing a clean solution for differentiation between plot size and
canvas size.
Best regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-06 22:44:48
|
On Thursday 06 October 2005 03:38 pm, Harald Harders wrote: > > I still have the idea that there should be a terminal-independent option > that changes the size of the canvas by a factor. I am aware that this > would be difficult to explain because a thing like > set canvasscale 1.5,1.5 > set terminal png size 640,480 > would lead to a picture of the size 960 x 720 which seams pretty > unlogical. That is, in fact, what "set size" + "set term png size XX,YY" has done all along. The fact that I didn't even know this myself until testing shows that it is not obvious :-) -- 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-10-06 22:18:48
|
On Thursday 06 October 2005 02:41 pm, Petr Mikulik wrote: > Shouldn't there be "set term post eps scale nx,ny" to scale the canvas to a > given size? (Gnuplot could be used for making highway billboards :-) This is the sort of example I originally had in mind. If you are trying to scale up an eps figure uniformly, to highway billboard size for example, you don't *need* a scale parameter because the eps format is inherently scalable. Yes, the lettering will be half a meter tall and the lines a couple of cm thick, but that way they can be read by passing motorists. What I have learned is that people want to change the size of the figure *without* scaling the font size or line widths. The current "set size" command does this, but does not do a very consistent job of it. > Further, what I miss is a "scale", mainly for an inset figure inside another > figure (i.e., in multiplot). It would scale the figure with all linewidth, > fonts etc. Or rather "fontscale"... Are you saying that you do, or do not, want the fonts to change size if the figure changes size? I should also point out that the existing PostScript and eps output offers a possible easy fix to at least part of this dilemma if you are willing to use an editor. The following line appears near the very top of the output file: /gnulinewidth 5.000 def If you are planning to scale up your plot by a factor of 2 and don't want the line widths to became twice as thick, you can replace that with /gnulinewidth 2.500 def We could, I think, do exactly the same with font sizes by introducing a global multiplier in the header /gnufontsize 1.000 def -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-10-07 07:48:47
|
> One difficult thing is a0 posters: it is not possible to make big enough > eps images with Gnuplot to be included into an a0 poster. Of course, > there is a workaround; one just plots everything in smaller scale in > Gunplot (a4 vs a0), and scales the result back into a0. However, the > calculations with font sizes and linewidths are something that a user > shouldn't need to do. Using scalable fonts, it is feasible using "set termoptions font ..." <= it's only here you give the font scale. Now, we miss "set termoptions linewidth x" to scale in the same way. > Origin (a windows GUI driven plotting program), because it seems not to > have such limitation. I would combine several eps plots together using Xfig, or LaTeX. > set term post eps canvas 8cm, 5cm > set term post canvas a0 Actually there are two possibilities what this "8cm" can mean: - scalable size - non-scalable size I think there is some unity in the postscript definition which will keep the true dimension, whatever preceding "x y scale" command is. Something like "8 25.4 mul truept" vs "8 25.4 mul pt". But I don't know the details. --- PM |
|
From: Harald H. <h.h...@tu...> - 2005-10-08 18:16:00
|
On Fri, 7 Oct 2005, Petr Mikulik wrote: > > One difficult thing is a0 posters: it is not possible to make big enough > > eps images with Gnuplot to be included into an a0 poster. Of course, > > there is a workaround; one just plots everything in smaller scale in > > Gunplot (a4 vs a0), and scales the result back into a0. However, the > > calculations with font sizes and linewidths are something that a user > > shouldn't need to do. > > Using scalable fonts, it is feasible using "set termoptions font ..." <= > it's only here you give the font scale. Now, we miss "set termoptions > linewidth x" to scale in the same way. > > > Origin (a windows GUI driven plotting program), because it seems not to > > have such limitation. > > I would combine several eps plots together using Xfig, or LaTeX. > > > set term post eps canvas 8cm, 5cm > > set term post canvas a0 > > Actually there are two possibilities what this "8cm" can mean: > - scalable size > - non-scalable size In my opinion, with canvas 8cm,5cm, a BoundingBox with a width of 8cm=227pt and height of 5cm=142pt has to be ment, e.g. %%BoundingBox: 50 50 277 192 Thus, the measure has to be non-scalable. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Petr M. <mi...@ph...> - 2005-10-07 08:07:14
|
> I should also point out that the existing PostScript and eps output > offers a possible easy fix to at least part of this dilemma if you > are willing to use an editor. The following line appears near the > very top of the output file: > /gnulinewidth 5.000 def > > If you are planning to scale up your plot by a factor of 2 and > don't want the line widths to became twice as thick, you can replace > that with > /gnulinewidth 2.500 def I've just noticed there is also /userlinewidth, but it does not change anything? Isn't this a bug? Another strange thing: I've put two plots (two pages) into postscript file. There is /gnulinewidth 5.000 def in the header. Now, I wanted to increase the linewidth 5 times on the 2nd page by this change: grestore end showpage %%Page: 2 2 gnudict begin gsave /gnulinewidth 25.000 def 50 50 translate 0.100 0.100 scale However, it changed also the line width on the first page! Why?! ... or is it a bug in ghostscript? When it draws it 1st time, then it is ok, but when you go back from the 2nd to the 1st page (gv, gsview), the linewidth gets wrong. That's probably the value of the variable was overwritten in the dictionary? Question: how to organize different linewidths on different pages, or rather in different subplots? > We could, I think, do exactly the same with font sizes by introducing > a global multiplier in the header > /gnufontsize 1.000 def This would be useful. --- PM |
|
From: Harald H. <h.h...@tu...> - 2005-10-08 18:15:58
|
On Fri, 7 Oct 2005, Petr Mikulik wrote: > Question: how to organize different linewidths on different pages, or rather > in different subplots? > > > We could, I think, do exactly the same with font sizes by introducing > > a global multiplier in the header > > /gnufontsize 1.000 def > > This would be useful. I don't think it is too useful since the layout changes depending on the font size. Thus, a subsequent change in the Postscript output leads to bad results. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
