gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [gnuplot-beta]Re: metapost terminal

[Hans-Bernhard B. <br...@ph...>]

On Tue, 8 Jun 2004, Andrzej [utf-8] W=C4=85sowski wrote:

> Ethan A Merritt <merritt <at> u.washington.edu> writes:
>=20
> > With their guidance I have patched the terminal to support text r=
otation
> > and filled boxes.  I do not know how to add pattern-fill, but for=
 the moment
> > I have dummied it up with different solid fill densities.
>=20
> This is actually the reason, why I have not followed-up yet. It is =
not
> straightforward to do pattern fills with metapost. I think one need=
s to draw the
> patterns (generate metapost code to do it) and then clip the to the=
 box.=20

Not necessarily.  The general method for platforms that don't support
patterns in some native way is to draw them as lots of individual lin=
es.
That's possible because we do pattern-filling only for boxes.

> I have noticed also another difference. The grid lines are solid in
> metapost output and dashed (dotted?) in postscript output. Shall I =
look
> into making those the same?

Not necessary.  As long as the grid line style is noticably lighter t=
han
the borders, you're OK.  Some terminals dot it, some draw it in gray,=
 some
others combine those two.

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[gnuplot-beta]Re: metapost terminal

[Andrzej <wa...@ga...>]

Ethan A Merritt <merritt <at> u.washington.edu> writes:

> With their guidance I have patched the terminal to support text rotation
> and filled boxes.  I do not know how to add pattern-fill, but for the moment
> I have dummied it up with different solid fill densities.

This is actually the reason, why I have not followed-up yet. It is not
straightforward to do pattern fills with metapost. I think one needs to draw the
patterns (generate metapost code to do it) and then clip the to the box. So the
first thing is to get the patterns. Where can I get the patterns that are
supposed to be supported? Is it only boxes that we need to support with patterns?

I have noticed also another difference. The grid lines are solid in metapost
output and dashed (dotted?) in postscript output. Shall I look into making those
the same?

> However, I notice that the line colors and point styles do not match
> those of other terminal types.  We changed many (though not all)
> terminals a year ago to match each other as closely as possible at
> least for the first 8 line colors and first 12 point styles. In particular,
> almost all terminals supporting color assign  linetypes 1, 2, 3 to be
> red, green, blue. Metapost uses instead black, red, blue.

I think it is better to have consistent colors, although I find metapost driver
colors much, much, much, oh so much, more appealing than postscript colors (at
least the first 8). Since metapost supports RGB colors I think it should be easy
to get exactly the same colors in both drivers (all 64 AFAIR). I hope that
current metapost colors are among these.

Andrzej

Re: [gnuplot-beta]metapost terminal

[Hans-Bernhard B. <br...@ph...>]

On Tue, 8 Jun 2004, Daniel H. Luecking wrote:

> Well, I did seek guidence when I chose the colors.  The best I could get
> was the advice that they should be distinguishable, and black is easy to
> distinguish from almost anything. 

But we're already using black for the borders, tick marks,  and all kinds
of text in the graph.  You usually want to be distinguishable from those, 
too.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [gnuplot-beta]metapost terminal

[Daniel H. L. <lue...@ua...>]

On Tue, 8 Jun 2004, Hans-Bernhard Broeker wrote:

> On Mon, 7 Jun 2004, Ethan A Merritt wrote:
>
> > Should I re-order the line and point types in the metapost driver to
> > match other drivers?
>
> I don't see any strong reason why not.  Note that lt -1 (the border line
> type) is generally the *only* solid black line type, in most other
> terminal drivers.  I.e. black should not show up as any other line type
> but -1 (internally -2).

Well, I did seek guidence when I chose the colors.  The best I could get
was the advice that they should be distinguishable, and black is easy to
distinguish from almost anything. Color for its own sake seems
irrational but I am all for consistency between terminals.

Dan

-- 
Dan Luecking                           Dept. of Mathematical Sciences
lue...@ua...                      University of Arkansas
http://comp.uark.edu/~luecking/        Fayetteville, AR 72101

Re: [gnuplot-beta]metapost terminal

[Hans-Bernhard B. <br...@ph...>]

On Mon, 7 Jun 2004, Ethan A Merritt wrote:

> Should I re-order the line and point types in the metapost driver to
> match other drivers?  

