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

Re: gnuplot 4.1

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

dan...@lo... wrote:

>yes sir, would be my pleasure to send it.
>will do so soon.
>
>writing a script to parse the dbf file to a txt/dat/gnu file, it needs to
>be inverted and rotated,, unless gnuplot can do that, will check docs.
>  
>

Below is the best that can be done, I think, with rotating ASCII-based 
data.  Maybe someday "rotate" could be generalized to include ASCII.  
But for now I think you are better off writing a couple extra lines of 
script to rearrange data if it isn't too difficult and then go with the 
previous "matrix" arrangement.

Dan


set palette defined \
(0 "black", \
1 "red", \
2 "green", \
3 "white", \
4 "white", \
5 "white",\
6 "yellow",\
7 "white")\
maxcolors 8

plot '-' u -2:0:1 w image
0
0
1
1
0
0
0
0
0
0


0
1
6
6
6
6
2
2
1
0


2
1
6
6
6
6
6
2
1
1


2
2
2
6
6
6
2
2
2
1


2
2
2
2
2
2
2
2
2
2
e

Re: gd.trm and multiple plots with png

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

It would be possible.

The "not a pipe" test may be problematic, since there are all
sorts of reasons for using a pipe, and some of them might well
benefit from the new option.

For what it's worth, there is an extended standard that permits
multiple images in *one* png file. It is supported, for instance,
by ImageMagick.  But as I recall this isn't currently provided
by libgd.



On Wednesday 12 January 2005 04:54 pm, Jim Kleckner wrote:
> Would it make any sense to hack gd.trm to
> add an option to detect when a new plot is
> created and if output is to a non-pipe named
> file to auto-append a number ahead of the extension
> and close/reopen the file?  Quick inspection
> of the code suggests that it can be done but perhaps
> there are gotchas and/or complexities that don't
> show on the surface.  For multiplot plots as
> an example.
> 
> An option named, say, auto_number_files ?
> 
> Issuing "set output" commands for every plot
> can be a tedious retrofit to something that
> works with PS or PDF.
> 
> Comments?
> 
> Jim
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

gd.trm and multiple plots with png

[Jim K. <je...@kl...>]

Would it make any sense to hack gd.trm to
add an option to detect when a new plot is
created and if output is to a non-pipe named
file to auto-append a number ahead of the extension
and close/reopen the file?  Quick inspection
of the code suggests that it can be done but perhaps
there are gotchas and/or complexities that don't
show on the surface.  For multiplot plots as
an example.

An option named, say, auto_number_files ?

Issuing "set output" commands for every plot
can be a tedious retrofit to something that
works with PS or PDF.

Comments?

Jim

Re: *** QUESTION: HOW MANY FUNCTIONS THAT CAN BE PLOTTED AT ONCE?

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

On Sunday 09 January 2005 04:50 pm, Pier Luca Lanzi wrote:
> 
> If you plot it, some holes in the plot will appear as if 
> some sections of the domain are not covered.
> 
> This for instance happens between 0 and 100.
> 
> Then, if you change the script and plot only the section 
> between 0 and 100 the holes disappear.

It is at least part a matter of how finely you sample along
the x axis.  Try setting
	set sample 10000
before your plot command

> Is there a limit to the number of functions that gnuplot 
> can plot at once?

No.  Although eventually you might run out of memory to
store them.


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

Re: *** QUESTION: HOW MANY FUNCTIONS THAT CAN BE PLOTTED AT ONCE?

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

Pier Luca Lanzi wrote:

> dear gnuplot people,
> sorry to bother with probably a naive question.
>
> I have a problem with gnuplot. I have a program that generates many 
> functions that must be plotted all together in the same plot.
> An example of the typical script I generate is in attach.
>
> If you plot it, some holes in the plot will appear as if some sections 
> of the domain are not covered.


You're plot a piece-wise continuous funtion of sorts, right?  I'm under 
the impression that gnuplot is plotting exactly what you are telling it 
to.  Look closely at your sections and consider stuff like this (which 
plots nothing):

 cl1841173(x1)=(x1>=1000 && x1<=1000)?-10.1292*1000+x1*10.1268:1/0

