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

Re: Separating line color and dot/dash pattern

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

Ethan Merritt wrote:

>
>Good luck. There is no guarantee that any particular terminal device
>is capable of a particular dash style.  We haven't even reached a 
>point where all terminals agree on colors! (Nor do I necessarily
>think they should - what looks good on the screen may not look good
>on paper).
>  
>

Speaking of which, I've been using octave's color scheme for gnuplot.  
Some of the colors in X11 are too bright to contrast against a gray or 
white background.  In particular, green and cyan are difficult to see.  
Whereas in the PDF terminal the colors come out a much darker green and 
cyan.  (Cyan is still a bit bright in PDF, but OK.)  I'd say it isn't so 
much the terminal that is the issue as it is the ultimate plotting 
background color.

Dan

Re: Separating line color and dot/dash pattern

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

On Saturday 05 February 2005 12:25 pm, Harald Harders wrote:
> On Sat, 5 Feb 2005, Ethan Merritt wrote:
>
> > - The obvious extension is to add a keyword "{dt|dashtype} <n>".
> >   In the context of setting a line style, the command would be
> >     set style line <tag> dt <N> lt rgb "#aabbcc"

> I think the keyword 'colour' is more clear because it tells what it
> changes. And at the moment, linetype changes both color and dashtype in
> many cases which should be preserved for compatibility.
> Set dashtype to <N> and color to RGB value of aa, bb, cc:
>   set style line <tag> dashtype <N> color rgb "#aabbcc"

But is it really more clear?  Remember that currently the
"line style" also includes the point type and point size.
Is "colour" to apply to both the line and the points, or is
it specifically the line colour?

And I think there are compatibility issues. Consider the command
	plot "foo" with linespoints dashtype <n> color rgb "red"

What exactly do you expect to happen to the points?
And what should happen on a terminal that cannot set rgb colors?

> Escpecially for postscript there is a difference between cmyk and rgb
> (and hsb) colours depending on the output device.

So?  That's a totally orthogonal issue. Anything that depends on the
eventual PostScript output device is clearly out of gnuplot's control.
If you are concerned to have an hsv option, this could either be created
as a parallel option to rgb, or else we could define a user-accessible
string-valued function  hsv2rgb(H,S,V)  that returns "#RRGGBB". E.g.
	set style line 1 lt rgb hsv2rgb(H,S,V)
Hmmm. Actually, I think you could do that anyhow right now just by
loading a script that defined such a funciton. 

> > - A surprising number of terminal types already support dashed lines:
> >   But I suspect that other than the ones piggybacking on post.trm
> >   they all disagree about specific dot/dash patterns.
>
> Yes, I think, all terminals should be harmonized.

Good luck. There is no guarantee that any particular terminal device
is capable of a particular dash style.  We haven't even reached a 
point where all terminals agree on colors! (Nor do I necessarily
think they should - what looks good on the screen may not look good
on paper).


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: Separating line color and dot/dash pattern

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

On Sat, 5 Feb 2005, Ethan Merritt wrote:

> On Saturday 05 February 2005 09:09 am, Ethan Merritt wrote:
> > Unfortunately you cannot currently set a line style to have a
> > different dot/dash pattern than it has by default, but for a totally
> > unintended feature that's not such a severe limitation.
>
> Assuming that we would like to clean this up and document it properly,
> there are a few things that should be decided.
>
> - The current (unintended) mechanism only works with line styles,
>   not with in-line specifications like "plot <foo> lt <bar>".
>   Is that sufficient?

I think not. Maybe it would be worth to seperate choosing the dashtype and
the color (for example using 'dashtype' as suggested by you and 'color').
Linetype could then be preserved as it is for compatibility reasons.

> - The obvious extension is to add a keyword "{dt|dashtype} <n>".
>   In the context of setting a line style, the command would be
>     set style line <tag> dt <N> lt rgb "#aabbcc"
>   This would be exactly equivalent to the current behaviour of
>     set style line <N> lt rgb "#aabbcc"
>   except that you could have (<tag> != <N>)

I think this is the best approach. But I would prefer to use the keyword
'colour' or 'color' for the colour. E.g.:

Set dashtype to <N> and color to RGB value of aa, bb, cc:
  set style line <tag> dashtype <N> color rgb "#aabbcc"
Set dashtype to <N> and color to the <M>th color in automatic color order:
  set style line <tag> dashtype <N> color <M>
Set dashtype to <N> and color to named color:
  set style line <tag> dashtype <N> color named "name"
Set dashtype to <N> and color to CMYK value of aa, bb, cc, dd:
  set style line <tag> dashtype <N> color cmyk "#aabbccdd"
Set dashtype to <N> and color to the <N>th color in automatic color order:
  set style line <tag> dashtype <N> color <M>
  set style line <tag> linetype <N>

I think the keyword 'colour' is more clear because it tells what it
changes. And at the moment, linetype changes both color and dashtype in
many cases which should be preserved for compatibility.
Escpecially for postscript there is a difference between cmyk and rgb (and
hsb) colours depending on the output device. Of course, for pixel
terminals the colours have to be converted into the output colour model.

> - A surprising number of terminal types already support dashed lines:
>     apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
>     hpgl iris4d metafont metapost next openstep post pslatex
>     pstricks tgif tpic unixplot win x11
>   But I suspect that other than the ones piggybacking on post.trm
>   they all disagree about specific dot/dash patterns.
>   Is this worth addressing?

Yes, I think, all terminals should be harmonized.

> - Another alternative is to create a small number of new linetypes.
>   I suppose these would internally be LT_DOTTED, LT_DASHED,
>   LT_DOTDASH, ..., and have negative index values (similar to -1
>   for the current LT_BORDER line type).

I don't really like this idea. In my opinion, the other approach is more
flexible and makes future work easier. Indeed it looks like more work for
the moment.

Regards
Harald

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

Separating line color and dot/dash pattern

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

On Saturday 05 February 2005 09:09 am, Ethan Merritt wrote:
> Unfortunately you cannot currently set a line style to have a
> different dot/dash pattern than it has by default, but for a totally
> unintended feature that's not such a severe limitation.

Assuming that we would like to clean this up and document it properly,
there are a few things that should be decided.

- The current (unintended) mechanism only works with line styles,
  not with in-line specifications like "plot <foo> lt <bar>".
  Is that sufficient?

- The obvious extension is to add a keyword "{dt|dashtype} <n>".
  In the context of setting a line style, the command would be
    set style line <tag> dt <N> lt rgb "#aabbcc"
  This would be exactly equivalent to the current behaviour of
    set style line <N> lt rgb "#aabbcc"
  except that you could have (<tag> != <N>)

- A surprising number of terminal types already support dashed lines:
    apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
    hpgl iris4d metafont metapost next openstep post pslatex
    pstricks tgif tpic unixplot win x11
  But I suspect that other than the ones piggybacking on post.trm
  they all disagree about specific dot/dash patterns.
  Is this worth addressing?

- Another alternative is to create a small number of new linetypes.
  I suppose these would internally be LT_DOTTED, LT_DASHED,
  LT_DOTDASH, ..., and have negative index values (similar to -1
  for the current LT_BORDER line type). Support for this would
  have to be gradually added to terminal drivers individually.
  This would produce a consistent set of patterns for all drivers.
  But it has a big disadvantage compared to the current accidental
  method.  The current method is so harmless that I didn't even 
  know it existed; individual terminal drivers don't know anything
  about it, it "just works" for those that support dash patterns.
  By contrast, commands using special new line types would generate
  various errors on terminals that had not yet been modified to
  accept them.
  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Gnuplot for pocket pc?

[Max V. <max...@gm...>]

Hi,
   exist some version of gnuplot for pocket pc?

Thanks!!

Max

Re: line color given by rgb value

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

On Saturday 05 February 2005 08:21 am, Harald Harders wrote:
> A view days ago, Ethan has told me that it is possible to give the line
> color by specifying the rgb value. This is a great thing but I have not
> found out how to specify the line type (i.e., dash style), too.

> Do I miss something in the
> documentation or is that not possible yet?

It turns out that it is possible, although it was an unplanned feature.
Here is what I posted to the newsgroup yesterday:

In thinking about how this would have to work, I came to the unexpected
realization that it is already possible in the current CVS version of
gnuplot.  This was not intentional; it's just a happy accident.

The key is that there is a recent feature that you can specify the color
of a line type, or line style, as an explicit RGB triple.  Certain
well-known colors can be referenced by name.  See "help colorspec".

The happy accident is that this is applied *on top of* whatever
characteristics the line already had. For most terminals that is
effectively just a replacement of one color by another.  But for
a terminal that support dot/dash/solid line types, it is another story.

So what you can do right now with the CVS code is the following:

	set term post color dash
	set style line 1 lt rgb "red"
	set style line 2 lt rgb "purple"
	set style line 3 lt rgb "#FF00AA"

and so on.  Each line style keeps its default dot/dash/solid pattern
from the default sequence, but you can assign any color you like to it.

Unfortunately you cannot currently set a line style to have a 
different dot/dash pattern than it has by default, but for a totally
unintended feature that's not such a severe limitation. 

Since the dot/dash pattern cycles every 9 style types, the following
demo give two sets of lines, one in red, the other in blue.
The red and blue sets contain matching solid and dashed types.

#
# Demonstrate forcing a fixed color onto dot/dash lines in postscript
#
set title "Forced combinations of color and dot/dash/solid\n(PostScript 
terminals only)"
#
set term post eps color dash dl 3.0
set output 'dash.eps'
#
set style line 1 lt rgb 'red' lw 2
set style line 2 lt rgb 'red'
set style line 4 lt rgb 'red'
set style line 5 lt rgb 'red' lw 3
#
set style line 10 lt rgb 'blue' lw 2
set style line 11 lt rgb 'blue'
set style line 13 lt rgb 'blue'
set style line 14 lt rgb 'blue' lw 3
#
unset colorbox
set xrange [-1.8:1.8]
set yrange [0:1.1]
set key left
#
plot sin(x) ls 1 ti "ls 1", 0.8*sin(x) ls 2 ti "ls 2", \
 0.6*sin(x) ls 4 ti "ls 4", 0.4*sin(x) ls 5 ti "ls 5", \
     cos(x) ls 10 ti "ls 10", 0.8*cos(x) ls 11 ti "ls 11", \
 0.6*cos(x) ls 13 ti "ls 13", 0.4*cos(x) ls 14 ti "ls 14"

 
> Another thing:
> Why does gnuplot switch on the color palette when using an rgb-defined
> color?

That's a bug, obviously.  The problem is that the program is currently
only tracking the use of pm3d colors as TRUE or FALSE.  It doesn't
separately track *why* they are being used. A similar problem exists
for surfaces.   "splot sin(x) with lines lt rgb 'gold'"  doesn't work,
because the flag for palette coloring causes it to color the whole
surface by Z value rather than recognizing that a single, uniform
color was requested.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

line color given by rgb value

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

A view days ago, Ethan has told me that it is possible to give the line
color by specifying the rgb value. This is a great thing but I have not
found out how to specify the line type (i.e., dash style), too.

set style line 1 lt rgb "#000000"
set style line 2 lt rgb "#00FF00"
set style line 3 lt rgb "#FF0000"

This sequence, for instance, produces a black solid line type, a green one
with long dashes and a red one with shord dashes. But how to produce too
solid line types and then a dashed one? Do I miss something in the
documentation or is that not possible yet?

Another thing:
Why does gnuplot switch on the color palette when using an rgb-defined
color? I think it should not do that, automatically. In this code,

set output 'asdf.ps'
set terminal postscript dashed color dashlen 4
set style line 1 lt rgb "#000000"
set style line 2 lt rgb "#00FF00"
set style line 3 lt rgb "#FF0000"
plot sin(x) ls 1, cos(x) ls 2, sin(x)*cos(x) ls 3
set output

for example, the color palette is useless.

Regards
Harald

PS: Thanks, Ethan, for enhancing rgb-color specification to labels!

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

Again, epslatex terminal

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

Today, I have noticed that the currently available epslatex terminal has
two bugs. Have a look at the output of this script:

set terminal epslatex color 'default' 12
set output 'epslatex-orig1.eps'
test
set output
set output 'epslatex-orig2.eps'
set style line 1 lt rgb "#DA00A0"
plot sin(x) w l ls 1
set output

"gs epslatex-orig1.eps" results in "Error: /undefined in PolyFill" while
"gs epslatex-orig2.eps" results "Error: /undefined in C". It is easy to
fix these problems but I once again propose to apply my patch to cvs.
The 'oldstyle' mode of today's version provides line styles, colors and
symbols that are very similar to the ones of the old epslatex terminal
(for those who did like the old behaviour).

There has been positive feedback by Juergen Wieferink, Theo Hopman, and
Andreas Keil.

If you still have reservations to apply this patch please let me know why.

Regards
Harald

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

Re: Win32 printing

[Russell L. <gs...@gh...>]

Hans-Bernhard,

> That would be putting it mildly.  As of the current release version, 
> 4.0, the 16-bit version no longer even compiles.

So do you want all 16-bit code removed?

> And the 32-bit version is known to have various problems.  Apparently,
> it never worked on Win9x at all.  Neither the "print this" menu entry in 
> the graph context menu, nor the 'set output 'PRN:' method.

Neither of these should have been broken in the move to 32-bit.
Note that it is "set output PRN", not "set output PRN:".

> As a matter of fact, I sometimes think it's time to rewrite the entire 
> Windows-specific part of gnuplot from scratch, given that with Win32 
> it's possible to have gnuplot behave the same way X11 gnuplot does.  In 
> particular, I would really like to get rid of the home-grown terminal 
> emulator and all the problems and limitations it causes.

Doing it on one thread may be a little tricky.
Do you want gnuplot to provide the command line editing, or do you 
want the default Windows command line editor?
If gnuplot provides it, then we might be able to do it on a single 
thread.
If you use the Windows console to provide line editing, then we might 
have to use two threads.  The first thread is the console and the 
main gnuplot code.  The second thread handles the image window.  A 
small amount of synchronisation code is required to lock the image 
window data structures as each new plot is drawn.  This is the method 
I have used in ghostscript.  The code is probably simpler than a 
single thread version.


Russell Lang                   gs...@gh...
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/

Re: Now working on POV-Ray terminal

[V. <var...@cl...>]

KITA Toshihiro <t-kita <at> cc.kumamoto-u.ac.jp> writes:
> Anyway, we would like to release the patch file as soon as possible.
> # to avoid excessive expectations. 

  Anything that works is a starting point, and therefore a great progress, I
find. It gives a basis to start building on. I am very much looking forward to
see your work.

  Could you please Cc. me for issues concerning the povray terminal, as I am not
a subscirber of the mailing list.

   Good luck with your work,

    Gaël

Re: Now working on POV-Ray terminal

[KITA T. <t-...@cc...>]

From: Ga=EBl Varoquaux <var...@cl...>
Subject: Re: Now working on POV-Ray terminal

> KITA Toshihiro <t-kita <at> cc.kumamoto-u.ac.jp> writes:
> =

> =

> > I am astonished to see the thread starting with
> =

>   Sorry, I did Google a bit on such a subject but apperntly not enoug=
h.

That is not so. That e-mail I sent is the first announcement of our =

development. You can see what we previously developed at
http://t-kita.net/webplot/
http://t-kita.net/som/
but, they are not directly related to gnuplot.

# Actually the POV-Ray terminal codes began to work only one or two
# weeks before.

> > I and one of my students, Miyata, are currently working on the
> > POV-Ray and VRML terminal of gnuplot.
> =

>    This is very good new. I was going to give it a try, but I am defi=
nitely not
>  a good coder and it would have been quite hard for me, especially si=
nce I have
> very little time to spend on this.

Honestly, we are not so good at coding either.
Our codes are simply made after trials and errors, so I am afraid =

gnuplot developers will be disappointed at our dirty codes.

>    If I can be of any help don't hesitate, but I must warn you, I am =
not an IT
> professional therefore my ability to read or write code is quite low,=
 and I have
> started using povray only two month ago. However this is a project I =
find very
> exiting, both for my own use, and for gnuplot's future and I am more =
than
> willing to help.
> =

>     Ga=EBl