I don't see any strong reason why not.  Note that lt -1 (the border line
type) is generally the *only* solid black line type, in most other
terminal drivers.  I.e. black should not show up as any other line type
but -1 (internally -2).

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

[gnuplot-beta]metapost terminal

[Ethan A M. <merritt@u.washington.edu>]

Thanks to Andrzej W=C4=85sowski and Dan Luecking, I now know how to=20
run the output of 'set term mp' through mpost + latex + dvips to see
what it is doing.

With their guidance I have patched the terminal to support text rotation
and filled boxes.  I do not know how to add pattern-fill, but for the mom=
ent
I have dummied it up with different solid fill densities.

However, I notice that the line colors and point styles do not match
those of other terminal types.  We changed many (though not all)
terminals a year ago to match each other as closely as possible at
least for the first 8 line colors and first 12 point styles. In particula=
r,
almost all terminals supporting color assign  linetypes 1, 2, 3 to be
red, green, blue. Metapost uses instead black, red, blue.

While I can see the logic behind having "lt 1" produce a black line,
the other terminal types don't do it that way. Instead, all terminal type=
s
that I know of provide black (or at least "foreground") as linetype -1.

Should I re-order the line and point types in the metapost driver to
match other drivers? =20

--=20
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Metapost terminal and rotation

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 05 June 2004 05:08 pm, Andrzej W=C4=85sowski wrote:
> I am not posting these corrections as proper patches, but just showing
> them here, as being new to gnuplot, and even newer to its code, I canno=
t
> be even sure i fall this is sane.=20

If it works on the output from the "test" command, and also on
the demo file "textrotation.dem" then I think it is probably fine.

> In fact the thing above seems so
> obvious, that I suspect there must be a reason, why it is not there
> already

The main reason is reluctance to change code that I don't know how
to test.  I added text rotation to many terminal types about a year ago,
but I didn't know then (and still don't!) how to use or test metapost out=
put.

If you are willing to contribute your metapost expertise towards
improving the gnuplot metapost driver, then everybody wins.

Out of curiosity, have you run "load all.dem" in metapost to
find out how many of the newer gnuplot features actually work
for this terminal type?  How does PM3D output look?

--=20
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Metapost term and solid filling

[Hans-Bernhard B. <br...@ph...>]

On Sun, 6 Jun 2004, Andrzej [utf-8] W=C4=85sowski wrote:

> Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:
[...]

> So, if I get you right, some kind of fix would not be out of scope =
here.

Of course not.  Except that an implementation of a previously missing
feature is not actually a "fix".=20

[...]
> This is not quite the answer, I expected. I guess I am exactly yhe =
guy, who
> tries to sit down and implement the thing. I meant: is there any te=
chnical
> reason making this simple hack would not work?

None I would be aware of --- but then, I don't speak Metapost.

> Is the gnuplot project interested in patches of this kind, or shall=
 I
> just keep them in my private set of patches to gnuplot?=20

Yes, and no.  In that order.

Please do post a complete patch, preferrably into the Patch Tracker a=
t our
SourceForge site.  And subscribe to this mailing-list, so I don't hav=
e to
manually approave each of your mails to it ;-)

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Should we keep this list subscriber-only?

[Hans-Bernhard B. <br...@ph...>]

On Sun, 6 Jun 2004, Dave Denholm wrote:

> One problem with automatically sending back a reply is that if
> most of the incoming mail is junk, we are adding to the problem of
> unsolicited mails bouncing around the network.

Fulll ACK.  These days, completely useless "Virus found in your mail"
notices (including the particularly helpful ones in Finnish, Frensh and
whatever language you can imagine) already make up the majority of what
junk mail actually ends up in my inbox, after the virus scanner and the
spam assassin have done their job.  We *don't* want to add to that if we
can possibly help it.  And with the current setup of our SF mailing lists,
I think we're doing the right thing on that front.

> One game that people seem to play is sending mail to one list with a
> from field of another list. 

I'm quite sure it's not people who are playing this game, but clueless
mail worms and their equally clueless cousins, the address harvesters used
to fill spammers' mailing lists.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Should we keep this list subscriber-only?

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Thursday 03 June 2004 09:18 am, Hans-Bernhard Broeker wrote:
>>
>> Before changing this, I'ld like a poll.  So: if anybody has strong
>> opinions in either direction, please voice them soon.
>
> I'd rather keep the list subscriber-only, and if possible to 
> auto-generate a reply to non-subscribed messages that
> says something like:
>
> This is a subscriber-only mailing list for discussion of 
> gnuplot development.  
>

