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

Re: Again: canvas size

[Harald H. <h.h...@tu...>]

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> >
> > Until now, the screen coordinates are the only measure (except character,
> > see above) that can remain constant independent on the graph, canvas or
> > whatever size. If the screen coordinate system is changed to be hardcoded
> > to range 0:1 the only absolute coordinate system gets lost.
>
> Then let let us fix that problem directly, instead of mis-using the
> screen size simply to allow specification of arrows in absolute coordinates.
>
> Introduce a new coordinate system "absolute", or maybe even the specific
> units  "in", "cm", "pt", "pixel".

I totally agree with this approach. The specific units have too problems:
How shall pixel defined in vector terminals, and how shall in, ch, pt be
defined in terminals without a absolute canvas size? For png and jpeg, a
resolution in dpi could be given and thus in, ch, and pt also used. But
what about x11 and windows? Do they have access to the system-wide
resolution settings?

> > Where is the advantage of generating two plots with the same size by
> > giving different measures:
> >
> > set terminal png size 640,480
> > set multiplot
> > set size 1,1
> > ...
> >
> > and
> >
> > set terminal png size 640,600
> > set multiplot
> > set size 1,480./600
> >
> > I do not understand this.
>
> If those two command sequences produce the same result, it is a bug.
> But they don't.
>
> The first one produces a 640x480 image that is entirely filled
> by the plot.
>
> The second one produces a 640x600 image that contains a plot
> in the lower 480 pixels, but is blank above that.

Which is the same plot on different canvas (what is the plural of
canvas?). Our do you tell twice the same drawing to be different only
because they are placed in different frames?

> Presumably that
> blank area will be occupied by the next plot in the multiplot
> sequence.  Is that not the entire purpose of multiplot?

Yes, the multiplot command is ment for this. I often use one big plot in
the upper part (which is meant to have the same size as my normal, single
plots) and a smaller plot under it. Here, the automatic placement of
gnuplot cannot work. But let's stop discussing about this because the
abolute measurements are okay for both of us. What do the others say to
that suggestion?

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Again: canvas size

[Harald H. <h.h...@tu...>]

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> >
> > I of course would also agree with a new coordinate system that may really
> > use absolute coordinates as millimeters. But this seems not to be possible
> > because many terminals do not have this measure.
>
> But also many terminals (essentially ALL of them :-) do not consistently
> support sizes greater than 1.

Let me extend your list.

> gnuplot> set size 2,2
> gnuplot> set term <TERMINAL>
> gnuplot> set output <foo.TERMINAL>
> gnuplot> plot sin(x)
>
> Results
> ---------
>
> post.trm	full plot is drawn - bounding box goes negative

post.trm (eps mode)   works correctly

> gd.trm		full plot is drawn - size is twice that requested

Here, the labels are missing outside 1,1 (without my patch). The double
size is unexpected by consistent with other terminals as postscript. But I
also see this as a bug.

> fig.trm		full plot is drawn - size is twice that expected
>
> mif.trm		full plot is drawn but bounding box describes only
> 		lower left corner. Arguably this is the only terminal
> 		to get it right!
>
> dumb.trm	segfault after next command
>
> pdf.trm		lower left quarter of plot is drawn
>
> x11.trm		lower left quarter of plot is drawn
>
> epslatex	left 2/3 of plot is drawn  (bizarre!)

Here, the whole plot is there, but all text outside 1,1 is ignored. Using
my small patch (available on the www page), the epslatex plot gets
correct.

> cgm.trm		gnuplot: ../term/cgm.trm:1282: CGM_write_int:
> 		Assertion `value <= 32767' failed.
> 		Abort
>
> emf.trm		gnuplot: ../term/emf.trm:860: EMF_move:
> 		Assertion `x < term->xmax && y < term->ymax' failed.
> 		Abort


-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Again: canvas size

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

On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> 
> I of course would also agree with a new coordinate system that may really
> use absolute coordinates as millimeters. But this seems not to be possible
> because many terminals do not have this measure.

But also many terminals (essentially ALL of them :-) do not consistently
support sizes greater than 1.