I am glad you are intereted in our work.
Unlike other popular GUI-based plotting tools, gnuplot can be easily dr=
iven by
CUI-based commands and scripts. That is why I love to use gnuplot and
I want to add virtual-reality terminals to it.

Anyway, we would like to release the patch file as soon as possible.
# to avoid excessive expectations. :-)

-- =

  KITA Toshihiro
  http://t-kita.net/    PGP-Key: http://t-kita.net/pubkey.asc
  fingerprint : CBFF 6A61 5990 10F5 B4B6  D2E8 279A 7063 CF8B 6339

Re: Win32 printing

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

Russell Lang wrote:

Welcome back!  It's been quite a while since we heard from you.  It's 
good to see you still remember gnuplot after all these years.

> The file src/win/wprinter.c contains some old code for sending 
> printer specific output to a printer in DumpPrinter().  The 16-bit 
> code is probably still Ok, but probably not much used these days.

That would be putting it mildly.  As of the current release version, 
4.0, the 16-bit version no longer even compiles.

And the 32-bit version is known to have various problems.  Apparently,
it never worked on Win9x at all.  Neither the "print this" menu entry in 
the graph context menu, nor the 'set output 'PRN:' method.

> So we should be able to replace the old Win32 printing code with  
> something based on the attached code.  In a slightly different form, 
> this code has been used by GSview and Ghostscript for many years.

I suspect just about anything would work better than the current stuff.

As a matter of fact, I sometimes think it's time to rewrite the entire 
Windows-specific part of gnuplot from scratch, given that with Win32 
it's possible to have gnuplot behave the same way X11 gnuplot does.  In 
particular, I would really like to get rid of the home-grown terminal 
emulator and all the problems and limitations it causes.

Re: Outputing image fields

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

  Yes, I am very unclear, I must admit it. Petr understood quite clearly
whit I meant, it is basicaly wath the zimg program does (thank for the
tip, by the way, Petr, it is very usefull).
  I am trying to create a 1:1 mapping between data and pixel in an splot
(or a with image, I must admit I had not looked at the CVS version).

  I understand that I am probablly trying to do something that gnuplot is
not meant for, as it deals with much more then a height field. I think I
will use zimg to do that, though I must admit I really like gnuplot's way
of dealing with colormap.

  Thank for the answer,
         Ga=EBl

Re: Outputing image fields

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

Ga=EBl Varoquaux wrote:

>   Is there a way to output a pm3d plot to an bitmap image where the ima=
ge
> would be, pixel by bixel, a height field of the data.=20

I'm completely confused by that sentence.  You refer to some "image" two =

times, but I fail to see whether it's supposed to be the same image both =

times and, if not, what is the difference between the two.  If it is the =

same image, how would this differ from the new 4.1 plot style "with=20
image"?  Or even from pm3d itself, for that matter?

 > That would be
> feasily feasable with the png output driver with option "crop", if one =

> could control precisely the size of the bitmap comming out.

What is feasible with a single output driver is, ultimately, irrelevant.
For it to make a useful gnuplot feature, it really should be feasible on =

a multitude of drivers.

>   If this is not possible, is there a simple aglorithme to determine th=
e
> size of the area that gets cropped ?

I'm not sure what "cropping" step you're referring to here, either.

Re: Outputing image fields

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

>   Is there a way to output a pm3d plot to an bitmap image where the image
> would be, pixel by bixel, a height field of the data.

No, gnuplot scales the image, in both "with pm3d" and "with image":
  * you probably want to switch on "set pm3d corners2color c1", see
    demo/pm3d.dem
  * "splot ... with image" from the current development version


For exact 1:1 mapping, use the "zimg" program, zimg.sf.net.

---
PM

Re: Simultaneous Line Limit?

[Chris H. <ch...@be...>]

Aha! I figured it out!

It was because I was explicitly specifying the xrange.  That cause a conflict, 
because there were plenty of x values with missing y values!

Thanks for your help.
Chris.

