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

Re: Bug #1503114

[<br...@ph...>]

Daniel J Sebald wrote:
>> Not really.  You just hid it in a spot where it's harder to trigger.
> 
> I'm still debating with myself if this is the case.

Just think of it this way: at some point, the actual endpoint of the 
range *will* jump from 2.0 to, e.g., 2.5.  With the existing code this 
happens exactly if the end of the data range is larger than 2.0.  That's 
by far the clearest and most simple way of doing it.  With the proposed 
modifications the jump would be elsewhere --- and with all the different 
suggestions being made, it's by now entirely unclear where that is.

So the jump won't magically go away --- it just moves to a different 
position on the input axis.  I refuse to see that as an improvement. 
Especially not if we can't even explain it clearly to each other, much 
less to unsuspecting users, where that new position is actually supposed 
to be, and why it should be exactly there.

>> Floating-point rounding is tricky stuff.  It's completely inevitable 
>> that sometimes, results will surprise people.  All this patch does is 
>> move the surprise from a seemingly obvious place to a less obvious 
>> one.  An axis ending at 2.0000001 has no more business being 
>> artificially cut down to 2.0 than one ending at 2.001.
> 
> I think it does in some cases, and depends on the range.  

It depends on entirely too much, IMHO.

> 1) [1.9999999 : 2.0000001]
> 
> 2) [-2.0 : 2.0000001]
> 
> In the first case, yes definitely, the limits have no business being 
> artificially shrunk.
> 
> However, in the second case I'm saying that cutting the upper limit 
> inward to 2.0 rather than rounding outward to 2.5 is not egregious 
> because its effect is beyond the resolution of the plot.  

Maybe.  But as I said, that just moves the problem elsewhere.  There 
*will* be some threshold for which a data range of

	[-2.0: 2.0+delta]

jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].  You say 
that delta=1e-7 should be below the threshold --- but that wilfully 
turns a perfectly valid data point into an out-of-bounds one.   And at 
some point between delta=1e-7 and, say, delta=1e-2, the output range 
*will* jump to 2.5.  Maybe that jump is at delta=1e-3 or at 1e-5, it 
doesn't really matter.   It's still a jump, and somebody will have to 
explain to himself or a puzzled user why that range endpoint made such a 
  huge jump.  As is, that explanation is simple: the actual range was 
larger than 2.0, so gnuplot made room for that.  Now you explain why 
your threshold is exactly where it ends up to be --- and why the same 
data, with the same settings, yield a different range endpoint on 
different terminal drivers.

>> The current behaviour may not be free from surprises, but at least it's
>> correct: an autoscaled axis always contains all its inputs.
> 
> Define correct when we are talking that scale of things.  

We're talking about a plotting program.  It's job is to put data onto 
the plot.  Not outside of it.  Not even by a small margin of error --- 
at least not on purpose.  The whole job of autoscaling is to determine 
an axis range that contains all the input data points.  Your proposed 
changes effectively break the single promise 'set autoscale' exists for.

Re: btw.: did you (the wxterminal developers) compile with gcc -Wall ?

[Dr. J. Z. <joh...@ze...>]

On Wed, Jun 21, 2006 at 01:08:16AM +0200, Timothée Lecomte wrote:
> Dr. Johannes Zellner wrote:
> >I get some warnings and just wanted to report this ...
> >
> >  
> Good remark. I don't because I would like it to be done automatically, 
> and I don't know to do that.
> 
> (I know export CFLAGS="-Wall" but it has to be done on each terminal 
> session, it's annoying)

I'd really, really recommend setting this by default (in your
~/.profile), not just for gnuplot, but for any project development using
gcc. In the last years I found again and again that (collegues) could
have saved a lot of time (and trouble) if they would have used -Wall.
Just a very strong recommendation. As I've it by default, I see also
warnings as it was just the case for gnuplot.

-- 
Johannes