Here is a quick survey of terminals I can easily test.

Arguably, the only terminal to get it right is mif.trm.

If I am being generous, I can point out that I patched the abort/failure
in cgm.trm last week.

If I am being even more generous, then I can accept that fig.trm also does
something reasonable although it's not what I expected it to do.

All other terminals that I tested have problems of varying severity.

Test sequence of commands
---------------------------

gnuplot> set size 2,2
gnuplot> set term <TERMINAL>
gnuplot> set output <foo.TERMINAL>
gnuplot> plot sin(x)

Results
---------

post.trm	full plot is drawn - bounding box goes negative
gd.trm		full plot is drawn - size is twice that requested
fig.trm		full plot is drawn - size is twice that expected

mif.trm		full plot is drawn but bounding box describes only
		lower left corner. Arguably this is the only terminal
		to get it right!

dumb.trm	segfault after next command

pdf.trm		lower left quarter of plot is drawn

x11.trm		lower left quarter of plot is drawn

epslatex	left 2/3 of plot is drawn  (bizarre!)

cgm.trm		gnuplot: ../term/cgm.trm:1282: CGM_write_int: 
		Assertion `value <= 32767' failed.
		Abort

emf.trm		gnuplot: ../term/emf.trm:860: EMF_move: 
		Assertion `x < term->xmax && y < term->ymax' failed.
		Abort


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

Re: Again: canvas size

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

On Wednesday 12 October 2005 02:39 pm, Harald Harders wrote:
> 
> Until now, the screen coordinates are the only measure (except character,
> see above) that can remain constant independent on the graph, canvas or
> whatever size. If the screen coordinate system is changed to be hardcoded
> to range 0:1 the only absolute coordinate system gets lost.

Then let let us fix that problem directly, instead of mis-using the
screen size simply to allow specification of arrows in absolute coordinates.

Introduce a new coordinate system "absolute", or maybe even the specific
units  "in", "cm", "pt", "pixel".

That would work far better than misusing the screen coords, because the
screen coords are not guaranteed to have an aspect ratio of 1.  Indeed
usually they do not, which I have noticed is a problem for generating
arrowheads that look the same independent of the direction the arrow is
pointing.


> Where is the advantage of generating two plots with the same size by
> giving different measures:
> 
> set terminal png size 640,480
> set multiplot
> set size 1,1
> ...
> 
> and
> 
> set terminal png size 640,600
> set multiplot
> set size 1,480./600
> 
> I do not understand this.

If those two command sequences produce the same result, it is a bug.
But they don't.

The first one produces a 640x480 image that is entirely filled
by the plot.

The second one produces a 640x600 image that contains a plot
in the lower 480 pixels, but is blank above that.  Presumably that
blank area will be occupied by the next plot in the multiplot
sequence.  Is that not the entire purpose of multiplot?


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

Re: gnuplot+octave+cygwin-X11

[Shai A. <sh...@gm...>]

Maybe while doing these changes, the much talked about "split" of the
plotting code from octave could also be implemented? I have no idea
how, but it seems that the gnuplot interface will undergo not so minor
changes so it's a good time to at least do it in way which will be
consistent with the future plan to split the gnuplot code.

Shai