One problem with automatically sending back a reply is that if
most of the incoming mail is junk, we are adding to the problem of
unsolicited mails bouncing around the network.

One game that people seem to play is sending mail to one list with a
from field of another list. So any automated replies get sent back
to the other list. (I block a lot of junk mail to the gnuplot
lists which looks like it's auto-replies from other lists)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Metapost term and solid filling

[Andrzej <wa...@ga...>]

Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:
> As is explained somewhere in the docs (or so I think...), not all terminal
> drivers support all features of gnuplot.  metapost, e.g., has a boxfill
> function, but that predates the addition of filled boxes plotting style to
> gnuplot by several years --- it's from the time when the only usage of
> term->fillbox was by the 'clear' command, to clear an area for an inset
> plot.

So, if I get you right, some kind of fix would not be out of scope here.

> It's still incomplete, though: you should support patterned fill styles,
> too.

Yeah. I see the point. This may actually be a problem. I have no clue, how
patterns interface works and there seems to be no simple way to fill with
patterns in MetaPost (besides drawing the patterns explicitly). There are some
packages around, but I guess gnuplot should not depend on them, so there is some
 more effort to put in here.

> > My question is: why is this not implemented this way? 
> 
> Simple: because nobody sat down and implemented it.  This is open source,
> which means that in the essence nothing ever gets done until somebody
> mounts up the initiative to do it.

This is not quite the answer, I expected. I guess I am exactly yhe guy, who
tries to sit down and implement the thing. I meant: is there any technical
reason making this simple hack would not work?

Is the gnuplot project interested in patches of this kind, or shall I just keep
them in my private set of patches to gnuplot? If there is some interest, what is
the usual procedure? Sourceforge patches or posting for discussion here first?

Andrzej

Re: Metapost term and solid filling

[Hans-Bernhard B. <br...@ph...>]

On Sun, 6 Jun 2004, [iso-8859-2] Andrzej W=B1sowski wrote:

> Hi,
>=20
> I am trying to use the metapost terminal to produce a bar chart
> (boxes). One of the several problems I have is that despite that
> style solid is on, metapost term just outputs line drawing.=20

As is explained somewhere in the docs (or so I think...), not all ter=
minal
drivers support all features of gnuplot.  metapost, e.g., has a boxfi=
ll
function, but that predates the addition of filled boxes plotting sty=
le to
gnuplot by several years --- it's from the time when the only usage o=
f
term->fillbox was by the 'clear' command, to clear an area for an ins=
et
plot.

> This version produces excellent boxes plots (in fact metapost proce=
ssed
> gnuplot graphs are so much more beatiful than those produced with
> postscript term directly!).=20

It's still incomplete, though: you should support patterned fill styl=
es,
too.

> My question is: why is this not implemented this way?=20

Simple: because nobody sat down and implemented it.  This is open sou=
rce,
which means that in the essence nothing ever gets done until somebody
mounts up the initiative to do it.

--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Multiplot fails in postscript mode

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>On Saturday 05 June 2004 09:47 am, Daniel J Sebald wrote:
>  
>
>>Anyway, the immediate issue is the difficulty in which to get multiplots
>>laid out in anything but the default manner.
>>    
>>
>
>[snip example of stacked plots]
>
>  
>
>>Bottom line: can anyone think of a syntax and scheme that would allow
>>better control for this?
>>    
>>
>
>I think we already have it.
>	set {b|l|r}margin 0
>
>That should line all the plots up regardless of labels or tics,
>at the cost of having to explicitly position them in from the page
>boundary.
>

Right...  This is the kind of thing there should be a 5 page tutorial 
for, or a demo.  Something titled "Plot Layout".

>One remaining issue for such stacked plots, however, is trying
>to collect all of the plot labels into a single key.  I can't think of
>an easy way to do that.
>

That is a problem.  But in this case it was a bunch of stacked 
histograms, i.e., no real white space within the plots.  So the key 
would cover up some information, and not really provide anything useful.

>Is there something else missing?
>

No, I think that does the trick.  Thanks Ethan.

Dan

Re: Multiplot fails in postscript mode

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Sat, 5 Jun 2004, Daniel J Sebald wrote
>
>But all is not lost yet.  This situation is exactly what 'set lmargin' and
>friends exist for.  They let you fix the relation between the plot and the
>graph by overriding the automatically determined margins.
>

Ethan A Merritt wrote:

>On Saturday 05 June 2004 09:47 am, Daniel J Sebald wrot
>
>Is it sufficient to add the single command "set bmargin 0", 
>and manually leave room for the tic labels, as in the modification
>I made to your script above? 
>

Yes, that is EXACTLY what I'm looking for.  By setting all the margins 
to zero, I now have accurate control of the border lengths by using "set 
size" and "set origin".  Thanks.

This should have dawned on me.  I wrote a patch to change the margin 
variables inside gnuplot to floats instead of ints.  At the time I did 
that patch, I was probably thinking that fine tuning of the plot should 
be done using the margin settings, which when they are int variables 
doesn't work so well.  But setting margins to 0 is the way to go in the 
situation I have.

Dan

Re: Multiplot fails in postscript mode

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 05 June 2004 09:47 am, Daniel J Sebald wrote:
>
> Anyway, the immediate issue is the difficulty in which to get multiplots
> laid out in anything but the default manner.

[snip example of stacked plots]

> Bottom line: can anyone think of a syntax and scheme that would allow
> better control for this?

I think we already have it.
	set {b|l|r}margin 0

That should line all the plots up regardless of labels or tics,
at the cost of having to explicitly position them in from the page
boundary.

One remaining issue for such stacked plots, however, is trying
to collect all of the plot labels into a single key.  I can't think of
an easy way to do that.  

Is there something else missing?

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Metapost terminal and rotation

[<wa...@ga...>]

Hi,

yet another problem with the metapost term is rotation. I was trying to
produce some rotated labels, and apparently all non 0 angle labels are
treated as vertical, as in very weak terminals, which is a bit of a
shame in metapost. In fact I think it is easier to rotate as needed than
to coerce everything to 0 or 90. This fix works for me:

--- term/metapost.trm	2004-06-06 01:53:12.605250704 +0200
+++ ../gnuplot--mydev/term/metapost.trm	2004-06-06 01:55:09.716447096 +0200
@@ -532,11 +532,11 @@
   GPtext:=GPtext shifted\n\
     if j = 1: (-(ulcorner GPtext + llcorner GPtext)/2)\n\
     elseif j = 2: (-center GPtext)\n\
     else: (-(urcorner GPtext + lrcorner GPtext)/2)\n\
     fi\n\
-    rotated if r > 0: 90 else: 0 fi;\n\
+    rotated r;\n\
   draw GPtext shifted (x,y)\n\
 enddef;\n", gpoutfile);
 }
 
 TERM_PUBLIC void