Should NaN be reported as "UNDEFINED" ?

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

On a machine with IEEE-compliant floating point interpretations,
the string "NaN"  (not case sensitive) is a legal floating point
value.  Thus if NaN occurs in an input data file, the point is 
not flagged as DF_UNDEFINED.

Should it be?  

DF_UNDEFINED usually means some random non-parsable
junk appears in the field, or perhaps the field is empty.

I've uploaded a trivial patch that marks input NaN values as
UNDEFINED, attached to Bug #1490699

But I'd like to hear whether everyone agrees that this is
correct behaviour.

What about infinities ("Inf")?  
I am inclined to pass those through, since the sign information
is still present and conceivably a plotting function would want
to handle +/- Inf explicitly.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: btw.: did you (the wxterminal developers) compile with gcc -Wall ?

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

On Tuesday 20 June 2006 02:02 pm, Dr. Johannes Zellner wrote:
> I get some warnings and just wanted to report this ...

I only get these 2.  Both are false alarms.

=2E./term/wxt.trm:112: warning: =E2=80=98font_setting=E2=80=99 may be used =
uninitialized=20
in this function

wxterminal/gp_cairo.c:1029: warning: =E2=80=98overprinted_width=E2=80=99 ma=
y be used=20
uninitialized in this function


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: btw.: did you (the wxterminal developers) compile with gcc -Wall ?

[<tim...@en...>]

Dr. Johannes Zellner wrote:
> I get some warnings and just wanted to report this ...
>
>  =20
Good remark. I don't because I would like it to be done automatically,=20
and I don't know to do that.