On 10/11/05, John W. Eaton <jw...@be...> wrote:
> On 11-Oct-2005, John W. Eaton wrote:
>
> | On 10-Oct-2005, Paul Kienzle wrote:
> |
> | | Any idea how difficult it would be to extend octave/gnuplot to suppor=
t
> | | multiple figures natively?
> |
> | The fix for Octave, independent of any changes to gnuplot, would be to
> | open a separate connection to gnuplot for each figure (i.e., one
> | gnuplot process per figure).  In the current sources, you'd need to do
> | this in the src/DLD-FUNCTIONS/gplot.l file.  Instead of
> |
> |   // Pipe to gnuplot.
> |   static oprocstream *plot_stream =3D 0;
> |
> | we might want
> |
> |   // Pipe to gnuplot.
> |   static oprocstream *current_plot_stream =3D 0;
> |
> |   std::map<int,oprocstream *> plot_stream_map;
> |
> | to map figure numbers to plot stream objects.
> |
> | The current figure.m should maybe become a built-in function that
> | handles opening plot streams and manages the plot_stream_map and the
> | variable __current_figure__.  Currently this variable is only defined
> | as a global in the scripting language, but that should probably become
> | a variable in gplot.l that is exported to the scripting language.
>
> I looked at this a bit more and I think the variables
>
>  // The number of lines we've plotted so far.
>  static int plot_line_count =3D 0;
>
>  // Is this a parametric plot?  Makes a difference for 3D plotting.
>  static bool parametric_plot =3D false;
>
>  // The gnuplot terminal type.
>  static std::string gnuplot_terminal_type;
>
> will also need to be per-process variables, and the functions that
> handle opening and closing the plot stream will need to be changed.
> Probably all the per-process data should go in a separate class.
> You'll want to be able to look up a process given a figure number or a
> PID (for the plot_stream_event_handler).  The oprocstream object contains
> the PID, so you shouldn't need to duplicate that, but you will need to
> be able to go from PID to oprocstream object.  Etc.  There are quite a
> few details.  I think the current code could use some cleaning up.
>
> jwe
>
>

Re: Again: canvas size

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

On Tuesday 11 October 2005 11:16 pm, Ga=EBl Varoquaux wrote:
>     By the way, the fonts are tiny and unreadable in my browser (Firefox)
> for the demo webpages. I am the only one this happens to ?

The web pages as a whole should appear in normal fonts.

The embedded text of the demo scripts is written with style spec
 LISTING, PRE=20
        {
        margin-left: 2%   ;
        line-height: 1.00 ;
        font-size: 0.5em ;
        }

This should result in half-size monospaced text. The intent is=20
that the script is less likely to overlap with the plot itself.

The size it appears in your browser will depend on what you have
set as a default size for the monospace font, and the minimum
fontsize overall. =20

=46or me it comes out small but very legible in firefox.
But I see that it is hitting the minimum fontsize limit (9)
rather than the default/2 (12/2=3D6), so I will increase that spec
on the web site to fontsize to 75% of default instead.
See if that is better for you.


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

Re: Again: canvas size

[Harald H. <h.h...@tu...>]

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 06:34 am, Harald Harders wrote:
> > set xscreenrange [0:1]
> > set yscreenrange [0:2]
> >
> > Have a look at http://www.harald-harders.de/gnuplot/canvas/
>
> I remain unconvinced.
>
> The only reason that your plots need to have these odd screen
> ranges is that they specify per-plot arrows in terms of
> screen coordinates rather than graph coordinates.
>
> If you don't want the arrow to scale with the screen size,
> then why are you specifying them in screen coordinates?

Because I also do not want them to scale with the graph size. I do want to
have arrows that have the same length in absolute coordinates, say mm or
inches. I use larger canvas sizes mainly for multiplots where two plots
are above each other, often with different heights. And all these plots,
single plots and multiplots have the same arrow lengths. Of course I could
use 'character' as absolute measure which does not scale with the canvas
size, but there is no fixed relation between x and y length.

Until now, the screen coordinates are the only measure (except character,
see above) that can remain constant independent on the graph, canvas or
whatever size. If the screen coordinate system is changed to be hardcoded
to range 0:1 the only absolute coordinate system gets lost.

And I also do not see why there shall not be a coordinate system that
allows two plots to have identical sizes independently on the canvas size.

Where is the advantage of generating two plots with the same size by
giving different measures:

set terminal png size 640,480
set multiplot
set size 1,1
...

and

set terminal png size 640,600
set multiplot
set size 1,480./600

I do not understand this.

I do not understand your reluctance against a coordinate system with an
absolute manner. In particular because I also agree that the default
should be that the screen coordinate system scale with the canvas.
Maybe, we have a different view of the canvas size. For you it appears to
be a scaling factor for the plots (but for that, I really can rescale my
output in standard size). For me, the canvas size is the size of an area
where I can put everything. If you use A3 paper instead of A4 paper, you
still have the possibility of plotting a square of 10 x 10 mm. You do not
have to say: "I plot a square of 10/sqrt(2) * 10/sqrt(2) A3-mm".