Dan

Re: Command line way to prevent unbuffered?

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

> I just noted comments in FAQ and INSTALL.
> gcc has __CYGWIN__ defined for the platform.
>
> BTW, the comment in INSTALL seems wrong now as
> cygwin seems to configure and build for X11
> "out of the box".  The comment says something
> about copying a makefile.cyg and using that.
> Not needed if you are using cygwin for X11 and
> not trying to build a native windows app with
> mingw.

With cygwin, you can either
1. build native Win API wgnuplot.exe as described above, or
2. build X11 gnuplot.exe by the unixish ./configure; make procedure

Into INSTALL, it should probably be added a note at the end of the MSW
section about the possibility 2 and refer to the Unix section.

---
PM

Re: Command line way to prevent unbuffered?

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

On Tuesday 11 January 2005 06:59 pm, Jim Kleckner wrote:
>
> I just noted comments in FAQ and INSTALL.
> gcc has __CYGWIN__ defined for the platform.

That does not, by itself, make it easy to test in the
configure script.  I'm sure it's possible to exploit it
somehow and feed back a symbol to autoconf, but I'll leave
that to the autoconf experts.

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

Re: Command line way to prevent unbuffered?

[Jim K. <je...@kl...>]

Ethan Merritt wrote:
> On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote:
> 
>>cygwin looks like a unix box with X11 and it already appears in
>>configure I see.
> 
> 
> But does it define some symbol I can test on to see if the
> current ./configure is being run on cygwin?  
> 
> I don't see any mention of cygwin in any of gnuplot's own configuration
> files. The closest I can find is the forced definition of __WIN32__
> in the file config/config.cyg but I am not sure how specific that is.

I just noted comments in FAQ and INSTALL.
gcc has __CYGWIN__ defined for the platform.

BTW, the comment in INSTALL seems wrong now as
cygwin seems to configure and build for X11
"out of the box".  The comment says something
about copying a makefile.cyg and using that.
Not needed if you are using cygwin for X11 and
not trying to build a native windows app with
mingw.

Re: Command line way to prevent unbuffered?

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

On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote:
> >
> cygwin looks like a unix box with X11 and it already appears in
> configure I see.

But does it define some symbol I can test on to see if the
current ./configure is being run on cygwin?  

I don't see any mention of cygwin in any of gnuplot's own configuration
files. The closest I can find is the forced definition of __WIN32__
in the file config/config.cyg but I am not sure how specific that is.



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

Re: Command line way to prevent unbuffered?

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

On Tuesday 11 January 2005 11:14 am, Jim Kleckner wrote:
> 
> The demo seems to work the same way with buffering on or off.
> It also seems to work correctly with one exception. A tab or enter
> does not terminate the keystroke.dem sub-test.

OK. Thanks.
That last is a known bug. I've got a fix for it, but it's currently
wrapped in a larger patchset that I want to have discussed on the
mailing list.  Maybe I should break it out separately.


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

Re: Command line way to prevent unbuffered?

[Jim K. <je...@kl...>]

Ethan Merritt wrote:

>On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
>  
>
>>>diff -u -r1.72 plot.c
>>>--- plot.c    25 Aug 2004 22:33:16 -0000    1.72
>>>+++ plot.c    11 Jan 2005 05:26:21 -0000
>>>@@ -422,7 +422,9 @@
>>>      * Do any non-X platforms suffer from the same problem?
>>>      * EAM - Jan 2004.
>>>      */
>>>-    setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>>+    if (isatty(fileno(stdin))) {
>>>+        setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>>+    }
>>> #endif
>>>      
>>>
>>I see why you want this.  But speed is no good if the program
>>does not function properly, and previous experience showed that
>>unbuffering the input stream was needed for at least some 
>>implementations of piped input.
>>    
>>
>
>I have changed my mind.  The behavior is not likely to differ
>from user to user, only from one platform to another. So it should
>be a configuration option for building on that platform, not a
>run-time option on the command line.
>
>How about we wrap the code as follows:
>
>#ifndef UNBUFFERED_STDIN
>    setvbuf(stdin, (char *) NULL, _IONBF, 0);
>#endif
>
>and you can provide a brief set of instructions for how to set
>this conditional compilation flag during the cygwin configuration setup.
>I have not used cygwin, so I don't know exactly how that is done.
>
>It would be nice if you also checked that this doesn't interfere
>with correct execution of "pause" commands, however, since as I
>recall that was one of the original problems this was supposed to fix.
>For instance, please check that "mousevariables.dem" works properly with 
>buffered input under cygwin. 
>
>  
>
cygwin looks like a unix box with X11 and it already appears in
configure I see.
I have just been doing configure and build and it works fine (I pre-install
the PDF library so that it will get detected at configure time).