(I know export CFLAGS=3D"-Wall" but it has to be done on each terminal=20
session, it's annoying)

Timoth=E9e =20

btw.: did you (the wxterminal developers) compile with gcc -Wall ?

[Dr. J. Z. <joh...@ze...>]

I get some warnings and just wanted to report this ...

-- 
Johannes

Re: Rotate plot in Gnuplot

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

On Saturday 17 June 2006 07:14 am, L=C3=B8v=C3=A5s Olvar wrote:
> Hello,
>
> It is possible to rotate a plot 90 degrees before plotting on screen?

Depends on what terminal type you want to use.
If you don't need mousing, just screen display then you have at
least 2 options:

=46or PostScript output you can switch Landscape/Portrait either
in the plot itself or in the viewer:

  set term post landscape
  set output '|gv -'

=46or PNG you can rotate to any angle you please

  set term png
  set output '|display -rotate 270 png:-'

But I don't know of a way to rotate the output of terminals
x11 or windows so that it's mousable.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Rotate plot in Gnuplot

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

L=F8v=E5s Olvar wrote:
> Hello,
>=20
> It is possible to rotate a plot 90 degrees before plotting on screen?

Probably not, but what are you trying to do that requires rotating a plot=
?  That can be done post output with many devices.  So the question is wh=
ether it is possible to rotate on-screen terminal windows.  Not that I've=
 seen.  Can you give us an example, i.e., point to a link somewhere?

Dan

Re: emf : set label colors effects other elements

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

Just to prevent confusion -

This is the bug reported on the newsgroup last week.
Already fixed in CVS.

	Ethan

On Friday 16 June 2006 09:26 am, Torfinn Ottesen wrote:
> gnuplot - version 4.1 patchlevel 0
>
> Downloaded and compiled just recently from CVS on Cygwin (on Win XP).
> Worked just great -out of the box - thanks for great documentation
> and tool.
>
> For information:
>
> When using the emf-terminal I find that the colors of plot elements:
> boundary box, curves and labels are different from what I see on the
> screen - furthermore - the colors seems to be dependant on the last
> label color I specify, like:
>
> set label "label to be colored blue"  ...... tc lt 3
>
> The following plot should give 3 files: plot1.emf, plot2.emf and
> plot3.emf describing this issue. The xlabel describes what I see:
>
> Torfinn
>
> ------------------
> reset
>
> set output 'plot1.emf'
> set terminal emf
> set grid lt 23
>
>
> #set label 'red blue' at screen 0.010,0.030 tc lt 3  #diff here
> #set label 'red'      at screen 0.010,0.030 tc lt 1  #diff here
> set title  "Investigating red and blue"
> set xlabel "Guess this one is correct, all lines black"
> set ylabel "All axis, curves and titles are black"
>
> plot    \
>  x   t 'x'   w lp lt -1 lw 2         ,     \
> x*x  t 'x*x' w l  lt  1
>
> reset
>
>
> set output 'plot2.emf'
> set terminal emf
> set grid lt 23
>
>
> set label 'red blue' at screen 0.010,0.030 tc lt 3
> set label 'red'      at screen 0.010,0.030 tc lt 1
> set title  "Investigating red and blue"
> set xlabel "Here I see that all curves including boundary box,
> testing label and text of first key (legend) are red"
> set ylabel "red or blue"
> set label 'testing color of label'
>
> plot    \
>  x   t 'x'   w lp lt -1 lw 2         ,     \
> x*x  t 'x*x' w l  lt  1
>
>
>
> reset
> set output 'plot3.emf'
> set terminal emf
> set grid lt 23
>
>
> set label 'red blue' at screen 0.010,0.030 tc lt 3
> #set label 'red'      at screen 0.010,0.030 tc lt 1   # difference
> here set title  "Investigating red and blue"
> set xlabel "Here I see that all curves including boundary box,
> testing label and text of first key (legend) are blue"
> set ylabel "red or blue"
> set label 'testing color of label'
>
> plot    \
>  x   t 'x'   w lp lt -1 lw 2         ,     \
> x*x  t 'x*x' w l  lt  1
>
>
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: thanks and rant

[<tim...@en...>]

Bastian Maerkisch wrote:
> Timoth=E9e Lecomte wrote:
>  =20
>> Timoth=E9e Lecomte wrote:
>>    =20
>>> Daniel J Sebald wrote:
>>>  =20
>>>      =20
>>>> Dr. Johannes Zellner wrote:
>>>>  =20
>>>>    =20
>>>>        =20
>>>>> in trm/post.trm there's a really ugly hardcoded path:
>>>>>
>>>>> #ifndef GNUPLOT_PS_DIR
>>>>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>>>> #endif
>>>>>      =20
>>>>>          =20
>>> (...)
>>>
>>> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
>>> defined (ie when not using ./configure), the best is to make sure tha=
t=20
>>> all custom makefile's do that properly (something else to do before 4=
.2=20
>>> I think).
>>>  =20
>>>      =20
>> In fact this would be wrong for Windows and probably other platforms=20
>> (OS/2 ?), where there are no standard filesystem directories. On these=
=20
>> platforms, hardcoding a path at compile time is completely wrong.
>>
>> Two alternatives for them :
>> - Encode the paths relatively to the binary. Windows has a function fo=
r=20
>> that : GetModuleFileName().
>>    =20
>
> I think, to achieve the same functionality as on other platforms this
> would be the way to do it. Btw. shouldn't argv[0] contain the path
> to the executable in a bit more platform independent way?
>
> Bastian
>  =20
As far as I can tell, argv[0] only contains the name of the executable,=20
not its path.

Timoth=E9e

Re: thanks and rant

[Bastian M. <bma...@we...>]

Timoth=E9e Lecomte wrote:
> .....
> To some extent, this run-time configuration is possible with the=20
> environment variable GNUPLOT_PS_DIR. Ethan has written the code so that=
=20
> it looks for this variable first, as it is done to find the gnuplot_x11=
=20
> executable (X11_DRIVER_DIR) for example.
> ....

As far as I can tell this environment variable is not yet mentioned
in the docs. There should probably be two entries: One in 'environment'
and one in 'set term post'.

Bastian

Re: thanks and rant