I of course would also agree with a new coordinate system that may really
use absolute coordinates as millimeters. But this seems not to be possible
because many terminals do not have this measure.

So, why not a coordinate system that's unit is constant, x mm for
Postscript, y Pixel for screen or pixel terminals independent on canvas
size?  And because pixel are not defined in postscript and inches,
millimeter, and pt are not defined for screen terminals (while they were
defined for pixel-based terminals if the resolution could be given), a
pragmatic default scaling has to be defined. And why not using range 0 to
1 for the default canvas size?

Maybe, a measure millimeter should be introduced that used a resolution
for pixel-based terminals and either the resolution of the window manager
or a fall-back of 75 or 72 dpi for screen terminals.

I am strict against to dispose a coordinate system that stays constant
when resizing the canvas.

I assume that you still are not convinced but I nevertheless hope so.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Again: canvas size

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

On Wednesday 12 October 2005 06:34 am, Harald Harders wrote:
> set xscreenrange [0:1]
> set yscreenrange [0:2]
> 
> Have a look at http://www.harald-harders.de/gnuplot/canvas/

I remain unconvinced.

The only reason that your plots need to have these odd screen
ranges is that they specify per-plot arrows in terms of
screen coordinates rather than graph coordinates.

If you don't want the arrow to scale with the screen size,
then why are you specifying them in screen coordinates?

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

Re: PBM documentation patch

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

On Tuesday 11 October 2005 11:16 am, Don Taber wrote:
> I also noted that the information
> about PBMPLUS is way out of date.  A patch to fix this is appended.

Applied. Thanks.

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

Re: Again: canvas size

[Harald H. <h.h...@tu...>]

On Tue, 11 Oct 2005, Ethan Merritt wrote:

> On Monday 10 October 2005 02:37 pm, Harald Harders wrote:
> > At the moment, there are two different possibilities to change
> > the canvas size (partly depending on the terminal):
> >
> > - Use 'set size xcan,ycan' before using 'set terminal'.
> >   This leads to screen coordinates 0,0 in the lower left corner and
> >   xcan,ycan in the upper right corner.
>
> That does seem to be true currently.
> I really dislike this as being totally counter-intuitive.
> See for example, today's bug report #1324011
>
> > - Use 'set terminal <term> size xterm,yterm'.
> >   This leads to screen coordinates 0,0 in the lower left corner and
> >   1,1 in the upper right corner.
>
> This is not true currently.

I ment the default case without prior 'set size'.

> > Say, you want to have many plots in one document with identical size. If
> > one of these plots is a multiplot, it is useful to have a canvas with
> > maximal screen coordinates 1,2.
>
> I am totally lost here.  Can you post a web page that contains an
> example of such a document?  Won't you get exactly what you describe
> without specifying "set size" at all?  Each plot, multi- or single-
> will be of identical size.

You could compare the screen coordinate ranges with the ranges in a plot.
Would you understand if I say:

set xscreenrange [0:1]
set yscreenrange [0:2]

This would mean, the lower left corner of the canvas has the screen
coordinates 0,0 and the upper right has 1,2.

Have a look at http://www.harald-harders.de/gnuplot/canvas/

> > I propose following structure:
> >
> > - The canvas size is defined exclusively by the 'set terminal' commands,
> >   e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.
>
> I agree with this part.
>
> > And for a multiplot, you can use
> >
> > set screen-coordinate max 1,2
> > set terminal postscript size 5in,6in
> >
> > This would lead to identical absolute screen coordinate lengths in both
> > cases.
>
> I do not understand this at all.
> What is "screen coordinate length"?

I do not know the correct English term. If you draw an arrow from screen
0,0 to screen 1,1 in a plot with

set screen-coordinate max 1,1
set terminal postscript size 4in,3in

and the same arrow (0,0 to 1,1) in a plot with

