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

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

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

  Hello,

  Great to see a gnuplot output some povray. It fantastic.

  I gave it a quick look, but I won't have time to look at it again this
week.

#### My first impressions :

  No colours, and color-box, that's really sad. I guess it is just a
matter of giving it a bit more work.

  Titles should be reasonably easy to add.

  set pm3d hidden3d doesn't seem to work.

  The conventions you used to specify surface type are not quite
intuitive. There probably will be some thinking to do as to what gnuplot
instructions generate what povray material.

  I suggest trying to stick as much as possible to gnuplot standard
behaviour :

  ***  No options -> wireframe + some thing like this :
pigment {
                gradient z
                 color_map {
                [0.0  color rgb <0,0,0>]
                [0.25 color rgb <0.5,0,1>]
                [0.5  color rgb <1,0,0>]
                [0.75 color rgb <1,0.5,0>]
                [1.0  color rgb <1,1,0>]

    (of course the value of the colour map would be generated from the
gnuplot palette, possibly using gnuplot's "show palette palette <n>"
function)

  *** set p3md transparent -> only wireframe (current default behaviour).

  *** unset surface would turn the wireframe off.

#### A few comments on the code

  Looking at gnuplot's code and at the way you patched gnuplot to have
the povray terminal work, this patch seems a bit of a dirty hack. It
establishes special routines to plot vrml and povray. As Ethan points
out this will probably be very hard to maintain. The file=20
gnuplot-4.0.0/term/README defines quite clearly the way it shoud be
done. However in a povray or vrml terminal, this terminal standard
cannot be defined. I think it makes sens to separate 2D terminals (all
existing ones) and 3D terminals (vrml, povray, and hopefully more). The
core gnuplot core could be adapted to behave differently whether the
terminal is 2D or 3D (is is currently a completely 2D code) and the
actual translation of gnuplot internals in povray code could be made by
the terminal.

  Of course setting up the 3D code in gnuplot would require some work
from gnuplot devellopers, but I think it is worth the while. Especially
since the 2D code could be a projection of the 3D code. But I haven't
looked enough at gnuplots internal to know if this is possible.

  Thanks a lot for your and your student's work. I hope you will get
some help from people who know gnuplot's code better on this project. I
am willing to help (whenever I have time) with the terminal itself, but
I would rather not play with the core gnuplot function.

  Ga=EBl

PS :
  To answer ethan's suggestion about extending gnuplot's color
specifiaction to include alpha channel, yes, I think it would be great.

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

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

On Sunday 03 April 2005 08:08 pm, KITA Toshihiro wrote:
> I announce the first release of the patch to add povray and vrml
> terminals to gnuplot 4.0.
>
> http://t-kita.net/gnuplot_povrml/
>
> Any comments and suggestions will be appreciated.

The patch on your website is the patch you are talking about?

It does not fit well with the design of gnuplot.
Although you call these "terminals", in fact the terminal
routines are just place holders, leaving the real work to be
done by stand-alone routines that have to replicate all
the data-handling and plot evaluation that the gnuplot core
routines currently do.

Such a design would be very hard to maintain, even if it were
fully working. Every change to gnuplot's internal data structures
or plotting capabilities would have to be made in parallel to the
normal core routines and to these new povray and vrml routines.

Therefore while this code is interesting as a proof-of-principle,
I think that in order to progress towards inclusion into gnuplot
proper all or most of this code must be moved into actual terminal
driver routines (POVRAY_init(), POVRAY_options(), POVRAY_move(), etc).

In the long run I think you will find that will be much simpler anyway.
Let the existing core routines do the hard work for you.

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

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

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

On Sunday 03 April 2005 08:08 pm, KITA Toshihiro wrote:
> http://t-kita.net/gnuplot_povrml/

I see you are post-processing to add transparency:
 set terminal povray
 set view 70,305
 set out "tmp.pov"
 # klein.dat is one of the gnuplot demo data
 splot "klein.dat" with d
 set out
 ! sed 's/Red/Red filter 0.5/' tmp.pov > povray-demo3.pov 
 ! povray +FC +A0.1 +I povray-demo3.pov

Would it make sense to extend gnuplot's color specifications
to include an alpha channel?
I'm not so sure that's a good idea, actually.
It might make sense, however, to have transparency be an 
attribute of each surface as a whole.
Something like:

  plot "foo" with pm3d transparent, "baz" with pm3d solid



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

please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

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

Hello, =


I know I said 'in several weeks' but actually 'in several month,'
I announce the first release of the patch to add povray and vrml
terminals to gnuplot 4.0.

http://t-kita.net/gnuplot_povrml/

# I would like to put the patch also in sourceforge.net as soon as
# I get to know how. =


These terminals have been mostly written by one of my students, =

MIYATA Shigeo, and I have revised them against the errors
and problems found while making the demo images.
# In povray terminal, plotting with polygons is implemented thanks to
# the suggestions from Harald Harders.

The code is far from complete, but I would like to know how much
gnuplot users are interested in these terminals.

Any comments and suggestions will be appreciated.


From: Ga=EBl Varoquaux
Subject: Re: Now working on POV-Ray terminal
Date: Fri, 4 Feb 2005 19:02:25 +0000 (UTC)

> 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 prog=
ress, I
> find. It gives a basis to start building on. I am very much looking f=
orward to
> see your work.
-- =

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

Re: Help wanted: Minor *.doc -> *.tex problem

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

On Sunday 03 April 2005 08:22 am, you wrote:
> but you may want to check what's going on there...]
>
> > I found the problem because I was trying to add a new section
> > elsewhere. Adding additional levels is the only way I know of to
> > break the interactive help into shorter sections and have it
> > prompt for additional keywords. =C2=A0So it's useful in the *.gih form.
>
> Let's say: it can be, if not abused. =C2=A0A node with only one subnode
> doesn't make terribly much sense, IMHO.
>
> I don't think keeping individual nodes short would be sufficient reason
> to split them up. =C2=A0It's more important to keep up the principle of
> one subject matter <--> one node.

The issue is how to allow access to the same help section via
multiple keywords for the 'help' command.

=46or example: There is a longish section on the 'with histogram'
style. It is located with the other plot style entries as:
  5 histograms
  ?commands set style histogram

So it is already 5 levels deep.  At the end of this section is an
explanation of the 'newhistogram' command.  Unfortunately, you cannot
find it by typing 'help newhistogram'.  It was not clear to me that
I could simply add a line
  ?newhistogram
without first creating a new section heading
  6 newhistogram

Upon experimentation, I see that in fact it is possible to add
the '?<foo>' form without a corresponding '6 <foo>' form.
This allows 'help newhistogram' to work, and does not add a
separate 6th level entry to the ToC.  However, it also causes
'help set style histogram' to terminate without printing this
last section.  So there's still a problem.

It wouldn't make any sense to bump 'newhistogram' up to a
parallel 5th level entry, because it isn't a plotting style on
its own.

Suggestions?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: Help wanted: Minor *.doc -> *.tex problem

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

Ethan Merritt wrote:

[Ethan, a side note: you occasionally send mail encoded as Japanese
(Shift-JIS) for no readily apparent reason.  It's not a major hassle,
but you may want to check what's going on there...]

> I found the problem because I was trying to add a new section
> elsewhere. Adding additional levels is the only way I know of to
> break the interactive help into shorter sections and have it
> prompt for additional keywords.  So it's useful in the *.gih form.

Let's say: it can be, if not abused.  A node with only one subnode
doesn't make terribly much sense, IMHO.

I don't think keeping individual nodes short would be sufficient reason
to split them up.  It's more important to keep up the principle of
one subject matter <--> one node.

> In the printed docs it is maybe not so useful.  Levels beyond
> 4 or 5 may not need a separate TOC number of their own.

Levels beyond 6 already don't --- they'll just end up starting
plain paragraphs.

> But it would be nice to have an index at the back that catches
> them. Is that possible?

Possible: yes.  But it could turn into a major hassle to make it happen.
Currently, our LaTeX document has no index at all.  Adding the necessary
apparatus to generate one could prove quite tricky.

Re: Help wanted: Minor *.doc -> *.tex problem

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

Ethan Merritt wrote:
> On Friday 01 April 2005 01:19 pm, Juergen Wieferink wrote:

>>I think it's quite distracting that both section headings and
>>backquoted text get boldfaced.  Wouldn't it be nicer to have the
>>latter italic?  This could be done by substituting "{\\bf " with
>>"{\\em " in line 406.

> I agree.  Anyone else have opinions on this?

Fine with me.

And while we're at it, I've found yet another quirk that may need
addressing: gnuplot has some subsection count run up into three-digit 
numbers.  LaTeX doesn't anticipate that, and the resulting formatting
is quite spectacularly bad (see the lower half of page 9 of gnuplot.ps, 
i.e. the last couple subsections below section 'Set-show').

That said, I still think we should

1) switch from article to report
2) change doc2texi to turn what are now \section's into \chapter's
    (and so on down the hierarchy)

And hierarchy levels beyond 6 probably shouldn't generate any TOC 
entries (\paragraph*, or maybe just fall through to the default: case, 
i.e. do nothing in particular).

Re: Looks like a parsing problem?

[Justace C. <pro...@co...>]

Problem fixed, inadvertantly had two different versions of gnuplot
installed, one in /usr/local/bin and one in /usr/bin.  The one
in /usr/local/bin/works correctly.  Sorry for the uneeded traffic.

Justace

On Sat, 2005-04-02 at 07:35 -0600, Justace Clutter wrote:
> Hey everybody,
> 
> 	So, I have just encountered a small problem.  I usually create a
> gnuplot script that can just be executed from the command line in Linux.
> I do this throught the #! style.  Here is the thing though, I want to
> use sprintf.  When I use sprintf in an interactive session it works
> fine.  When I put this line in a script I get the following error:
> 
> gnuplot> blah = sprintf("Hello")
>                         ^
>          "./cost", line 54: invalid expression
> 
> 	I will include the script just below so that we can see if I am missing
> anything.  I am running version 4.1 patchlevel 0.  Thanks for any
> information.
> 
> 
> --------------------Script Below
> #!/usr/bin/gnuplot
> 
> budget         = 1000
> 
> gas_rate       = 2.20
> trip_distance  = 1400
> 
> auto_insurance = 24.95
> 
> car_mpg        = 25
> car_cost       = 30 + auto_insurance
> car_cap        = 4
> 
> van_mpg        = 15
> van_cost       = 75 + auto_insurance
> van_cap        = 9
> 
> hotel_cost     = 75
> hotel_cap      = 4
> 
> NumberOfVans(x) = ceil(x/van_cap)
> NumberOfCars(x) = ceil(x/car_cap)
> 
> HotelCost(x) = hotel_cost * (ceil(x/hotel_cap))
> VanCost(x)   = NumberOfVans(x)*van_cost +
> NumberOfVans(x)*((trip_distance/van_mpg)*gas_rate)
> CarCost(x)   = NumberOfCars(x)*car_cost +
> NumberOfCars(x)*((trip_distance/car_mpg)*gas_rate)
> 
> TripCostVan(x)  = HotelCost(x) + VanCost(x)
> TripCostCar(x)  = HotelCost(x) + CarCost(x)
> 
> AdditionalCostVanUnbound(x) = (TripCostVan(x)-budget)/x
> AdditionalCostCarUnbound(x) = (TripCostCar(x)-budget)/x
> 
> AdditionalCostVan(x) = AdditionalCostVanUnbound(x)<0 ? 1/0 :
> AdditionalCostVanUnbound(x)
> AdditionalCostCar(x) = AdditionalCostCarUnbound(x)<0 ? 1/0 :
> AdditionalCostCarUnbound(x)
> 
> set title "Cost of the SPS Fermilab Trip"
> set xlabel "Person Count"
> set ylabel "Cost"
> 
> set samples 10000
> set xrange [1:30]
> set yrange [0:2000]
> set y2range [0:100]
> 
> set key left
> set xtics 1
> set ytics auto 
> set ytics nomirror
> set y2tics auto 
> set y2tics nomirror
> 
> #blah = gprintf("Gas Rate %2.2f", gas_rate)
> blah = sprintf("Hello")
> 
> set label blah at .2,.7
> 
> plot TripCostVan(x) with lines title "Vans", TripCostCar(x) with lines
> title "Cars", \
>  AdditionalCostVan(x) with lines axes x1y2 title "Additional Cost
> (Van)", \
>  AdditionalCostCar(x) with lines axes x1y2 title "Additional Cost
> (Car)", \
>  budget with lines title ""
> 
> pause -1
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Looks like a parsing problem?

[Justace C. <pro...@co...>]

Hey everybody,

	So, I have just encountered a small problem.  I usually create a
gnuplot script that can just be executed from the command line in Linux.
I do this throught the #! style.  Here is the thing though, I want to
use sprintf.  When I use sprintf in an interactive session it works
fine.  When I put this line in a script I get the following error:

gnuplot> blah = sprintf("Hello")
                        ^
         "./cost", line 54: invalid expression

	I will include the script just below so that we can see if I am missing
anything.  I am running version 4.1 patchlevel 0.  Thanks for any
information.


--------------------Script Below
#!/usr/bin/gnuplot

budget         = 1000

gas_rate       = 2.20
trip_distance  = 1400

auto_insurance = 24.95

car_mpg        = 25
car_cost       = 30 + auto_insurance
car_cap        = 4

van_mpg        = 15
van_cost       = 75 + auto_insurance
van_cap        = 9

hotel_cost     = 75
hotel_cap      = 4

NumberOfVans(x) = ceil(x/van_cap)
NumberOfCars(x) = ceil(x/car_cap)

HotelCost(x) = hotel_cost * (ceil(x/hotel_cap))
VanCost(x)   = NumberOfVans(x)*van_cost +
NumberOfVans(x)*((trip_distance/van_mpg)*gas_rate)
CarCost(x)   = NumberOfCars(x)*car_cost +
NumberOfCars(x)*((trip_distance/car_mpg)*gas_rate)

TripCostVan(x)  = HotelCost(x) + VanCost(x)
TripCostCar(x)  = HotelCost(x) + CarCost(x)

AdditionalCostVanUnbound(x) = (TripCostVan(x)-budget)/x
AdditionalCostCarUnbound(x) = (TripCostCar(x)-budget)/x

AdditionalCostVan(x) = AdditionalCostVanUnbound(x)<0 ? 1/0 :
AdditionalCostVanUnbound(x)
AdditionalCostCar(x) = AdditionalCostCarUnbound(x)<0 ? 1/0 :
AdditionalCostCarUnbound(x)

set title "Cost of the SPS Fermilab Trip"
set xlabel "Person Count"
set ylabel "Cost"

set samples 10000
set xrange [1:30]
set yrange [0:2000]
set y2range [0:100]

set key left
set xtics 1
set ytics auto 
set ytics nomirror
set y2tics auto 
set y2tics nomirror

#blah = gprintf("Gas Rate %2.2f", gas_rate)
blah = sprintf("Hello")

set label blah at .2,.7

plot TripCostVan(x) with lines title "Vans", TripCostCar(x) with lines
title "Cars", \
 AdditionalCostVan(x) with lines axes x1y2 title "Additional Cost
(Van)", \
 AdditionalCostCar(x) with lines axes x1y2 title "Additional Cost
(Car)", \
 budget with lines title ""

pause -1

Re: Help wanted: Minor *.doc -> *.tex problem

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

On Friday 01 April 2005 01:10 pm, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > The current documentation contains section headings nested
> > as deep as level 6.
>
> ... and they're all in "binary datafiles" section.  Which, IMHO,
> suggests an obvious alternative to patching up doc2tex.c: changing the
> structure of that part of the docs to make it less deeply nested.

I found the problem because I was trying to add a new section
elsewhere. Adding additional levels is the only way I know of to
break the interactive help into shorter sections and have it
prompt for additional keywords.  So it's useful in the *.gih form.
In the printed docs it is maybe not so useful.  Levels beyond
4 or 5 may not need a separate TOC number of their own.
But it would be nice to have an index at the back that catches
them. Is that possible?

> > But the conversion to *.tex (doc2tex.c) handles only levels 1-5.
>
> I don't know where you found this limitation --- it actually supports
> 1..6 as it is (6 turns into \paragraph()).  See section() in doc2tex.c,
> line 327.

It did not work in practice.  Juergen's simple change fixed it.

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

Re: Help wanted: Minor *.doc -> *.tex problem

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

On Friday 01 April 2005 23:10, Hans-Bernhard Broeker wrote:
> > But the conversion to *.tex (doc2tex.c) handles only levels 1-5.
>
> I don't know where you found this limitation --- it actually supports
> 1..6 as it is (6 turns into \paragraph()).  See section() in doc2tex.c,
> line 327.

The problem is that \subsubsubsection is an alias to \paragraph (see
toc_entry.sty).  Both level 5 and 6 were \paragraph{}s this way.


Juergen

Re: Help wanted: Minor *.doc -> *.tex problem

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

On Friday 01 April 2005 01:19 pm, Juergen Wieferink wrote:
> 
> Attached.

Thanks.  Added to cvs.

> I think it's quite distracting that both section headings and
> backquoted text get boldfaced.  Wouldn't it be nicer to have the
> latter italic?  This could be done by substituting "{\\bf " with
> "{\\em " in line 406.

I agree.  Anyone else have opinions on this?


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

Re: Help wanted: Minor *.doc -> *.tex problem

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

On Friday 01 April 2005 21:22, Ethan Merritt wrote:
> Can some TeX-savvy person contribute a patch deal with a 6th level
> of indexing and section numbering?

Attached.

> 6 edf
> ?binary general filetype edf
> ?filetype edf
> ?edf
>  `edf` is one of the automatically recognized binary file types for images.

I think it's quite distracting that both section headings and
backquoted text get boldfaced.  Wouldn't it be nicer to have the
latter italic?  This could be done by substituting "{\\bf " with
"{\\em " in line 406.


Juergen

Re: Help wanted: Minor *.doc -> *.tex problem

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

Ethan Merritt wrote:
> The current documentation contains section headings nested
> as deep as level 6.  

... and they're all in "binary datafiles" section.  Which, IMHO,
suggests an obvious alternative to patching up doc2tex.c: changing the 
structure of that part of the docs to make it less deeply nested.

 >
> But the conversion to *.tex (doc2tex.c) handles only levels 1-5.

I don't know where you found this limitation --- it actually supports 
1..6 as it is (6 turns into \paragraph()).  See section() in doc2tex.c,
line 327.

While at it, there is one thing that might be worth considering, though:
gnuplot.tex currently is an "article" --- at 181 pages, I would think 
that it's time to acknowledge reality and finally escalate that to 
"report" (which means it can have chapters, not just parts and 
sections).  If we fiddle with the defaults a bit (such that chapter 
starts don't force themselves onto a new right page), that should be 
manageable.

Help wanted: Minor *.doc -> *.tex problem

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

The current documentation contains section headings nested
as deep as level 6.  For example:

6 edf  
?binary general filetype edf
?filetype edf
?edf
 `edf` is one of the automatically recognized binary file types for images.

This is no problem for the interactive help system (doc2gih.c)
But the conversion to *.tex (doc2tex.c) handles only levels 1-5.

Can some TeX-savvy person contribute a patch deal with a 6th level
of indexing and section numbering? 

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

Re: gnuplot.texi missing postscript terminal docs

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

On Wednesday 30 March 2005 23:15, Hans-Bernhard Broeker wrote:
> That doesn't seem to address the issue of which terminals should be
> documented in the texinfo documentation.  The philosophy used to be
> that online help documents only what the accompanying gnuplot binary
> actually supports, but printable docs should document everything.
> So far, gnuplot.texi seems to have followed the "include all" strategy,
> albeit with some quirks.

I really should have read docs/README.

> You should compile the new doc2tdc.c with -DALL_TERM_DOC, I guess.

Hmm, ... actually I used to compile it with -DALL_TERM_DOC, this got
lost while rewriting the Makefile stuff. :-( But the dependencies
were there! ;-)

> > I did a quick diff on the resulting gnuplot.texi and could find two
> > major differences: The sequence of the terminal nodes has changed and
> > the cross reference detection.
>
> Erm... the cross reference detection ... did what?

Uups.  It changed its behaviour.  The the strings `windows`, `aqua`,
`epslatex`, `gif`, `ggi`, `pdf`, `jpeg`, `fig`, ... are
now detected as cross references, `postscript` is no more.  There
may be quite a lot of reasons for this.  The node naming and cross
referencing code is quite sensible to minor changes in gnuplot.doc.

AFAICS, the new gnuplot.texi is better than the old one.  The latter
had some doubled terminal entrys, some surplus quotes (") at the end
of terminal entrys, ...

Some problems with the naming of the nodes still remain.  I'm
wondering if there could be a nicer way to decide which nodes get 
trailing underscores to make their names unique.


> > I don't have too much experience with (e)lisp other than this, so it
> > would be a good idea to have this patch reviewed.  Is anyone in
> > contact with the original author of doc2texi.el?
>
> His mail address mentioned inside doc2texi.el should still work, I guess.

I'll contact him.


Juergen

Re: color box appearing for rgb plots

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

> Well, I think the above would work (sort of), but really
> an RGBIMAGE does not need a palette.

Then it is even easier -- please replace twice in pm3d.c:

if (this_3dplot->plot_style == IMAGE || this_3dplot->plot_style == RGBIMAGE)

by

if (this_3dplot->plot_style == IMAGE)

Is that OK?
BTW, there is no demo for
	splot ... with rgbimage

please try/add it.


> However, is it possible to have both an RGBIMAGE and a
> palette-based IMAGE on a plot at the same time?  If so,

Yes, it works -- I tried blutux + demo.dem (scaled down 10x).

Petr

Re: color box appearing for rgb plots

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

Petr Mikulik wrote:
>>I've compiled the latest CVS version and run the demo.  I notice
>>that in the "image.dem" demo that color boxes are now appearing
>>with RGB plots by default.  That used to be disallowed.  Everyone
>>agree that color boxes shouldn't appear for RGB (i.e., non-palette)
>>plots?
> 
> 
> I though both are IMAGE and RGBIMAGE are equivalent, thus I let them
> function in the same way.
> 
> See pm3d.c, lines 768 and 794.
> If you replace  if ( ... == IMAGE || ... == RGBIMAGE)  by
> 
> #ifdef WITH_IMAGE
> 	if (this_3dplot->plot_style == IMAGE)
>     	    return;
> 	if (this_3dplot->plot_style == RGBIMAGE) {
> 	    want_palette_but_not_colorbox = TRUE;
>     	    return;
> 	}
> #endif
> 
> does it work as you expect?
> 
> 
> Yet another question:
> Does RGBIMAGE need palette of continous colors or not?
> Thus, should plot_has_palette be TRUE or FALSE?

Well, I think the above would work (sort of), but really
an RGBIMAGE does not need a palette.

However, is it possible to have both an RGBIMAGE and a
palette-based IMAGE on a plot at the same time?  If so,
it may be the case that one should set a variable like
"has_palette" to false when starting the plot and then
set that variable to TRUE when IMAGE is created, but
don't set it to FALSE when RGBIMAGE is created.

Dan

Re: color box appearing for rgb plots

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

> I've compiled the latest CVS version and run the demo.  I notice
> that in the "image.dem" demo that color boxes are now appearing
> with RGB plots by default.  That used to be disallowed.  Everyone
> agree that color boxes shouldn't appear for RGB (i.e., non-palette)
> plots?

I though both are IMAGE and RGBIMAGE are equivalent, thus I let them
function in the same way.

See pm3d.c, lines 768 and 794.
If you replace  if ( ... == IMAGE || ... == RGBIMAGE)  by

#ifdef WITH_IMAGE
	if (this_3dplot->plot_style == IMAGE)
    	    return;
	if (this_3dplot->plot_style == RGBIMAGE) {
	    want_palette_but_not_colorbox = TRUE;
    	    return;
	}
#endif

does it work as you expect?


Yet another question:
Does RGBIMAGE need palette of continous colors or not?
Thus, should plot_has_palette be TRUE or FALSE?

---
PM

Re: color box appearing for rgb plots

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

On Thursday 31 March 2005 11:58 am, Daniel J Sebald wrote:
> I've compiled the latest CVS version and run the demo.  I notice
> that in the "image.dem" demo that color boxes are now appearing
> with RGB plots by default.  That used to be disallowed.  Everyone
> agree that color boxes shouldn't appear for RGB (i.e., non-palette)
> plots?

The last 3 changes to pm3d.c have all changed that exact same bit of
code (near line 784) in one way or another.  It may be time to step
back and re-think the logic from scratch. 


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

color box appearing for rgb plots

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

I've compiled the latest CVS version and run the demo.  I notice
that in the "image.dem" demo that color boxes are now appearing
with RGB plots by default.  That used to be disallowed.  Everyone
agree that color boxes shouldn't appear for RGB (i.e., non-palette)
plots?

Dan

Re: gnuplot.texi missing postscript terminal docs

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

Juergen Wieferink wrote:
> I think the most portable and maintainable way is to use the 
> functionality of termdoc.c to merge the terminal documentation with 
> gnuplot.doc.  I named the resulting file "gnuplot.tdc".  This file is
> then loaded by doc2texi.el.

That doesn't seem to address the issue of which terminals should be
documented in the texinfo documentation.  The philosophy used to be
that online help documents only what the accompanying gnuplot binary
actually supports, but printable docs should document everything.
So far, gnuplot.texi seems to have followed the "include all" strategy,
albeit with some quirks.

You should compile the new doc2tdc.c with -DALL_TERM_DOC, I guess.

> I did a quick diff on the resulting gnuplot.texi and could find two 
> major differences: The sequence of the terminal nodes has changed and
> the cross reference detection.

Erm... the cross reference detection ... did what?

> I don't have too much experience with (e)lisp other than this, so it 
> would be a good idea to have this patch reviewed.  Is anyone in 
> contact with the original author of doc2texi.el?

His mail address mentioned inside doc2texi.el should still work, I guess.

Please take care of conditionals...

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

Hello, everybody,

you may have noticed that I've had to fix several separate cases now of
code that assumed some optional feature was turned on, but wasn't
protected by the appropriate #ifdef. Please try to be a bit more careful
as you add code, so this doesn't turn into a regular maintenance job.

HB

Re: gnuplot.texi missing postscript terminal docs

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

On Monday 21 March 2005 20:12, Hans-Bernhard Broeker wrote:
> You may profit from a look into how allterm.h is built.  Or maybe
> combine the second half of your proposal with using allterm.h right away
> --- that might also solve the maintenance problem of yet another copy of
> the terminal list currently being hardwired inside doc2texi.el.

I think the most portable and maintainable way is to use the
functionality of termdoc.c to merge the terminal documentation with
gnuplot.doc.  I named the resulting file "gnuplot.tdc".  This file
is then loaded by doc2texi.el.

Thus doc2texi.el doesn't have to treat the terminals in a special
way (apart from two minor points: the terminal list and some change
in the hierarchy).

I did a quick diff on the resulting gnuplot.texi and could find two
major differences: The sequence of the terminal nodes has changed
and the cross reference detection.

I don't have too much experience with (e)lisp other than this, so it
would be a good idea to have this patch reviewed.  Is anyone in
contact with the original author of doc2texi.el?  Maybe he can even
find a better way to fix the (e)ps(la)tex terminal documention.

Juergen

Re: set pm3d explicit

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

> > I've just committed a patch which allows
> > 	splot x*y with pm3d
> > anytime. Thus, "set pm3d explicit" is on after gnuplot startup and after
> > 'reset'.
>
> Sounds good.
> Are you going to do the same for "set contour"?

No, contours are black magic for me.

BTW,
set contours base
splot x*y with pm3d
... "clabels" remain

splot x*y with pm3d at C
... this (undocumented) filled contours would require all contours to be
closed.

Well, it really looks like "splot with contour" or "splot {no}contour" be
useful.


---
PM