@@ -756,11 +756,11 @@
 
 TERM_PUBLIC int
 MP_text_angle(int ang)
 {
     /* Metapost code does the conversion */
-    MP_ang = (ang ? 1 : 0);
+    MP_ang = ang; 
     return (TRUE);
 }
 
 TERM_PUBLIC int
 MP_set_font(const char *font)

I am not posting these corrections as proper patches, but just showing
them here, as being new to gnuplot, and even newer to its code, I cannot
be even sure i fall this is sane. In fact the thing above seems so
obvious, that I suspect there must be a reason, why it is not there
already (but it may well be that it is so, because metapost.trm had been
created based on some simpler trm file).

Andrzej

Metapost term and solid filling

[<wa...@ga...>]

Hi,

I am trying to use the metapost terminal to produce a bar chart
(boxes). One of the several problems I have is that despite that
style solid is on, metapost term just outputs line drawing. I looked
into the generated code and apparently right metapost fill commands are
note generated at all.

So I grabbed the CVS release of gnuplot and it does not seem that there
is any difference in there. Since I got the code it was pretty easy to
find the actual terminal file and patch it slightly:

--- term/metapost.trm	2004-04-13 19:24:34.000000000 +0200
+++ ../gnuplot--mydev/term/metapost.trm	2004-06-05 22:56:44.833836616 +0200
@@ -799,22 +799,29 @@
 TERM_PUBLIC void
 MP_boxfill(sty, x1, y1, wd, ht)
 int sty;
 unsigned int x1, y1, wd, ht;
 {
     /* for now simply clear box if sty <= 0, do nothing otherwise */
     if (MP_inline)
 	MP_endline();
-    if (sty <= 0)
+    if (sty <= 0) {
 	fprintf(gpoutfile, "\
 fill (%.1fa,%.1fb)--(%.1fa,%.1fb)--(%.1fa,%.1fb)--(%.1fa,%.1fb)--cycle withcolor background;\n",
 		x1 / 10.0, y1 / 10.0, (x1 + wd) / 10.0, y1 / 10.0,
 		(x1 + wd) / 10.0, (y1 + ht) / 10.0, x1 / 10.0,
 		(y1 + ht) / 10.0);
+    } else {
+      fprintf(gpoutfile, "\
+fill (%.1fa,%.1fb)--(%.1fa,%.1fb)--(%.1fa,%.1fb)--(%.1fa,%.1fb)--cycle withpen (pencircle scaled 0pt);\n",
+	      x1 / 10.0, y1 / 10.0, (x1 + wd) / 10.0, y1 / 10.0,
+	      (x1 + wd) / 10.0, (y1 + ht) / 10.0, x1 / 10.0,
+	      (y1 + ht) / 10.0);
+    }
 }
 