set screen-coordinate max 1,2
set terminal postscript size 4in,6in

this would lead to two identical arrows while in

set screen-coordinate max 1,1
set terminal postscript size 4in,6in

the arrow would point to a position at double height of the first two
cases.


> Consider the two following command sequences:
>
> A)
> set term png size 200,200
> set output 'A.png'
> set screen-coord max 1,1
> set multiplot layout 2,1
> plot <foo>
> plot <baz>
>
> B)
> set term png size 200,200
> set output 'B.png'
> set screen-coord max 1,2
> set multiplot layout 2,1
> plot <foo>
> plot <baz>
>
> Both png images are 200x200 pixels, right?
> Will B.png contain both plots, or will it only contain one of them?
> If it contains both, in what way does it differ from A.png?

I am not talking about the automatically scaled plots but of plots that
have a defined size given by the user. See the www page for that.
Of course, automatically placed and scaled plots shall not be influenced
by the 'set screen-coord' command.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Again: canvas size

[Robert H. <en...@no...>]

On Wed, 2005-10-12 at 13:52 +0200, Hans-Bernhard Broeker wrote:
> Robert Hart wrote:
> > I assume the meaning is: A document contains a number of plots most of
> > which is plotted at a "default size". For some reason the author happens
> > to want to include a multiplot at such a size that each sub plot is the
> > same size as all the rest.
> 
> Using multiplot is certainly not the best possible way of achieving that 
> goal.
> 
> > To be honest, the more I think about it, the less sure I am that multiplot
> > is/was a good idea. 
> 
> It was a good idea alright --- it's just not a panacea.  But then, what 
> ever is?  It works well enough for its main purpose (multiple plots with 
> locked axes, inset plots, ...), and it's much easier to implement inside 
> gnuplot than outside.

Sorry I didn't intend to sound critical. I'm aware that there are
certain things that are *best* achieved by using multiplot such as the
inset plot, or two abutting plots (as in the finance demo), but the
impression I go when reading the documentation was that the primary (and
simplest) use is to just group together a series of plots on a page.

It also seems like a bit of a kludge to use because it doesn't work well
with the generally interactive nature of gnuplot. 

-- 
Robert Hart <en...@no...>
University of Nottingham


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.

Re: A question about Gnuplot

[Robert H. <en...@no...>]

On Wed, 2005-10-12 at 10:47 +0800, LUO Yingqin wrote:

> I am trying to display cell-cycle for different genes using Gnuplot.
> Then the graphs will be displayed on the web page by PERL script. It
> is pretty for each single gene.  J

> The problem is the number of genes what I select each time is
> uncertain and I hope all the cell-cycle curves are just in one plot.
> In other words, the number of curves is dynamic for each time. For
> this action, how can I do using Gnuplot? Does a loop command for
> Gnuplot to execute uncertain number data file?

Not 100% sure what you mean, but I would use perl to generate the
gnuplot commands to match the data file. i.e. you open the data file in
perl, decided how many plot series you need, then open a pipe to
gnuplot, and send it whatever commands are needed to draw the plot.

Rob



-- 
Robert Hart <en...@no...>
University of Nottingham


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.

Re: Again: canvas size

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

Robert Hart wrote:
> I assume the meaning is: A document contains a number of plots most of
> which is plotted at a "default size". For some reason the author happens
> to want to include a multiplot at such a size that each sub plot is the
> same size as all the rest.

Using multiplot is certainly not the best possible way of achieving that 
goal.

> To be honest, the more I think about it, the less sure I am that multiplot
> is/was a good idea. 

It was a good idea alright --- it's just not a panacea.  But then, what 
ever is?  It works well enough for its main purpose (multiple plots with 
locked axes, inset plots, ...), and it's much easier to implement inside 
gnuplot than outside.

Re: [ gnuplot-Patches-1323515 ] Sort points in 3D before plotting

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

Petr Mikulik wrote:
> The trouble of hidden3d is that it is a global filter, not an option for 
> the plot style. 