[Bastian M. <bma...@we...>]

Timoth=E9e Lecomte wrote:
> Timoth=E9e Lecomte wrote:
>> Daniel J Sebald wrote:
>>  =20
>>> Dr. Johannes Zellner wrote:
>>>  =20
>>>    =20
>>>> in trm/post.trm there's a really ugly hardcoded path:
>>>>
>>>> #ifndef GNUPLOT_PS_DIR
>>>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>>> #endif
>>>>      =20
>> (...)
>>
>> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
>> defined (ie when not using ./configure), the best is to make sure that=
=20
>> all custom makefile's do that properly (something else to do before 4.=
2=20
>> I think).
>>  =20
> In fact this would be wrong for Windows and probably other platforms=20
> (OS/2 ?), where there are no standard filesystem directories. On these =

> platforms, hardcoding a path at compile time is completely wrong.
>=20
> Two alternatives for them :
> - Encode the paths relatively to the binary. Windows has a function for=
=20
> that : GetModuleFileName().

I think, to achieve the same functionality as on other platforms this
would be the way to do it. Btw. shouldn't argv[0] contain the path
to the executable in a bit more platform independent way?

Bastian

Re: thanks and rant

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

Timoth=E9e Lecomte wrote:

>>Dan
>=20
> To some extent, this run-time configuration is possible with the=20
> environment variable GNUPLOT_PS_DIR. Ethan has written the code so that=
=20
> it looks for this variable first, as it is done to find the gnuplot_x11=
=20
> executable (X11_DRIVER_DIR) for example.
>=20
> Anyway, a configuration file only moves the problem to another place :=20
> where is the configuration file located ??? Another hard-coded path ???

Yes, I see your point.

Well, I guess then the only reason to have this kind of thing inside the =
C code:

/* This definition should be in config.h or in the compilation flags */
#ifndef GNUPLOT_PS_DIR
#define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
#endif

is to allow for someone to compile gnuplot without the aid of the autocon=
f/make tools.  (I'm unfamiliar with other platform compilation processes.=
)  Otherwise, I'd say toss this definition.

In any case, perhaps it is wise to allow some means to set this path eith=
er at command line or as 'set path term "asdf"'.  That way we can put som=
ething in the documentation "You don't have to go through the trouble of =
recompiling; just find your resource files and type 'set path'."

Dan

Re: thanks and rant

[<tim...@en...>]

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>> Timoth=E9e Lecomte wrote:
>>
>>> Daniel J Sebald wrote:
>>> =20
>>>
>>>> Dr. Johannes Zellner wrote:
>>>> =20
>>>>  =20
>>>>> in trm/post.trm there's a really ugly hardcoded path:
>>>>>
>>>>> #ifndef GNUPLOT_PS_DIR
>>>>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>>>> #endif
>>>>>     =20
>>>
>>> (...)
>>>
>>> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
>>> defined (ie when not using ./configure), the best is to make sure=20
>>> that all custom makefile's do that properly (something else to do=20
>>> before 4.2 I think).
>>> =20
>>
>> In fact this would be wrong for Windows and probably other platforms=20
>> (OS/2 ?), where there are no standard filesystem directories. On=20
>> these platforms, hardcoding a path at compile time is completely wrong.
>
> Even in unix, propably not the correct method.  This sounds like an=20
> installation time configuration, something that might best be handled=20
> with configuration file that gnuplot can search at startup.  In fact,=20
> one would think that something like autotools would have an automated=20
> process for dealing with such a thing, some macro that indicates a=20
> shared resource directory to be configured when installed.
>
> This is of some importance, because otherwise what we are saying is=20
> that from a distribution standpoint there could be dozens if not more=20
> unique binaries of gnuplot floating about regardless of the=20
> configuration options that the distributers might use.  Is that an issu=
e.
>
> Dan
To some extent, this run-time configuration is possible with the=20
environment variable GNUPLOT_PS_DIR. Ethan has written the code so that=20
it looks for this variable first, as it is done to find the gnuplot_x11=20
executable (X11_DRIVER_DIR) for example.