This version produces excellent boxes plots (in fact metapost processed
gnuplot graphs are so much more beatiful than those produced with
postscript term directly!). 

My question is: why is this not implemented this way? 

The original maintainer might have a good reason (see the
comment: "do nothing otherwise"). I am not a gnuplot developer, so I
have no clue if this things breakes anything in other with-styles etc.

Andrzej

Re: Multiplot fails in postscript mode

[Hans-Bernhard B. <br...@ph...>]

On Fri, 4 Jun 2004, Lutz Maibaum wrote:

> I wasn't aware that this is what the "set size" command does. I though
> that it tells gnuplot that "whatever graph you plot, do it in a way that
> it covers the whole width of the output medium, but only half its
> height". I didn't expect the "set size" command to change the size of
> the output medium itself, which I thought was always 10"x7" for the
> postscript terminal.

Actually, 'set size' doesn't really modify the size of the PS output
medium --- it cannot possibly do that for a printer output format, because
the medium is a physical sheet of paper, and gnuplot can neither know what
size that actually is, nor can it do anything about it if it's not the
expected size, let alone "change the size" of it.  gnuplot doesn't own a
pair of scissors, nor a knife.

Instead, 'set size' in postscript multiplot will change the _bounding_box_
comment record put into the file.  Whether that bounding box information
has any effect on the final output is entirely in the hands of the
postscript interpreter and other tools --- gnuplot loses all power to
affect this the moment it closes the file.  Printers, e.g., will generally
ignore it, but word processors you paste a plot file into may honour it.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Multiplot fails in postscript mode

[Lutz M. <ma...@uc...>]

On Friday 04 June 2004 21:54, Ethan A Merritt wrote:
> Consider:
>
> 	set term png size 600,480
> 	set size 0.5, 0.5
> 	plot sin(x)
>
> 	set term png size 300,240
> 	set size 1,1
> 	plot sin(x)
>
> Both of these will produce a graph that occupies roughly 300x240
> pixels, but the first one will be surrounded by a lot of empty space
> in a large window.  The second one will be in a smaller window which
> it mostly fills.

This is exactly the behavior I would expect: you define the size of the 
created image (i.e., the resolution) in the "set term" command, and the size 
of a graph relative to the total image size using "set size".

> In the second plot of your example you told the postscript driver
> that it could only write to half of the total paper ("set size 1,0.5"),
> and so that's what it did.

I wasn't aware that this is what the "set size" command does. I though that it 
tells gnuplot that "whatever graph you plot, do it in a way that it covers 
the whole width of the output medium, but only half its height". I didn't 
expect the "set size" command to change the size of the output medium itself, 
which I thought was always 10"x7" for the postscript terminal.

  Lutz 

Re: Multiplot fails in postscript mode

[Hans-Bernhard B. <br...@ph...>]

On Sat, 5 Jun 2004, Daniel J Sebald wrote:

> wanted the following
> 
> 1)  6 x 1 configuration, i.e., six plots stacked vertically.
> 2)  Tic marks outside the borders because otherwise they would interfere 
> with what is in the plot.
> 3)  All six plots share the same x-axis.  Hence, to free up space, I 
> wanted only the bottom plot to have units and tic marks.
> 4)  I wanted just one y-axis label, centered somewhere between the third 
> and fourth plots.
> 
> OK, it is #3 that really poses the problem.  Here is a string of 
> commands that basically captures the ideas I used to lay out the multiplot:
[...]