That's not a trouble, that's a necessity.  It makes absolutely no sense 
whatsoever to draw one dataset hidden-lined, but another one directly. 
This distinguishes hidden3d from essentially all other current or former 
global splot filters (dgrid3d, contouring, pm3d).

Hidden-lining is, by definition, a property of the plot at large, not of 
the individual dataset.

Re: Again: canvas size

[V. <gae...@no...>]

On Tue, Oct 11, 2005 at 05:19:54PM -0700, Ethan Merritt wrote:
>     http://gnuplot.sourceforge.net/demo_4.1/finance.html

    By the way, the fonts are tiny and unreadable in my browser (Firefox)
for the demo webpages. I am the only one this happens to ?

--
    Ga=EBl

A question about Gnuplot

[LUO Y. <lu...@gi...>]

Hi Gnuplot,=20

=20

I am trying to display cell-cycle for different genes using Gnuplot.
Then the graphs will be displayed on the web page by PERL script. It is
pretty for each single gene.  :-)

=20

The problem is the number of genes what I select each time is uncertain
and I hope all the cell-cycle curves are just in one plot. In other
words, the number of curves is dynamic for each time. For this action,
how can I do using Gnuplot? Does a loop command for Gnuplot to execute
uncertain number data file?

=20

Thanks a lot.

=20

Best regards,

Yingqin

Genome Institute of Singapore

     =20

Re: Again: canvas size

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

On Tuesday 11 October 2005 04:34 pm, Robert Hart wrote:
> 
> To be honest, the more I think about it, the less sure I am that multiplot
> is/was a good idea. Surely just as gnuplot isn't a data-processing
> application, it also isn't a page layout program either. Are there any
> uses for multiplot that couldn't be just as easily acheived by montaging
> the plots together in an Image Editor, DTP, LaTeX, or whatever?

Yes, but they are not exactly the ones that multiplot was originally 
designed to produce.

So far as I can see, the thing it is most useful for is to produce
stacked plots. See, for example, the "finance" demo provided by
John Bollinger	
    http://gnuplot.sourceforge.net/demo_4.1/finance.html

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

Re: Again: canvas size

[Robert H. <en...@no...>]

On Tue, 11 Oct 2005, Ethan Merritt wrote:

> > Say, you want to have many plots in one document with identical size. If
> > one of these plots is a multiplot, it is useful to have a canvas with
> > maximal screen coordinates 1,2.
> 
> I am totally lost here.  Can you post a web page that contains an 
> example of such a document?  Won't you get exactly what you describe
> without specifying "set size" at all?  Each plot, multi- or single-
> will be of identical size.

I assume the meaning is: A document contains a number of plots most of
which is plotted at a "default size". For some reason the author happens
to want to include a multiplot at such a size that each sub plot is the
same size as all the rest.

To be honest, the more I think about it, the less sure I am that multiplot
is/was a good idea. Surely just as gnuplot isn't a data-processing
application, it also isn't a page layout program either. Are there any
uses for multiplot that couldn't be just as easily acheived by montaging
the plots together in an Image Editor, DTP, LaTeX, or whatever?

Rob



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.

gnuplot+octave+cygwin-X11

[John W. E. <jw...@be...>]

On 11-Oct-2005, John W. Eaton wrote:

| On 10-Oct-2005, Paul Kienzle wrote:
| 
| | Any idea how difficult it would be to extend octave/gnuplot to support 
| | multiple figures natively?
| 
| The fix for Octave, independent of any changes to gnuplot, would be to
| open a separate connection to gnuplot for each figure (i.e., one
| gnuplot process per figure).  In the current sources, you'd need to do
| this in the src/DLD-FUNCTIONS/gplot.l file.  Instead of
| 
|   // Pipe to gnuplot.
|   static oprocstream *plot_stream = 0;
| 
| we might want
| 
|   // Pipe to gnuplot.
|   static oprocstream *current_plot_stream = 0;
| 
|   std::map<int,oprocstream *> plot_stream_map;
| 
| to map figure numbers to plot stream objects.
| 
| The current figure.m should maybe become a built-in function that
| handles opening plot streams and manages the plot_stream_map and the
| variable __current_figure__.  Currently this variable is only defined
| as a global in the scripting language, but that should probably become
| a variable in gplot.l that is exported to the scripting language.