The demo seems to work the same way with buffering on or off.
It also seems to work correctly with one exception. A tab or enter
does not terminate the keystroke.dem sub-test.

Jim

Re: Command line way to prevent unbuffered?

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

On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
> >
> > diff -u -r1.72 plot.c
> > --- plot.c    25 Aug 2004 22:33:16 -0000    1.72
> > +++ plot.c    11 Jan 2005 05:26:21 -0000
> > @@ -422,7 +422,9 @@
> >       * Do any non-X platforms suffer from the same problem?
> >       * EAM - Jan 2004.
> >       */
> > -    setvbuf(stdin, (char *) NULL, _IONBF, 0);
> > +    if (isatty(fileno(stdin))) {
> > +        setvbuf(stdin, (char *) NULL, _IONBF, 0);
> > +    }
> >  #endif
> 
> 
> I see why you want this.  But speed is no good if the program
> does not function properly, and previous experience showed that
> unbuffering the input stream was needed for at least some 
> implementations of piped input.

I have changed my mind.  The behavior is not likely to differ
from user to user, only from one platform to another. So it should
be a configuration option for building on that platform, not a
run-time option on the command line.

How about we wrap the code as follows:

#ifndef UNBUFFERED_STDIN
    setvbuf(stdin, (char *) NULL, _IONBF, 0);
#endif

and you can provide a brief set of instructions for how to set
this conditional compilation flag during the cygwin configuration setup.
I have not used cygwin, so I don't know exactly how that is done.

It would be nice if you also checked that this doesn't interfere
with correct execution of "pause" commands, however, since as I
recall that was one of the original problems this was supposed to fix.
For instance, please check that "mousevariables.dem" works properly with 
buffered input under cygwin. 

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

Re: square behavior

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

> >Yes, once the postscript file is completely written -- that's how fixbb, "gs
> >-DEVICE=bbox" or epstool work. For figures, I always do
> >	fixbb blabla.eps
> >whatever application produced the eps file.
>
> OK.  I see this is listed right there on the gnuplot web page.  (Oy.)
> Unfortunately, the link is forbidden.

Lars, please "chmod -x" all your files in
gnuplot.sf.net:scripts/files/

---
PM

Re: square behavior

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

Petr Mikulik wrote:

>>>>>For the png driver there is the additional option of using
>>>>>	set term png crop
>>>>>
>>>>>          
>>>>>
>>>>YES!!!!!!!!  Everything fine trimmed right up to the first non-white
>>>>pixels.  Perfect.  Every terminal should have such an option.
>>>>        
>>>>
>>>Feel free to contribute one for your favorite driver.
>>>
>>>      
>>>
>>Well, this is what I'm wondering.  Is this feature as straightforward
>>in, say, PostScript as it might be in PNG?
>>    
>>
>
>Yes, once the postscript file is completely written -- that's how fixbb, "gs
>-DEVICE=bbox" or epstool work. For figures, I always do
>	fixbb blabla.eps
>whatever application produced the eps file.
>  
>

OK.  I see this is listed right there on the gnuplot web page.  (Oy.)  
Unfortunately, the link is forbidden.

Dan

Re: "image"-related exotic interoperability question

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

Petr Mikulik wrote:

>> It would be easy enough I think to generate a color image from an
>>
>>indexed image.
>>    
>>
>
>Why is this needed? I guess nobody wants to edit the postscript file -- if
>you want, that's why the current palette is programmatic.
>  
>