> If you enter these commands, you'll see what the main issue is.  That 
> bottom plot is different in terms of label configuration.  The way 
> gnuplot works, when one says "size" it refers to the overall dimension 
> of the plot *including* labels.  

In the terms defined in "help glossary": 'set size' fixes the size of
the plot, not of the graph, based on the assumption that it's the "real"
size of the output (i.e. the plot, including all annotations outside the
graph box) you usually have to control.  

But all is not lost yet.  This situation is exactly what 'set lmargin' and
friends exist for.  They let you fix the relation between the plot and the
graph by overriding the automatically determined margins.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Hold On... (Re: Multiplot fails in postscript mode)

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> Bottom line: can anyone think of a syntax and scheme that would allow 
> better control for this?  For example, just as "coordinates" have a 
> "system" reference (i.e., `first`, `second`, `graph` or `screen`) 
> could it be possible for "size" to reference 'border' or 'overall' or 
> something like that.  The idea would be for some way to have the 
> borders of your plots be exactly the size you specify.  I don't think 
> I'm overlooking anything that would have made life simple here.  
> Thoughts? 


Hold on.  Maybe I did overlook an alternative.  One can solve the 
unequal borders problem by creating a phantom tic/unit for the top plots 
and placing a label for the bottom xlabel.  I.e.,

set multiplot
unset key
unset xlabel
set xtics nomirror
set xtics ("" 1e100)
set tics out
set size 0.95,0.35
set origin 0.05,0.6
plot sin(x)
set origin 0.05,0.315
plot sin(x+0.78540)
set origin 0.05,0.03
set xtics autofreq
set label 1 "amplitude" at screen 0.03,0.53 center rotate front
set label 2 "time (s)" at screen 0.53,0.03 center front
plot sin(x+1.5708)
unset multiplot

I'll just mumble to myself here for a while...

Dan

Re: Multiplot fails in postscript mode

[Daniel J S. <dan...@ie...>]

Lutz Maibaum wrote:

>Thank you very much for your explanations, Ethan and Hans. It seems that the 
>"size" setting has very different effects when evaluated by "set multiplot" 
>and by the plot command. It would be nice if this dual meaning could be 
>mentioned in the help entry of "set size".
>
>  Lutz
>  
>

Since this topic has come up...

I've thought for a while that a tutorial of plot layout would be a nice 
thing.  Something that illustrates the view, how size behaves, how 
coordinates behave, how labels get placed, etc.  But I'll put that in 
the "longterm" bin, i.e., maybe if ever some free time.

Anyway, the immediate issue is the difficulty in which to get multiplots 
laid out in anything but the default manner.  I'll give an example to 
illustrate the frustration.  I recently created a plot for which I 
wanted the following

1)  6 x 1 configuration, i.e., six plots stacked vertically.
2)  Tic marks outside the borders because otherwise they would interfere 
with what is in the plot.
3)  All six plots share the same x-axis.  Hence, to free up space, I 
wanted only the bottom plot to have units and tic marks.
4)  I wanted just one y-axis label, centered somewhere between the third 
and fourth plots.

OK, it is #3 that really poses the problem.  Here is a string of 
commands that basically captures the ideas I used to lay out the multiplot:

set multiplot
unset key
unset xlabel
unset xtics
set tics out
set size 0.95,0.3
set origin 0.05,0.7
plot sin(x)
set origin 0.05,0.4
plot sin(x+0.78540)
set origin 0.05,0.0
set xtics nomirror
set xlabel "time (s)"
set label 1 "amplitude" at screen 0.03,0.53 center rotate front
plot sin(x+1.5708)
unset multiplot

However, I had to do some tweaking of dimensions, but I left that undone 
here for illustration.

If you enter these commands, you'll see what the main issue is.  That 
bottom plot is different in terms of label configuration.  The way 
gnuplot works, when one says "size" it refers to the overall dimension 
of the plot *including* labels.  Hence, that bottom plot comes out 
smaller than all the rest.  No problem, you say.  Just issue a different 
size for the bottom plot, maybe

set size 0.95,0.4

Sure, but try it.  The trial an error process soon got the best of me. 
 You want the borders to be the same dimension (adjusting "size"), and 
you want the spacing between plots to be just right (adjusting 
"origin"), and you want the xlabel to not go too far off the view 
(adjusting "size" and "origin" again).  One could remove the xlabel and 
instead put another "label 2", but there is still the units and tics.