I looked at this a bit more and I think the variables

  // The number of lines we've plotted so far.
  static int plot_line_count = 0;

  // Is this a parametric plot?  Makes a difference for 3D plotting.
  static bool parametric_plot = false;

  // The gnuplot terminal type.
  static std::string gnuplot_terminal_type;

will also need to be per-process variables, and the functions that
handle opening and closing the plot stream will need to be changed.
Probably all the per-process data should go in a separate class.
You'll want to be able to look up a process given a figure number or a
PID (for the plot_stream_event_handler).  The oprocstream object contains
the PID, so you shouldn't need to duplicate that, but you will need to
be able to go from PID to oprocstream object.  Etc.  There are quite a
few details.  I think the current code could use some cleaning up.

jwe

Re: [ gnuplot-Patches-1323515 ] Sort points in 3D before plotting

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

On Tuesday 11 October 2005 12:05 pm, Petr Mikulik wrote:
> >> The series of points can be  a time sequence, and there it
> >> would be useful to draw them (into a map) as they appear in
> >> the data file, without ordering.
> >
> > I do not understand this example. Could you explain what the
> > x, y, and z coordinates would be in this case?
> 
> The data will be drawn as a color map (set view map).
> x, y - coordinate
> z - colour
> 
> Example: data file contains several scans (through angles, for example) of 
> scattered intensity, the sample has been measured several times, and I want 
> to see the latest values -- thus the previous have to be hidden below the 
> latest data.

OK. I understand.
 
> (Or, one would have to be think that the z-coordinate is $0, not $3).

Yes, that would work:
  set view map
  plot "series" using 1:2:0:3 with linespoints palette

The sort is on $0, but the color is taken from column 3.
That works fine for "set view map", although I admit that it is a change
from previous behavior.

But it doesn't work to retrace curves in the general 3D case
(not "set view map").  So yes, I see that there must be some way to
toggle the sort on and off.

> The trouble of hidden3d is that it is a global filter, not an option for the 
> plot style. 

The property of being global is exactly what you need in order 
to do Z-ordering for multiplot datasets within the same plot.
Otherwise the later plots will always occlude the earlier ones.

 
> > I am not clear on how this would fit in with Johannes Zellner's
> > patch #1077726 "true depth ordering for pm3d plots".
> 
> Yes. It is reordering the facets (quadrangles) same way as you do here for 
> points. Both are useful for a nice visualization of surfaces.

But you could not mix them in the same graph unless they were both
moved into the global hidden3d code, right?


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

Re: Re: color loop for gd.trm

[<ds...@ch...>]

> 
> From: Petr Mikulik <mi...@ph...>
> Date: 2005/10/11 Tue PM 02:51:33 EDT
> To: Ethan Merritt <merritt@u.washington.edu>
> CC: Shigeharu TAKENO <sh...@ie...>, 
>         gnu...@li...
> Subject: Re: color loop for gd.trm
> 
> >>   set term png xffffff x000000 x404040 \
> >>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
> >>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
> >
> > I see.  That is different from what I understood at first.
> >
> > So your goal is not to reduce the total number of colors, instead
> > it is to have the same default colors on all terminals?
> 
> What about
> 
> set style linetype colorsequence red,green,blue,"FFEE00", ...
> 
> which would redefine the color sequence for the linetype series, and then it 
> would become the same for all terminals?

Not a bad idea.  So the color would wrap when reaching the end of the sequence.  ("colorsequence" is quite long and not easily abreviated because of conflicts.)  A bit of extra work perhaps.  How would one guarantee that all terminals have the described colors?  And what would one do if that were not the case?  Complain when doing a "set term"?  It would seem that the non-defined colors gets us back to the same issue of color definitions for 1, 2, 3...

Dan

Re: gnuplot+octave+cygwin-X11

[Petr M. <mi...@ph...>]