People seem to be wondering... so I guess it shouldn't be done.  Case 
closed.

Dan

Re: "image"-related exotic interoperability question

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

> >I don't know if this is of interest at all to anyone else, but would it be
> >possible without a lot of effort to force gnuplot to output a non-indexed
> >rgb bitmap (with three times the size of course)? particularly since this
> >type of image is already produced by other plot commands...
>
> Does this seem like an option worth adding to the PostScript terminal?
>
> It would be easy enough I think to generate a color image from an
> indexed image.

Why is this needed? I guess nobody wants to edit the postscript file -- if
you want, that's why the current palette is programmatic.

---
PM

Re: square behavior

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

> >>>For the png driver there is the additional option of using
> >>>	set term png crop
> >>>
> >>YES!!!!!!!!  Everything fine trimmed right up to the first non-white
> >>pixels.  Perfect.  Every terminal should have such an option.
> >
> >Feel free to contribute one for your favorite driver.
> >
> Well, this is what I'm wondering.  Is this feature as straightforward
> in, say, PostScript as it might be in PNG?

Yes, once the postscript file is completely written -- that's how fixbb, "gs
-DEVICE=bbox" or epstool work. For figures, I always do
	fixbb blabla.eps
whatever application produced the eps file.

---
PM

Re: Command line way to prevent unbuffered?

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

On Monday 10 January 2005 09:47 pm, Jim Kleckner wrote:
> I looked at the code lower down where the "interactive" variable is set.
> The most minimal change seemed to be to duplicate the isatty code as
> follows:
>
> diff -u -r1.72 plot.c
> --- plot.c    25 Aug 2004 22:33:16 -0000    1.72
> +++ plot.c    11 Jan 2005 05:26:21 -0000
> @@ -422,7 +422,9 @@
>       * Do any non-X platforms suffer from the same problem?
>       * EAM - Jan 2004.
>       */
> -    setvbuf(stdin, (char *) NULL, _IONBF, 0);
> +    if (isatty(fileno(stdin))) {
> +        setvbuf(stdin, (char *) NULL, _IONBF, 0);
> +    }
>  #endif

This code was added originally because it was needed in order
that piped input not lose large runs of input characters
at the start of the file and also after "pause -1" statements.
It may be that your particular environment does not need this,
but I am pretty sure that the modification you propose above
will re-break the same cases that caused the problem in the
first place.

In other words, a test on isatty() is not what is needed.
I think a command line option, as you originally suggested,
is the only safe way to disable this.  Users can try it with
and without the extra option to determine whether their 
particular environment requires immediate flushing or not.

> My regression tests before the change (on a 3GHz P4 HT machine) used:
>  940.66user 628.54system 25:19.91elapsed
> and after:
>   621.38user 5.32system 10:22.86elapsed

I see why you want this.  But speed is no good if the program
does not function properly, and previous experience showed that
unbuffering the input stream was needed for at least some 
implementations of piped input.

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

Re: Command line way to prevent unbuffered?

[Jim K. <je...@kl...>]

Jim Kleckner wrote:

> I'm using gnuplot to create PDF files most of the time.  I find that 
> the unbuffered setting to make X11 work with the mouse and pasteboard 
> vastly increases the syscall overhead for this batch operation.  Would 
> it make sense to add an argument to be able to permit buffering?  I'm 
> using cygwin so perhaps there is some set of porting options that 
> interact on this platform.


I looked at the code lower down where the "interactive" variable is set.
The most minimal change seemed to be to duplicate the isatty code as
follows:

diff -u -r1.72 plot.c
--- plot.c    25 Aug 2004 22:33:16 -0000    1.72
+++ plot.c    11 Jan 2005 05:26:21 -0000
@@ -422,7 +422,9 @@
      * Do any non-X platforms suffer from the same problem?
      * EAM - Jan 2004.
      */
-    setvbuf(stdin, (char *) NULL, _IONBF, 0);
+    if (isatty(fileno(stdin))) {
+        setvbuf(stdin, (char *) NULL, _IONBF, 0);
+    }
 #endif