Anyway, a configuration file only moves the problem to another place :=20
where is the configuration file located ??? Another hard-coded path ???

In Unix, I can see two standard ways to install a program. The first is=20
through the "configure/make/make install" steps, where the installation=20
path is determined at compile time. Installing manually somewhere else=20
is possible but you have to play with the environment variables. The=20
second one is by installing a binary package. Can you choose where to=20
install a .deb or .rpm package ? I don't think so, but I may be wrong.

The nightmare of binary relocation is detailed in the autopackage doc :=20
http://autopackage.org/docs/devguide/ch05.html
Autopackage is a set of tools to create distribution-neutral and=20
relocatable packages. Although it seems a noble objective, it also seems=20
very difficult to achieve. Moreover this project only deals with linux,=20
but not for all UNIX. I don't think we should spend time on making=20
gnuplot relocatable, but rely on the autotools/GNU way.

Timoth=E9e

Re: thanks and rant

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

Timoth=E9e Lecomte wrote:
> Timoth=E9e Lecomte wrote:
>=20
>>Daniel J Sebald wrote:
>> =20
>>
>>>Dr. Johannes Zellner wrote:
>>> =20
>>>   =20
>>>
>>>>in trm/post.trm there's a really ugly hardcoded path:
>>>>
>>>>#ifndef GNUPLOT_PS_DIR
>>>>#define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>>>#endif
>>>>     =20
>>
>>(...)
>>
>>I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
>>defined (ie when not using ./configure), the best is to make sure that=20
>>all custom makefile's do that properly (something else to do before 4.2=
=20
>>I think).
>> =20
>=20
> In fact this would be wrong for Windows and probably other platforms=20
> (OS/2 ?), where there are no standard filesystem directories. On these=20
> platforms, hardcoding a path at compile time is completely wrong.

Even in unix, propably not the correct method.  This sounds like an insta=
llation time configuration, something that might best be handled with con=
figuration file that gnuplot can search at startup.  In fact, one would t=
hink that something like autotools would have an automated process for de=
aling with such a thing, some macro that indicates a shared resource dire=
ctory to be configured when installed.

This is of some importance, because otherwise what we are saying is that =
from a distribution standpoint there could be dozens if not more unique b=
inaries of gnuplot floating about regardless of the configuration options=
 that the distributers might use.  Is that an issue.

Dan

Re: thanks and rant

[<tim...@en...>]

Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
>  =20
>> Dr. Johannes Zellner wrote:
>>  =20
>>    =20
>>> in trm/post.trm there's a really ugly hardcoded path:
>>>
>>> #ifndef GNUPLOT_PS_DIR
>>> #define GNUPLOT_PS_DIR "/usr/local/share/gnuplot/4.1/PostScript"
>>> #endif
>>>      =20
> (...)
>
> I don't have any opinion on what to do when GNUPLOT_PS_DIR is not=20
> defined (ie when not using ./configure), the best is to make sure that=20
> all custom makefile's do that properly (something else to do before 4.2=
=20
> I think).
>  =20
In fact this would be wrong for Windows and probably other platforms=20
(OS/2 ?), where there are no standard filesystem directories. On these=20
platforms, hardcoding a path at compile time is completely wrong.

Two alternatives for them :
- Encode the paths relatively to the binary. Windows has a function for=20
that : GetModuleFileName().
- Include the postscript prologue files at compile time, with something=20
like :

    #ifndef GNUPLOT_PS_DIR
    static char* prologue[] =3D "
    # include PostScript/prologue_ps.h"
    }
    ...
    #endif

    where prologue_ps.h has been written from prologue.ps so that it can=20
be included (replace '{' by '\{' for example ?).