On Friday 04 February 2005 03:06, Chris Horn wrote:
> On Friday 04 February 2005 02:46, Juergen Wieferink wrote:
> > > 'memory-profile.txt' using 1:46 with linespoints 18, 
'memory-profile.txt'
> > > using 1:47 with linespoints 18, 'memory-profile.txt' using 1:48 with
> > > linespoints 18, 'memory-profile.txt' using 1:49 with linespoints 18,
> > > #'memory-profile.txt' using 1:5 with linespoints 18, 
'memory-profile.txt'
> > > using 1:50 with linespoints 18, 'memory-profile.txt' using 1:51 with
> > > linespoints 18, 'memory-profile.txt' using 1:52 with linespoints 18,
> > 
> > [...]
> > 
> > Put the comment sign before the comma.
> 
> Thanks!  It was something stupid, after all!
> 
> Now, if I could only figure out why I am continuously hit with errors like 
> this:
> 
> "generated-chart-code.gp", line 72: all points y value undefined!
> 
> This is probably beyond this mailing list, but with Perl, I wrote a program 
> (because of this error) that checks for any column who's y-values consist 
> solely of only undefined values - and then I don't include those columns in 
> the GNUplot control file.  Yet GNUplot still complains.
> 
> Do I misunderstand this error?  Why does it pop up?
> 
> The Perl can be found here, for whoever's curious:
> http://www.beefstew.net/downloads/chart-unit-process.pl
> 
> I run it on the dataset linked in the previous email (although my private 
copy 
> has column headers that I've stripped out in the public version).
> 
> Thank you, again, Juergen.
> Chris Horn.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

Re: Simultaneous Line Limit?

[Chris H. <ch...@be...>]

On Friday 04 February 2005 02:46, Juergen Wieferink wrote:
> > 'memory-profile.txt' using 1:46 with linespoints 18, 'memory-profile.txt'
> > using 1:47 with linespoints 18, 'memory-profile.txt' using 1:48 with
> > linespoints 18, 'memory-profile.txt' using 1:49 with linespoints 18,
> > #'memory-profile.txt' using 1:5 with linespoints 18, 'memory-profile.txt'
> > using 1:50 with linespoints 18, 'memory-profile.txt' using 1:51 with
> > linespoints 18, 'memory-profile.txt' using 1:52 with linespoints 18,
> 
> [...]
> 
> Put the comment sign before the comma.

Thanks!  It was something stupid, after all!

Now, if I could only figure out why I am continuously hit with errors like 
this:

"generated-chart-code.gp", line 72: all points y value undefined!

This is probably beyond this mailing list, but with Perl, I wrote a program 
(because of this error) that checks for any column who's y-values consist 
solely of only undefined values - and then I don't include those columns in 
the GNUplot control file.  Yet GNUplot still complains.

Do I misunderstand this error?  Why does it pop up?

The Perl can be found here, for whoever's curious:
http://www.beefstew.net/downloads/chart-unit-process.pl

I run it on the dataset linked in the previous email (although my private copy 
has column headers that I've stripped out in the public version).

Thank you, again, Juergen.
Chris Horn.

Re: Simultaneous Line Limit?

[Juergen W. <wie...@fr...>]

On Friday 04 February 2005 08:14, Chris Horn wrote:
> I'm having a bit of trouble getting a plot to be successfully created. 
> It's a lot of data to plot, so I'm curious whether I've hit some limit in
> GNUplot, or whether I'm just doing something stupid.

[...]

> gnuplot> plot 'memory-profile.txt' using 1:10 with linespoints 18,
> 'memory-profile.txt' using 1:11 with linespoints 18, 'memory-profile.txt'
> using 1:12 with linespoints 18, 'memory-profile.txt' using 1:13 with
> linespoints 18, 'memory-profile.txt' using 1:14 with linespoints 18,

[...]

> 'memory-profile.txt' using 1:46 with linespoints 18, 'memory-profile.txt'
> using 1:47 with linespoints 18, 'memory-profile.txt' using 1:48 with
> linespoints 18, 'memory-profile.txt' using 1:49 with linespoints 18,
> #'memory-profile.txt' using 1:5 with linespoints 18, 'memory-profile.txt'
> using 1:50 with linespoints 18, 'memory-profile.txt' using 1:51 with
> linespoints 18, 'memory-profile.txt' using 1:52 with linespoints 18,

[...]

Put the comment sign before the comma.

Juergen

Simultaneous Line Limit?

[Chris H. <ch...@be...>]

I'm having a bit of trouble getting a plot to be successfully created.  It'=
s a
lot of data to plot, so I'm curious whether I've hit some limit in GNUplot,=
 or
whether I'm just doing something stupid.

I don't think it's stupid - because I've written two Perl scripts to check =
the
data I'm trying to plot and make sure that it won't irritate GNUplot.

The specific message I receive is below.  I've attached the plot instruction
file and can send along the data it's working on, too, if anyone wants.  For
now, I'll just post it here if you want to go get it on your own:

http://www.beefstew.net/downloads/memory-profile.txt.gz (256019 bytes)

The error:

gnuplot> plot 'memory-profile.txt' using 1:10 with linespoints 18, 'memory-=
profile.txt' using 1:11 with linespoints 18, 'memory-profile.txt' using 1:1=
2 with linespoints 18, 'memory-profile.txt' using 1:13 with linespoints 18,=
 'memory-profile.txt' using 1:14 with linespoints 18, 'memory-profile.txt' =
using 1:15 with linespoints 18, 'memory-profile.txt' using 1:16 with linesp=
oints 18, 'memory-profile.txt' using 1:17 with linespoints 18, 'memory-prof=
ile.txt' using 1:18 with linespoints 18, 'memory-profile.txt' using 1:2 wit=
h linespoints 18, 'memory-profile.txt' using 1:20 with linespoints 18, 'mem=
ory-profile.txt' using 1:22 with linespoints 18, 'memory-profile.txt' using=
 1:25 with linespoints 18, 'memory-profile.txt' using 1:3 with linespoints =
18, 'memory-profile.txt' using 1:30 with linespoints 18, 'memory-profile.tx=
t' using 1:32 with linespoints 18, 'memory-profile.txt' using 1:34 with lin=
espoints 18, 'memory-profile.txt' using 1:35 with linespoints 18, 'memory-p=
rofile.txt' using 1:36 with linespoints 18, 'memory-profile.txt' using 1:37=
 with linespoints 18, 'memory-profile.txt' using 1:38 with linespoints 18, =
'memory-profile.txt' using 1:39 with linespoints 18, 'memory-profile.txt' u=
sing 1:4 with linespoints 18, 'memory-profile.txt' using 1:40 with linespoi=
nts 18, 'memory-profile.txt' using 1:41 with linespoints 18, 'memory-profil=
e.txt' using 1:42 with linespoints 18, 'memory-profile.txt' using 1:43 with=
 linespoints 18, 'memory-profile.txt' using 1:44 with linespoints 18, 'memo=
ry-profile.txt' using 1:45 with linespoints 18, 'memory-profile.txt' using =
1:46 with linespoints 18, 'memory-profile.txt' using 1:47 with linespoints =
18, 'memory-profile.txt' using 1:48 with linespoints 18, 'memory-profile.tx=
t' using 1:49 with linespoints 18, #'memory-profile.txt' using 1:5 with lin=
espoints 18, 'memory-profile.txt' using 1:50 with linespoints 18, 'memory-p=
rofile.txt' using 1:51 with linespoints 18, 'memory-profile.txt' using 1:52=
 with linespoints 18, 'memory-profile.txt' using 1:53 with linespoints 18, =
'memory-profile.txt' using 1:54 with linespoints 18, 'memory-profile.txt' u=
sing 1:55 with linespoints 18, 'memory-profile.txt' using 1:56 with linespo=
ints 18, 'memory-profile.txt' using 1:57 with linespoints 18, 'memory-profi=
le.txt' using 1:58 with linespoints 18, 'memory-profile.txt' using 1:59 wit=
h linespoints 18, 'memory-profile.txt' using 1:6 with linespoints 18, 'memo=
ry-profile.txt' using 1:60 with linespoints 18, 'memory-profile.txt' using =
1:61 with linespoints 18, 'memory-profile.txt' using 1:62 with linespoints =
18, 'memory-profile.txt' using 1:63 with linespoints 18, 'memory-profile.tx=
t' using 1:64 with linespoints 18, 'memory-profile.txt' using 1:7 with line=
spoints 18, 'memory-profile.txt' using 1:8 with linespoints 18, 'memory-pro=
file.txt' using 1:9 with linespoints 18
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                                                           =
                                   ^
         "generated-chart-code.gp", line 73: function to plot expected

Many thanks in advance.
Chris Horn.

Outputing image fields

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

   Hi,

  Is there a way to output a pm3d plot to an bitmap image where the image
would be, pixel by bixel, a height field of the data. That would be
feasily feasable with the png output driver with option "crop", if one=20
could control precisely the size of the bitmap comming out.

  If this is not possible, is there a simple aglorithme to determine the
size of the area that gets cropped ?

  Ga=EBl

Win32 printing

[Russell L. <gs...@gh...>]

Developers,

The file src/win/wprinter.c contains some old code for sending 
printer specific output to a printer in DumpPrinter().  The 16-bit 
code is probably still Ok, but probably not much used these days.  
The 32-bit code was written by me to work on Win32s and the full 
Win32.  Win32s had some limitations with printing - the old 16-bit 
APIs are not available, nor are the 32-bit APIs.  The current Win32 
code uses the GDI Escape to try to sneak the data through the printer 
driver.  It should be safe to assume the Win32s isn't used any more.

So we should be able to replace the old Win32 printing code with  
something based on the attached code.  In a slightly different form, 
this code has been used by GSview and Ghostscript for many years.
Note that although the function gp_printfile_win32 has an argument 
named "port", it really is the printer queue name, not the port name.
Some of the existing code to select a printer queue is still needed.

Let me know if you need some assistance with this.  I'm not on the 
gnuplot developer mailing list.


Russell Lang                   gs...@gh...
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/

Re: Now working on POV-Ray terminal

[V. <var...@cl...>]

KITA Toshihiro <t-kita <at> cc.kumamoto-u.ac.jp> writes:


> I am astonished to see the thread starting with

  Sorry, I did Google a bit on such a subject but apperntly not enough.
 
> I and one of my students, Miyata, are currently working on the
> POV-Ray and VRML terminal of gnuplot.

   This is very good new. I was going to give it a try, but I am definitely not
 a good coder and it would have been quite hard for me, especially since I have
very little time to spend on this.

   If I can be of any help don't hesitate, but I must warn you, I am not an IT
professional therefore my ability to read or write code is quite low, and I have
started using povray only two month ago. However this is a project I find very
exiting, both for my own use, and for gnuplot's future and I am more than
willing to help.

    Gaël

Re: %%BoundingBox and %%Orientation in *.ps and *.eps files

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

On Sunday 30 January 2005 11:59 am, Hans-Bernhard Broeker wrote:
>
> Not everytime the 'set size' changes, though.  Just everytime a new page
> is started with a different 'set size' in effect.  The difference
> becomes important if 'multiplot' is in use, where 'set size' doesn't
> actually control the page size if used between 'set multiplot' and
> 'unset multiplot'.

Of course you are correct.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: %%BoundingBox and %%Orientation in *.ps and *.eps files

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

Ethan Merritt wrote:
[...]
> But the sequence
>   set term post
>   set size <x>,<y>
>   plot "foo"
>   set size <x2>,<y2>
>   plot "baz"
> should in principle be setting %%PageBoundingBox each time
> the size is changed.

Not everytime the 'set size' changes, though.  Just everytime a new page 
is started with a different 'set size' in effect.  The difference 
becomes important if 'multiplot' is in use, where 'set size' doesn't 
actually control the page size if used between 'set multiplot' and 
'unset multiplot'.

Re: Contour plots

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

Hans-Bernhard Broeker wrote:

> I guess while at it, the entire command handling of 'set contour'
> would have to undergo a review: 'set clabel' is a dangerously ill-named,
> hard-to-find option; 'set contour' and 'set cntrparam' don't really 
> deserve being separate commands;


I agree with that.  "cntrparam" is too obscure.  "cntr" could mean 
"counter", or "control" or whatever the user's preconceived notion of 
"cntr" is.  Also, my first thought was "set cntrparam", realizing it was 
part of contour, was in fact the label of level curves.

Dan