My regression tests before the change (on a 3GHz P4 HT machine) used:
 940.66user 628.54system 25:19.91elapsed
and after:
  621.38user 5.32system 10:22.86elapsed

The difference is so big because I'm using gnuplot-py to drive
the plots and it uses a pipe and inline data (quite a lot of it).

Comments?  I might easily be missing something important
here.

Jim

Re: square behavior

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

Ethan Merritt wrote:

>On Monday 10 January 2005 08:33 pm, Daniel J Sebald wrote:
>  
>
>>I just think there is no case where a user wants that extra white space
>>in an EPS file that comes about from "square".  It's tolerable in X11,
>>but not as an imported graphic.
>>    
>>
>
>Disagree. I usually need an imported graphic to fit in an allocated
>*vertical* space, while the horizontal size is set by the column width.
>I want to specify size in column-inches, and any resulting whitespace
>on the edges is an expected consequence.
>  
>

That's true. But the amount of white space is easy to control in a word
processor. Usually there is a way to control width and/or height
depending upon whether one wants to maintain aspect ratio, which almost
always I want to do. For example, with LaTeX

/begin{figure*}[t]
/leavevmode
/centering
/epsfig{file=spikespec_ann.eps,width=0.7/columnwidth}
//*
/parbox{/columncaptionwidth}{
/caption{/label{fig:plottwo} Transform of neural spikes from
/reffig{fig:plotone}.}
}
/end{figure*}

formats a graph nicely; if the white space is trimmed away from the
figure that is. Could change the width. Could use height. Both.
Everything is scaled nicely. But if that white space gnuplot adds is
considered part of the width, there is no nice way of getting rid of it
without some bad LaTeX tricks that give errors. That, or things are off
center and space is used up.

>Anyhow, if you don't like the bounding box on a particular eps plot,
>just call up ghostscript and change it to suit.
>  
>

I know. But adding an extra step for the user isn't user friendly.

Dan

PS: Just downloaded LyX.

Re: square behavior

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

On Monday 10 January 2005 08:33 pm, Daniel J Sebald wrote:
>
> I just think there is no case where a user wants that extra white space
> in an EPS file that comes about from "square".  It's tolerable in X11,
> but not as an imported graphic.

Disagree. I usually need an imported graphic to fit in an allocated
*vertical* space, while the horizontal size is set by the column width.
I want to specify size in column-inches, and any resulting whitespace
on the edges is an expected consequence.

Anyhow, if you don't like the bounding box on a particular eps plot,
just call up ghostscript and change it to suit.

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

Re: square behavior

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

Ethan Merritt wrote:

>>left edge and whatever ends up with white space, right or top, so be 
>>it.  In the case of "square" size it's as though one anchors from the lower, 
>>    
>>
> <>
>
> In a word: no. Not the way the code is currently laid out.
> You'd enter a possibly infinite cycle of re-adjusting and recalculating
> and re-laying out and retesting.


Maybe this can be made to work out.  In a few weeks I will have a look; 
perhaps I'll revisit the key patch at the same time since it is related.

Also, in some patch I think I once put code that balanced the left and 
right or top and bottom whitespace in the case of "square".  I'd like to 
propose putting that back in if I can find it again.  It looked so much 
better in X11 plots.  Also, I bet it would look a whole lot better with 
multiplot subplots that use the square size option, in all terminals.

I just think there is no case where a user wants that extra white space 
in an EPS file that comes about from "square".  It's tolerable in X11, 
but not as an imported graphic.

First, there is a philosophical restriction here in that the BoundingBox 
must be output before other PostScript command are.  I don't think we 
want to approach this by, say, rerouting PostScript commands to a temp 
file, computing the BoundingBox, generating header in desired output 
file, then dumping the temp file to the desired output file.  No?  So 
that means we must stay away from a terminal level solution?

That being the case, the multiplot plots really pose a problem because 
each multiplot plot is done as a separate plot command.  There is 
absolutely no way to generate BoundingBox information in that situation 
because we are forced to send out plots before closing the multiplot.  
This may not be such a severe limitation.  In the case of multiplot, 
unless ones specifies all subplots sizes "square", there will be some 
whitespace that can't be removed.