I vote for the second alternative, which would save a lot of work on=20
each platform. As far as I understand, those Postscript files used to=20
live inside post.trm, but are now separate to make development and=20
corrections easier, right ? Falling back to including them at compile=20
time on some platforms doesn't seem a big drawback then.

Timoth=E9e

Re: [gnuplot]: set term size & ConTeXt

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

Ethan Merritt wrote:
> On Monday 19 June 2006 01:19 pm, Petr Mikulik wrote:
> 
>>>  `plot "foo" binary filetype=avs with rgbimage`
>>
>>I wish that gnuplot can read also png images. Usually gnuplot is
>>compiled with libpng, so that should not be a problem.
> 
> 
> It's not quite that simple.  AVS is a streaming format.
> You can read it one pixel at a time and process as you go.
> PNG is much more complicated. I believe that the minimum
> you can read at one go is an entire line, and the more
> normal operation is to read in an entire image. Furthermore,
> there are numerous PNG encoding options, so you have to be
> prepared for reading and interpreting a lot of envelope
> information.
> 
> And that's before we even get into the whole issues of
> truecolor/palette/colorspace/transparency/...
> 
> I honestly think the best way to read in a png image is
> to filter it through ImageMagick and generate an AVS stream.
> 
>    plot "< convert image.png avs:-" binary filetype=avs

AVS is unique in its simplicity, hence writing the code for that was pretty straightforward.  Conceptually, any other image format support should move data about in a similar way.  However, when we start talking more complex formats then it's best to use existing libraries just like GD for the output terminal side of things.

It isn't that difficult, but I think we'd need to devise some method of including only hunks of executable code, just like what has been suggested for the terminal driver.  Otherwise gnuplot starts to become bloated.  Furthermore, if we go to that extent with images, why should any type of datafile format be excluded from this approach regardless of plot style?

Dan

Re: [gnuplot]: set term size & ConTeXt

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

On Monday 19 June 2006 01:19 pm, Petr Mikulik wrote:
> >   `plot "foo" binary filetype=avs with rgbimage`
>
> I wish that gnuplot can read also png images. Usually gnuplot is
> compiled with libpng, so that should not be a problem.

It's not quite that simple.  AVS is a streaming format.
You can read it one pixel at a time and process as you go.
PNG is much more complicated. I believe that the minimum
you can read at one go is an entire line, and the more
normal operation is to read in an entire image. Furthermore,
there are numerous PNG encoding options, so you have to be
prepared for reading and interpreting a lot of envelope
information.

And that's before we even get into the whole issues of
truecolor/palette/colorspace/transparency/...

I honestly think the best way to read in a png image is
to filter it through ImageMagick and generate an AVS stream.

   plot "< convert image.png avs:-" binary filetype=avs

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: [gnuplot]: set term size & ConTeXt

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

>   `plot "foo" binary filetype=avs with rgbimage`

I wish that gnuplot can read also png images. Usually gnuplot is compiled 
with libpng, so that should not be a problem. And people don't know about 
avs, but do about png.

---
PM

Re: [gnuplot]: set term size & ConTeXt

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

>> In case of pm3d plots, polygon's z-value out of zrange is equivalent to 
>> full transparency (polygon is not plotted).
>
> Ah...  And what about syntax, Petr?  "with rgbaimage" makes sense to you? 
> (Most straight forward to program probably.)

OK.

---
PM

Re: [gnuplot]: set term size & ConTeXt

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

On Monday 19 June 2006 01:03 pm, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> > Nothing like cow plots to motivate someone from the dairy state. 

Moo.

> And as for command line syntax, we'll have "with rgbaimage" in a
> fashion similar to "rgbimage"?  

Remember that the decision whether to use transparency is a
separate question from whether the external file contains an alpha
channel.  That is,  
   `plot "foo" binary filetype=avs with rgbimage`
already handles an input stream containing an alpha channel, but
it is just discarded rather than being used in plotting. In the
case of AVS, it *always* has an alpha channel. But I'm not sure
how you generalize it to other input file types.