OK, if you've looked at the result of the commands above, you can 
imagine tweaking things with relative ease to get it to look right.  But 
now try getting things as you want using the "pslatex" terminal.  This 
isn't WYSIWYG, so it is the whole process over again; and this time one 
has to generate pslatex, compile tex, generate pslatex, compile tex, 
etc.  And you sort of need the X11 layout as a guide.  If you compare 
the layout parameters for proper pslatex layout, the X11 view looks like 
a mish-mash of overlapping plots and labels.

I eventually got what I wanted, and it looks great.  But it sure took 
enough time.

Bottom line: can anyone think of a syntax and scheme that would allow 
better control for this?  For example, just as "coordinates" have a 
"system" reference (i.e., `first`, `second`, `graph` or `screen`) could 
it be possible for "size" to reference 'border' or 'overall' or 
something like that.  The idea would be for some way to have the borders 
of your plots be exactly the size you specify.  I don't think I'm 
overlooking anything that would have made life simple here.  Thoughts?

Dan

Re: Multiplot fails in postscript mode

[Ethan A M. <merritt@u.washington.edu>]

On Friday 04 June 2004 04:56 pm, you wrote:

I'm not sure I can make things any clearer, but I'll try.

> The way I use gnuplot, I would have expected the following.
> "set multiplot": tells the plot command that the canvas shouldn't be
> cleared before the plot.

Not quite correct. "set multiplot" tells gnuplot that the canvas should not
be reset *after* the plot, or indeed after the next several plots leading
up to "unset multiplot".  It also tells gnuplot there are a number of other
things it should not allow while in multiplot mode (most of them pretty
obvious - like not change the terminal type).

> If I wanted to change the canvas size (for example, the resolution of a
> bitmap plot, or the paper size), I would expect this to be done using "set
> terminal <whatever> <canvas size>".

I was using "canvas" to refer to the subarea within the physical page
or window or piece of paper within which the plot lies.  The size of the
page or window or paper is a separate specification, and is unfortunately 
terminal-specific. For instance
	set term png size 600,480
	set term dumb 79 49
Perhaps even more unfortunately, there is no such option for the
PostScript terminal.  That may be the real bug here, if there is one. 

Anyhow, "set size" is independent of this, and controls how much of that
terminal size (or page size) can be written on by the next plot.

Consider:

	set term png size 600,480
	set size 0.5, 0.5
	plot sin(x)

	set term png size 300,240
	set size 1,1
	plot sin(x)

Both of these will produce a graph that occupies roughly 300x240
pixels, but the first one will be surrounded by a lot of empty space
in a large window.  The second one will be in a smaller window which
it mostly fills.

In the second plot of your example you told the postscript driver
that it could only write to half of the total paper ("set size 1,0.5"),
and so that's what it did.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Multiplot fails in postscript mode

[Lutz M. <ma...@uc...>]

On Friday 04 June 2004 14:18, Ethan Merritt wrote:
> On the other hand, I think it would be reasonable for
> set/unset multiplot to save and restore the plot size.
> Logically it should then also save and restore the
> origin.
>
> Is that what you expected to happen?

I'm not sure I understand your question. The way I use gnuplot, I would have 
expected the following (I will use the word "canvas" for the output medium, 
it could be an X window, or a sheet of paper. I think this is equivalent to 
the "screen" coordinate system in gnuplot):

"set multiplot": tells the plot command that the canvas shouldn't be cleared 
before the plot.

"set size xscale, yscale": tells the plot command that the whole plot should 
be scaled in x- and y-direction. "set size 1,1" means using the whole canvas.

"set origin x,y": tells the plot command to shift the plot by (x,y), where 
(0,0) is the bottom left and (1,1) is the top right corner of the canvas.

If I wanted to change the canvas size (for example, the resolution of a bitmap 
plot, or the paper size), I would expect this to be done using "set terminal 
<whatever> <canvas size>".

  Lutz

Re: Multiplot fails in postscript mode

[Ethan M. <merritt@u.washington.edu>]

On Friday 04 June 2004 12:59 pm, Ethan Merritt wrote:
> >The resulting postscript
> > file contains only one plot. Is this the expected behavior?
>
> Yes, I believe it is the expected behaviour.

On the other hand, I think it would be reasonable for
set/unset multiplot to save and restore the plot size.
Logically it should then also save and restore the
origin.

Is that what you expected to happen? 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195