OK, so let's just consider the single plot scenario.  In the code are 
the following few commands when starting a plot.

    /* EAM June 2003 - Although the comment below implies that font 
dimensions
     * are known after term_init(), this is not true at least for the X11
     * driver.  X11 fonts are not set until an actual display window is
     * opened, and that happens in term->graphics(), which is called from
     * term_start_plot().
     */
    term_init();        /* may set xmax/ymax */
    term_start_plot();

    /* compute boundary for plot (xleft, xright, ytop, ybot)
     * also calculates tics, since xtics depend on xleft
     * but xleft depends on ytics. Boundary calculations depend
     * on term->v_char etc, so terminal must be initialised first.
     */
    boundary(plots, pcount);

term_init() is where the BoundingBox is written.  I believe that 
boundary() is where axes etc. are computed, but nothing is written to 
the terminal.  So, if boundary() could be moved before 
"term_start_plot()" and BoundingBox could be written inside 
term_start_plot() we might have knowledge of the extent of the image 
before writing the BoundingBox.  Could the bounding box info be passed 
into the terminal via the "options" function and most terminals just 
ignore it?

Dan

Re: Fill plot area with background color

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

Daniel J Sebald wrote:

> Ethan Merritt wrote:
>
>> On Monday 10 January 2005 11:05 am, Harald Harders wrote:
>>  
>>
>>>
>>> plot 1 with filledcurves above y1=-1 ls 9999,\
>>>     sin(x) ls 1
>>>
>   In any case, this begs the question, why isn't there a demo for this 
> sort of thing?


Oh, now I see.  This is a bit kudgy, with the filledcurves to fill the 
whole backdrop.  But it is the right idea.  So, a better syntax and then 
a demo would be nice.  Below is Petr's ideas for a syntax, pretty much 
the same as putting rectangles behind the various elements.  (The 
problem with the "rectangle <location>" is that the user will not know 
exactly where the key will land.

Color control beyond the basic 1,2,...,8 colors would be nice.  I think 
Petr and Ethan discussed a more advanced color syntax, if I'm not mistaken.

Dan

==========

Yet another background is that of the graph (easy for 2D and 'view map',
more intriguing for 3D), and for the key.

What about some new syntax for that?

set key ... background rgb "gray10"
set border ... background rgb "gray10"
set size ... background rgb "cyan"

or

set style background {key | border | graph | paper} .... ?

Re: "image"-related exotic interoperability question

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

Ethan Merritt wrote:

>I didn't see the original message, so I have no context for what
>you guys are talking about here.   My gut reaction is that anybody
>who wants a bitmap image should not be using PostScript in the
>first place. That's why we have a png driver.
>  
>

I like PNG, but sometimes one is forced to use PostScript, e.g., LaTeX.  
Another difference is that with PNG the whole plot is a bitmapped image, 
borders, fonts and all.  With EPS, it is just the image on the plot that 
is indexed; the fonts and lines all remain high res.

Dan

Re: Fill plot area with background color

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

Ethan Merritt wrote:

>On Monday 10 January 2005 11:05 am, Harald Harders wrote:
>  
>
>>Is there a way to fill the plot area with a background color?
>>What I mean is similar to this example:
>>
>>set terminal postscript eps color rounded linewidth 2
>>set output 'asdf.eps'
>>set style line 1 lt 1 lw 4
>>set style line 9999 lt 6 lw 1
>>set style fill solid 1
>>plot 1 with filledcurves above y1=-1 ls 9999,\
>>     sin(x) ls 1
>>
>>Unfortunately, the tics are lost here.
>>    
>>
>
>To get your tics back, add the command
>  set grid front nox noy noz
>  
>

If the density of the fill is set to 0.3 or so, this turns out really 
nice.  Sort of what I had in mind a few months back...  Well, it looks 
good in PostScript that is, because the background is pastel yellow... 
which probably is almost always going to be the preferred color for such 
things.  In x11, the color is brown, which you can guess what that looks 
like.  In any case, this begs the question, why isn't there a demo for 
this sort of thing?

Dan