> What about the possibility of mapping  a particular pixel value
> to transparent, as I imagine a lot of glyphs might do?

That's part and parcel of the same issue. The input file might
not contain a separate alpha channel, but we might nevertheless
be able to generate one on the fly.

> Then again, a lot of palette based images don't have alpha
> blending... Am I worrying about a non-problem?

No. It's a real problem. There has to be a mechanism to specify
how many channels are to be read from the input, and a separate
mechanism to specify how many channels are used in plotting.

The latter may be as simple as a keyword "transparent".
E.g. plot the same file twice, with and without transparency:

  plot "foo" binary filetype=avs with transparent rgbimage
  plot "foo" binary filetype=avs with rgbimage

Or, following your suggestion, it could instead be

  plot "foo" binary filetype=avs with rgbaimage
  plot "foo" binary filetype=avs with rgbimage

In either case the command is controlling whether the alpha
channel is used on *output*.  The input in this case always
has an alpha channel, although that would not be true in general.

	All of this for post-4.2, of course.
	Let's defer detailed discussion til then

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: [gnuplot]: set term size & ConTeXt

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

Petr Mikulik wrote:
>> images before we send it to the terminal driver.)  For pm3d types of 
>> things we might just not plot the element associated with a 
>> transparent value.
> 
> 
> In case of pm3d plots, polygon's z-value out of zrange is equivalent to 
> full transparency (polygon is not plotted).

Ah...  And what about syntax, Petr?  "with rgbaimage" makes sense to you?  (Most straight forward to program probably.)

Dan

Re: [gnuplot]: set term size & ConTeXt

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

> images before we send it to the terminal driver.)  For pm3d types of 
> things we might just not plot the element associated with a transparent 
> value.

In case of pm3d plots, polygon's z-value out of zrange is equivalent to 
full transparency (polygon is not plotted).

---
PM

Re: possible bug in parsing of tics

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

On Monday 19 June 2006 11:58 am, Bastian Maerkisch wrote:
> Hi,
>
> I just tried the following tics setting, leaving out <end>. My
> understanding of the docs is that this should be valid, but isn't:
> ---------
> set y2tics 0, 0.05 textcolor lt 3
>                    ^
> expecting comma to separate incr,end

I'm not sure what it is interpreting that command string as,
but I think the command you want is

 set y2tics offset 0, 0.05 textcolor lt 3

The "offset" keyword was not needed in earlier versions of gnuplot,
in the same way that "linetype" was not needed.  But this led to
ambiguous syntax when additional options were added.  So now
(4.1) both "offset" and "linetype" are required if you use any of
the new options.  The old syntax still works so long as you don't
mix in newer options, so old scripts still work.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: [gnuplot]: set term size & ConTeXt

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

Daniel J Sebald wrote:

> Nothing like cow plots to motivate someone from the dairy state.  (Actually, it just keeps slipping my mind.)  Well, to get started, I'm going to add IC_RGBA to the list, i.e.,
> 
> typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA }
> 	     t_imagecolor;
> 
> and adjust things accordingly to all the terminal drivers.   The advantage of this, as opposed to simply changing IC_RGB to IC_RGBA is data reduction across the pipe in the case of X11 and generally just data reduction whenever.  (I'm always for data reduction when 2D types of elements, e.g. surfaces, images, etc. are in play.)

And as for command line syntax, we'll have "with rgbaimage" in a fashion similar to "rgbimage"?  What about the possibility of mapping a particular pixel value to transparent, as I imagine a lot of glyphs might do?  (Of course, we do that internally by playing a game with the alpha channel for images before we send it to the terminal driver.)  For pm3d types of things we might just not plot the element associated with a transparent value.

gnuplot> set transparent 255

Then again, a lot of palette based images don't have alpha blending... Am I worrying about a non-problem?

Dan