> The fix for Octave, independent of any changes to gnuplot, would be to
> open a separate connection to gnuplot for each figure (i.e., one
> gnuplot process per figure).

I would enjoy this change! Gnuplot interactive mousing (e.g. zooming by 
mouse) is limited to the current window only (for which "replot" works).

For example, you need to popen() several gnuplots to work simultaneously on 
a map and its line cross-section. That way you bypass the octave built-in 
gnuplot plotting completely and define all commands through "in userspace".

The proposed built-in solution with
>    static oprocstream *plot_stream = 0;
>    std::map<int,oprocstream *> plot_stream_map;
>    static oprocstream *current_plot_stream = 0;
would be much more elegant and consistent.

---
PM

gnuplot+octave+cygwin-X11

[John W. E. <jw...@be...>]

On 10-Oct-2005, Paul Kienzle wrote:

| Any idea how difficult it would be to extend octave/gnuplot to support 
| multiple figures natively?

The fix for Octave, independent of any changes to gnuplot, would be to
open a separate connection to gnuplot for each figure (i.e., one
gnuplot process per figure).  In the current sources, you'd need to do
this in the src/DLD-FUNCTIONS/gplot.l file.  Instead of

  // Pipe to gnuplot.
  static oprocstream *plot_stream = 0;

we might want

  // Pipe to gnuplot.
  static oprocstream *current_plot_stream = 0;

  std::map<int,oprocstream *> plot_stream_map;

to map figure numbers to plot stream objects.

The current figure.m should maybe become a built-in function that
handles opening plot streams and manages the plot_stream_map and the
variable __current_figure__.  Currently this variable is only defined
as a global in the scripting language, but that should probably become
a variable in gplot.l that is exported to the scripting language.

jwe

Re: color loop for gd.trm

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

On Tuesday 11 October 2005 11:51 am, Petr Mikulik wrote:
> 
> What about
> 
> set style linetype colorsequence red,green,blue,"FFEE00", ...

I would prefer to go for the fully general case of
defining a sequence of line styles.  

That way you could also give a preferred  sequence of line widths,
dot/dash patterns, point types, and so on.

I have not given a lot of thought to what the best command syntax
would be.  Not all the line styles would be wanted for the default
sequence, for example.  Maybe

   set style line sequence  1,2,6,5

meaning: cycle through four default line styles (styles 1,2,6 and 5)
when generating plots.  As is currently the case for linetypes, it
wraps around so that in this example the fifth plot again uses
line style 1.


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

Re: [ gnuplot-Patches-1323515 ] Sort points in 3D before plotting

[Petr M. <mi...@ph...>]

>> The series of points can be  a time sequence, and there it
>> would be useful to draw them (into a map) as they appear in
>> the data file, without ordering.
>
> I do not understand this example. Could you explain what the
> x, y, and z coordinates would be in this case?

The data will be drawn as a color map (set view map).
x, y - coordinate
z - colour
line number in the file = this gives the z-order, which point is drawn the 
last

Example: data file contains several scans (through angles, for example) of 
scattered intensity, the sample has been measured several times, and I want 
to see the latest values -- thus the previous have to be hidden below the 
latest data.

I use this "overlapping" when measuring scattered intensity in regions of 
reciprocal space of a sample with and without absorber, and overlapping that 
part which has better statistics. If gnuplot sorts the data, that would 
destroy the image.

(Or, one would have to be think that the z-coordinate is $0, not $3).

> the longer term plan should be to extend the category of
> plots handled by "set hidden3d".  In particular the hidden3d code
> could sort points and line segments even if there is no surface

The trouble of hidden3d is that it is a global filter, not an option for the 
plot style. Having the sort as an option, it would be more convenient.

> I am not clear on how this would fit in with Johannes Zellner's
> patch #1077726 "true depth ordering for pm3d plots".
> Have you looked at that patchset?

Yes. It is reordering the facets (quadrangles) same way as you do here for 
points. Both are useful for a nice visualization of surfaces. For "maps", it 
would bring processing artefacts to overlapping regions.

---
PM