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

Re: bug in palette routine?

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

>> Attached is a patch to fix this bug.  It uses a bisecting method.  Please 
>> check it over and test it.  You'll find that the imshow(A,A,A) now works 
>> but doesn't look to be the correct brightness.  We'll address that problem 
>> next.

OK, now the patch, gnuplot does not crash.

On the other hand, it shows the following garbage:

octave|3> A = loadimage ("default.img");
octave|4> imshow(A,A,A);
gnuplot_x11: unknown command 
<.'.'.'<.<.<.>/>/>/$@0@0@0,@0@0@03@0@0@0;@0@0@0C@p@p@pJ@p@p@pR@p@p@pZ?p?p?pb>o>o>oi<n<n<nq9m9m9my:m:m:m:m:m:m8l8l8l8l8l8l9,9,9,9m9m9m
>
gnuplot_x11: unknown command 
<@0@0@0@0@0@0@p@p@p!@p@p@p)@p@p@p1@p@p@p8@p@p@p@@0@0@0H?p?p?pP>o>o>oW:-:-:-_;-;-;-g;n;n;no:-:-:-v9,9,9,~8l8l8l8l8l8l*e*e*e*%*%*%)$)$)$%(d(d(d,)$)$)$4'd'd'd<($($($D&c&c&cK'd'd'dS'#'#'#[&c&c&cc'd'd'dj'd'd'dr'd'd'dz(d(d(d(d(d(d($($($'d'd'd($($($($($($('#'#'#0&c&c&c8'#'#'#?&c&c&cG'#'#'#O'd'd'dV'#'#'#^'d'd'df'#'#'#n&c&c&cu%c%c%c}($($($*%*%*%
>
gnuplot_x11: unknown command 
<.'.'.'<.<.<.>/>/>/$@0@0@0,@0@0@03@0@0@0;@0@0@0C@p@p@pJ@p@p@pR@p@p@pZ?p?p?pb>o>o>oi<n<n<nq9m9m9my:m:m:m:m:m:m8l8l8l8l8l8l9,9,9,9m9m9m
>
octave|5>



> Oh, btw, I made the patch behave similar to the existing routine in that it 
> rounds up, like a ceil() function.  I didn't look closely, but perhaps you'd 
> like the routine to be round(), unless that's been compensated for somewhere 
> else already.

I have no idea what you mean. But it does not matter, please send me the 
patch as close as to the "traditional" octave or Matlab behaviour as 
possible.

Petr

Re: bug in palette routine?

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

Daniel J Sebald wrote:

> Attached is a patch to fix this bug.  It uses a bisecting method.  
> Please check it over and test it.  You'll find that the imshow(A,A,A) 
> now works but doesn't look to be the correct brightness.  We'll address 
> that problem next.

Oh, btw, I made the patch behave similar to the existing routine in that it rounds up, like a ceil() function.  I didn't look closely, but perhaps you'd like the routine to be round(), unless that's been compensated for somewhere else already.

Dan

bug in palette routine?

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

Petr,

I'm having problems plotting an image via

imshow(r,g,b)

in Octave.  There may be multiple bugs and I can't seem to reproduce things exactly in pure gnuplot, even using the files that Octave creates.

It began in a case where image(r,g,b) worked OK in x11, but not with the postscript terminal.  The bug was causing gnuplot to crash.

In Octave, currently, image(r,g,b) is done using a palette as opposed to true color.

I think it is too difficult to describe what I did for that, but then I started sniffing around and found this:  In octave type (with x11 terminal)

A = loadimage ("default.img");
image(A);      # no problem
imshow(A,A,A); # I see a crash
image(A);      # continues to crash
imshow(A);     # seems to fix problem
image(A);      # works again

I think I have traced this bug to the routine interpolate_color_from_gray().  To verify this, replace the couple commands:

    /* find index, bisecting would be faster */
    for (idx = 0; sm_palette.gradient[idx].pos < gray; ++idx)
	; /* do nothing */

with

    /* find index, bisecting would be faster */
    for (idx = 0; sm_palette.gradient[idx].pos < gray; ++idx)
//	; /* do nothing */
if (idx == maxidx)
fprintf(stderr,"interp 2, %d %d\n", maxidx, idx);

fprintf(stderr,"interp 3, %d %d\n", maxidx, idx);

and you will see that when imshow(A,A,A) is issued in Octave idx = maxidx, which is one beyond the limits of the array and the next fprintf("interp 3") doesn't execute.

Attached is a patch to fix this bug.  It uses a bisecting method.  Please check it over and test it.  You'll find that the imshow(A,A,A) now works but doesn't look to be the correct brightness.  We'll address that problem next.

Thanks,

Dan

gnuplot manual misprint (no.18)

[Shigeharu T. <sh...@ie...>]

shige 02/20 2006
----------------

In docs/gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.343 2006/02/07 04:27:27 sfeam Exp $

and term/post.trm

 * $Id: post.trm,v 1.170 2006/02/12 22:19:36 mikulik Exp $

I found some points that seem to be misprints. I send the unified
diff file for them.

----- From here -----
diff -u docs/gnuplot.doc~ docs/gnuplot.doc
--- docs/gnuplot.doc~	Wed Feb  8 15:20:46 2006
+++ docs/gnuplot.doc	Mon Feb 20 12:53:19 2006
@@ -6041,7 +6041,7 @@
  affects 3D plotting styles `with points`, `with labels`, and `with vectors`,
  even if no surface is present in the graph.  Individual plots within the
  graph may be explicitly excluded from this processing by appending the extra
- option `nohidden` to the `with` specifier.
+ option `nohidden3d` to the `with` specifier.
 
  Functions are evaluated at isoline intersections.  The algorithm interpolates
  linearly between function points or data points when determining the visible
@@ -7333,7 +7333,7 @@
  color each quadrangle appropriately. For data files, this will smoothen the
  color surface, and enhance spikes in a color surface. For functions,
  interpolation makes little sense, except to trade off precision for memory.
- It would usually make more sense to use 'samples' and 'isosamples' when working
+ It would usually make more sense to use `samples` and `isosamples` when working
  with functions.
 
  The coloring setup as well as the color box drawing are determined by
diff -u term/post.trm~ term/post.trm
--- term/post.trm~	Mon Feb 20 12:55:19 2006
+++ term/post.trm	Mon Feb 20 12:56:20 2006
@@ -4109,7 +4109,7 @@
 " errors but, rather, display a message or a PostScript Level 1 approximation.",\
 " The `level1` option substitutes PostScript Level 1 approximations of these",\
 " features and uses no PostScript Level 2 code.  This may be required by some",\
-" old printers and old versions of Adobe Illustrator.  The flag `Level1` can be",\
+" old printers and old versions of Adobe Illustrator.  The flag `level1` can be",\
 " toggled later by editing a single line in the PostScript output file to force",\
 " PostScript Level 1 interpretation.  In the case of files containing level 2",\
 " code, the above features will not appear or will be replaced by a note when",\

----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: gnuplot cvs does not compile

[Munteanu A. <io_...@ya...>]

On Sat, Feb 18, 2006 at 06:14:19PM +0100, Munteanu Alexandru wrote:
> Hello,
>=20
> I was trying to compile gnuplot from CVS and I have the following
> error :
>=20
>  make[3]: Entering directory `/mnt/personal/hacking/gnuplot/src'
>=20
>  gcc  -I/home/ion/progs/include  -L/home/ion/progs/lib  -o gnuplot
>  alloc.o axis.o bin_hook.o breaders.o bitmap.o color.o command.o
>  contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o
>  graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o
>  matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o
>  readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o
>  tables.o term.o time.o unset.o util.o util3d.o variable.o version.o
>  -lz -lgd  -ljpeg -lfreetype -lpng  -lm
>=20
>  term.o: In function `image_do_crop':term.c:(.text+0x25c7d): undefined
>  reference to `gdImageColorAllocateAlpha'
> =20
>  collect2: ld returned 1 exit status
>=20
> Hope this helps making gnuplot more stable.
>=20
> If you solve this bug, please send me a mail if you have the
> time. (with my mail on To: and gnuplot mailing list to Cc for example
> because I'm not suscribed to the list)
>=20
> Thank you.
>=20

I have solved the problem. I had to install libgd2 developement
libraries instead of libgd1.
This should be easy to fix I think (cheching in configure.in for
libgd2 instead of libgd)

--=20
Munteanu Alexandru Ionut <io_alex_2002 @no_spam@ yahoo.fr>

gnuplot cvs does not compile

[Munteanu A. <io_...@ya...>]

Hello,

I was trying to compile gnuplot from CVS and I have the following
error :

 make[3]: Entering directory `/mnt/personal/hacking/gnuplot/src'

 gcc  -I/home/ion/progs/include  -L/home/ion/progs/lib  -o gnuplot
 alloc.o axis.o bin_hook.o breaders.o bitmap.o color.o command.o
 contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o
 graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o
 matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o
 readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o
 tables.o term.o time.o unset.o util.o util3d.o variable.o version.o
 -lz -lgd  -ljpeg -lfreetype -lpng  -lm

 term.o: In function `image_do_crop':term.c:(.text+0x25c7d): undefined
 reference to `gdImageColorAllocateAlpha'
=20
 collect2: ld returned 1 exit status

Hope this helps making gnuplot more stable.

If you solve this bug, please send me a mail if you have the
time. (with my mail on To: and gnuplot mailing list to Cc for example
because I'm not suscribed to the list)

Thank you.

--=20
Munteanu Alexandru Ionut <io_alex_2002 @no_spam@ yahoo.fr>

Re: line corners with terminals for vector graphics

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

> However, exactly at this point (filled_polygon, trickery with
> palettes, ...) proper documentation for current functionality is
> missing.

See src/README and term/README.

> but I'm a bit lost.

then you must investigate the code itself

> PostScript terminal uses some "cryptic code" for patterns, palettes,
> ... that is not documented anywhere else.

Read postscript reference book(s).

> For example, there's exactly only one place where "previous_palette" is 
> called. PostScript does only "grestore" and the source states that the 
> command could probably be dropped since no other terminal is using it.

This API was needed in 1998 when I wrote the pm3d code.

> Is PostScript "the" reference of how the functions are to be
> implemented in other terminals? Or who could help me with further
> suggestions what the "fill_polygon" and palette switching functions
> are supposed to do exactly?

You have to enjoy playing with the source code yourself.

---
PM

Re: line corners with terminals for vector graphics

[Mojca M. <moj...@gm...>]

On 2/8/06, Petr Mikulik wrote:
> > This makes the grid "finer", but not smooth.
> >
> > PostScript (and PDF) support smooth shading, which means that you can
> > only define a color in the corners and PostScript will take care for
> > "pixels" in the middle.
>
> Wasn't this question discussion during the OpenGL driver? It is a bit
> similar (colors for vertices). Aha, not the question here, since we are i=
n
> 2D projections, not in 3D coordinats.
>
> It would need to add
>         float r,g,b;
> into the definition of gpiPoint.
>
> Then there are these possibilities:
> 1. Add also
>         int fade_color
>     into gpiPoint. Then
>         void XX_filled_polygon (int points, gpiPoint *corners)
>     won't change.
> 2. Change
>          void XX_filled_polygon (int points, gpiPoint *corners, t_fade *f=
ade)
>     The last new param will be ignored by most terminals.
> 3. As term->set_color() is called before each term->filled_polygon(),
>     the fading option could be passed at this point.
>
> It is probably not difficult to implement. You can have a nice play.

The proper color should probably be calculated first for each point as well=
.

Thans a lot for the guidelines. If nobody else is willing to
investigate, I'll try to finish the new terminal first before starting
to dig into this, so that I get some experience first.

However, exactly at this point (filled_polygon, trickery with
palettes, ...) proper documentation for current functionality is
missing. ConTeXt is able to do many things (not "grestore" however,
but this can be done in many other ways), but I'm a bit lost.
PostScript terminal uses some "cryptic code" for patterns, palettes,
... that is not documented anywhere else. For example, there's exactly
only one place where "previous_palette" is called. PostScript does
only "grestore" and the source states that the command could probably
be dropped since no other terminal is using it.

Is PostScript "the" reference of how the functions are to be
implemented in other terminals? Or who could help me with further
suggestions what the "fill_polygon" and palette switching functions
are supposed to do exactly?

(sorry for going off-topic in this thread)

Mojca

Re: post.trm image max colors patch

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

> Attached is a bug fix for the PostScript image using the five operand form 
> (i.e., no palette).  The bug was that the max colors was not set to 2^N, 
> where N is 1, 2, 4, 8, or 12.  So if the gray scale max was 128 (2^7) the 
> brightness was lower than it should have been.

The patch seems OK for me.

---
PM

Re: "where's" my line

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

> 1 0.5
> 9 0.5
>
> Then try the following from gnuplot's command line:
>
> gnuplot> set xrange [0:10]
> gnuplot> plot sin(x), 'data.dat' with line
>
> There's a green line.  Now
>
> gnuplot> set xrange [2:8]
> gnuplot> replot
>
> and there's no green line anymore.  Shouldn't there be a line visible?

Try "set clip two".

---
PM

"where's" my line

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

In data file 'data.dat' put the lines

1 0.5
9 0.5

Then try the following from gnuplot's command line:

gnuplot> set xrange [0:10]
gnuplot> plot sin(x), 'data.dat' with line

There's a green line.  Now

gnuplot> set xrange [2:8]
gnuplot> replot

and there's no green line anymore.  Shouldn't there be a line visible?

Dan

Re: post.trm image max colors patch

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

Daniel J Sebald wrote:

> The EPS appears too dark without the patch when maxcolors is 2 4 16 256 
> or 4096.

That should be NOT 2 4 16 256 or 4096.

Dan

Re: post.trm image max colors patch

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

Ethan Merritt wrote:
> On Thursday 09 February 2006 09:44 pm, Daniel J Sebald wrote:
> 
>>Attached is a bug fix for the PostScript image using the five operand
>>form (i.e., no palette).  The bug was that the max colors was not set
>>to 2^N, where N is 1, 2, 4, 8, or 12.  So if the gray scale max was
>>128 (2^7) the brightness was lower than it should have been.
> 
> 
> Could you please provide a demo script that shows the difference
> between before/after this patch?

Sure, from the demo directory:

set palette gray maxcolors 128
plot 'blutux.rgb' binary array=128x128 flipy format='%uchar%uchar%uchar' using ($1+$2+$3)/3 with image
set output
set term post monochrome eps
set output 'test.eps'
replot
set output
# To illustrate other terms work
set term png
set output 'test.png'
replot
set output

The EPS appears too dark without the patch when maxcolors is 2 4 16 256 or 4096.

Dan

Re: post.trm image max colors patch

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

On Thursday 09 February 2006 09:44 pm, Daniel J Sebald wrote:
> Attached is a bug fix for the PostScript image using the five operand
> form (i.e., no palette).  The bug was that the max colors was not set
> to 2^N, where N is 1, 2, 4, 8, or 12.  So if the gray scale max was
> 128 (2^7) the brightness was lower than it should have been.

Could you please provide a demo script that shows the difference
between before/after this patch?

	thanks,

		Ethan

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

post.trm image max colors patch

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

Attached is a bug fix for the PostScript image using the five operand form (i.e., no palette).  The bug was that the max colors was not set to 2^N, where N is 1, 2, 4, 8, or 12.  So if the gray scale max was 128 (2^7) the brightness was lower than it should have been.

Dan

Re: Bugs in new key placement code

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

Petr Mikulik wrote:

>> I think this is the more difficult task that Hans refers to: making 
>> that axes annotation look good in all views.
> 
> 
> I wish a much simpler task: the box of "set border 4095" rotates within 
> the bounding box adjustable by "set Xmargin". Ignore labels as tics for 
> this size -- exactly as "set Xmargin" in 2D.

I understand.  That's what I'd like too.

Dan

Re: Gnuplot - FAQ

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

Gerd Heinz wrote:

[Erm, two side notes: 1) usage questions don't really belong in this 
mailing list.  We have a USENET group and the -info mailing list for 
that.  2) Please try to find a more meaningful Subject: next time...]

> set terminal emf monochrome  'Times Roman Italic' 14 	
> # windows enhanced metafile für Word, vector-format
> set output "gnuplot.emf"
> replot

Please don't forget to 'set output' (without file name) after this, and 
before you try to do anything with the generated file.  Always close 
your file before you open it in another program.

> but it is terrible, if you use small sizes for small drawings
> set size .5,.5

I don't think anybody can help you much with that, if you aren't more 
specific about what is so "terrible" about this.  You may want to 
re-think the choices font and size.  Drawing all text in the plot in 
Italic hardly seems a good idea, in terms of readability, and size 14 
may be a bit too large for such a small plot.

Re: Bugs in new key placement code

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

Petr Mikulik wrote:
>> 1) add more 'coordinate' classes for 3D plots, if only for debugging. 
>> We need commands like
>>
>>     set arrow from view 0,0,0 to view 1,1,1  # 'camera' coordinates
>>     set arrow from canvas 0,0 to canvas 1,1  # the 'plot_boundary'
> 
> Aha, there is no coordinate system for the bounding rectangle of the 3D?
> Do we need it?

I think so.  It would certainly help us in modifying the layout code, 
and it could be useful for users, too.  A 3D plot has more separate 
coordinate systems than a 2D one, but we only offer coordinate systems 
for those that also exist in 2D.

> This looks like a bug:
>     set arrow 1 from graph 0,0,0 to graph 1,1,1
>     splot x*y
>     pause -1
>     set view map
>     replot
>     pause -1
>     plot x
> 
> I would expect a line in another diagonal.

Well, I did point out that the 'set view map' implementation is an 
unholy mess, didn't I?

>> 2) Extend boundary3d(): add handling for the other 3 margins, 'set 
>> offsets', and completely re-think space reservations for ticks, 
>> ticklabels, and axis labels.
> 
> You mean 'set margins'? I think this is the most easy and helpful fix. 
> This would allow to scale down the 3D plot area manually in order to 
> allow enough space for the color box when needed.

Scaling it further down isn't exactly the most pressing need, IMHO.  The 
real problem are horrors like 'set view ,,1.3' many people use in an 
attempt to scale *up* the 3D plot area.  The notion that 3D plots were 
not utilizing enough of the available space was a good part of the 
motivation of 'set view map', and look where that got us.


> 
> ---
> PM
> 

Re: Bugs in new key placement code

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

> because of the viewing angle.  But the default view angle should at least 
> look pretty good.
>
> [I seem to recall the color box was at one time drawn in the plot coordinates 
> and used to rotat around with the graph.  Remember that?]

All views, as you get by mouse rotations, should look good.

> Then replot the 3d example after
>
> set xlabel 'xlabel'
> set ylabel 'ylabel'
> set zlabel 'zlabel'
>
> Again, for some viewing angles the text is way out further than it need be. 
> [And if you could draw the axis labels using rotated text, you might have a 
> real winner.]
>
> I think this is the more difficult task that Hans refers to: making that axes 
> annotation look good in all views.

I wish a much simpler task: the box of "set border 4095" rotates within the 
bounding box adjustable by "set Xmargin". Ignore labels as tics for this 
size -- exactly as "set Xmargin" in 2D.

How to prove it: "set l+r+b+t margin 0",  "set border 4095" , and the box is 
tighly inside the graphics window for any rotation by mouse.

---
PM

Gnuplot - FAQ

[Gerd H. <he...@gf...>]

Ladies and Gentlemen,

as a friend of gnuplot I have a question:

"Using Microsofts Word - how can I import small vector plots in the best
way, so that I can edit it as drawing?"

I'm using something like that:

set terminal emf monochrome  'Times Roman Italic' 14 =09
# windows enhanced metafile f=FCr Word, vector-format
set output "gnuplot.emf"
replot

but it is terrible, if you use small sizes for small drawings
set size .5,.5

Thanks for your attention.

Gerd Heinz
Berlin

Re: Bugs in new key placement code

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

Petr Mikulik wrote:
>> Sure.  boundary3d() can use a lot of improvement.  Only question is: 
>> do this incrementally, risking an end state that is a rather tangled 
>> mess, or allow someone the time to really work on this, and get it 
>> _right_?
> 
> 
> Fixing the most obvious "bugs" (=missing functionality) now.

Easier and more obvious, but still would require significant file restructure.

> 
>> 1) add more 'coordinate' classes for 3D plots, if only for debugging. 
>> We need commands like
>>
>>     set arrow from view 0,0,0 to view 1,1,1  # 'camera' coordinates
>>     set arrow from canvas 0,0 to canvas 1,1  # the 'plot_boundary'
> 
> 
> Aha, there is no coordinate system for the bounding rectangle of the 3D?
> Do we need it?
> 
> This looks like a bug:
>     set arrow 1 from graph 0,0,0 to graph 1,1,1
>     splot x*y
>     pause -1
>     set view map
>     replot
>     pause -1
>     plot x
> 
> I would expect a line in another diagonal.

Looks like a bug.  In 3d space the arrow goes from -10,-10 to 10,10.  So, unless map is something quite different from 3d, the project seems wrong.

> 
>> 2) Extend boundary3d(): add handling for the other 3 margins, 'set 
>> offsets', and completely re-think space reservations for ticks, 
>> ticklabels, and axis labels.
> 
> 
> You mean 'set margins'? I think this is the most easy and helpful fix. 
> This would allow to scale down the 3D plot area manually in order to 
> allow enough space for the color box when needed.

I think he means the spacing along the axes margins, which as Ethan pointed out, are very different than the canvas margins.  The example you gave above, if one looks at the tick mark text in some cases it overlaps with the axes line and doesn't look good.  Sure, in some cases this is difficult to avoid because of the viewing angle.  But the default view angle should at least look pretty good.

[I seem to recall the color box was at one time drawn in the plot coordinates and used to rotat around with the graph.  Remember that?]

Then replot the 3d example after

set xlabel 'xlabel'
set ylabel 'ylabel'
set zlabel 'zlabel'

Again, for some viewing angles the text is way out further than it need be.  [And if you could draw the axis labels using rotated text, you might have a real winner.]

I think this is the more difficult task that Hans refers to: making that axes annotation look good in all views.

Dan

Re: Bugs in new key placement code

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

> Sure.  boundary3d() can use a lot of improvement.  Only question is: do this 
> incrementally, risking an end state that is a rather tangled mess, or allow 
> someone the time to really work on this, and get it _right_?

Fixing the most obvious "bugs" (=missing functionality) now.

> 1) add more 'coordinate' classes for 3D plots, if only for debugging. We need 
> commands like
>
> 	set arrow from view 0,0,0 to view 1,1,1  # 'camera' coordinates
> 	set arrow from canvas 0,0 to canvas 1,1  # the 'plot_boundary'

Aha, there is no coordinate system for the bounding rectangle of the 3D?
Do we need it?

This looks like a bug:
 	set arrow 1 from graph 0,0,0 to graph 1,1,1
 	splot x*y
 	pause -1
 	set view map
 	replot
 	pause -1
 	plot x

I would expect a line in another diagonal.

> 2) Extend boundary3d(): add handling for the other 3 margins, 'set offsets', 
> and completely re-think space reservations for ticks, ticklabels, and axis 
> labels.

You mean 'set margins'? I think this is the most easy and helpful fix. This 
would allow to scale down the 3D plot area manually in order to allow enough 
space for the color box when needed.

---
PM

Re: Bugs in new key placement code

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

Petr Mikulik wrote:
> Thus, there exists a bounding rectangle of that ellipse/circle. This 
> could be manipulated by all of the set margin's, not only the lmargin. 
> Isn't this functionality feasible to add?

Sure.  boundary3d() can use a lot of improvement.  Only question is: do 
this incrementally, risking an end state that is a rather tangled mess, 
or allow someone the time to really work on this, and get it _right_?

Things that really need doing in this area:

1) add more 'coordinate' classes for 3D plots, if only for debugging. 
We need commands like

	set arrow from view 0,0,0 to view 1,1,1  # 'camera' coordinates
	set arrow from canvas 0,0 to canvas 1,1  # the 'plot_boundary'

to analyze what actually goes on in 3D layout.  The main problem with 
the current layout is that even among us, the developers, nobody really 
knows what goes where, and why, in 3D, because none of the relevant 
boundaries can easily be displayed on the plot.

2) Extend boundary3d(): add handling for the other 3 margins, 'set 
offsets', and completely re-think space reservations for ticks, 
ticklabels, and axis labels.

3) Completely re-do the implementation of 'set view map', getting rid of 
temporary overrides of 'set' values for ranges, reverse states etc.  The 
number of places the value of splot_map is checked is well beyond the 
acceptable.  We've been piling band-aids upon kludges upon hacks to 
implement this feature.  That has to stop.

4) get rid of the internal surface_scale variable and all it entails. 
Obsolete <scale> parameter in 'set view', achieve its effect in other ways.

5) same as 4), for surface_scale_z --- that one's just plain wrong.

6) While at it, add point-perspective projection.

Re: Bugs in new key placement code

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

> The 3D plots do have such a border.  Its real shape is not a rectangle, 
> though. It's an ellipse, inside which the plot can take different
> orientations according to 'set view'.
>
> actual area occupied by the data is a circle enscribed into the
> plot_boundary rectangle.  This is the rectangle filled with data in
> 'set view 0,0,1,1' splots.  In other orientations, some parts of

Thus, there exists a bounding rectangle of that ellipse/circle. This could 
be manipulated by all of the set margin's, not only the lmargin. Isn't this 
functionality feasible to add?

---
PM

'set view' zscale (was: Re: Bugs in new key placement code)

[Jonathan T. <jt...@ae...>]

On Wed, 8 Feb 2006, Hans-Bernhard Bröker wrote:
> That style of zooming (the <zscale> parameter of 'set view', really) is a 
> horrible hack, period.  If ever we get a chance to do it, I strongly suggest 
> we kill that feature and be done with it.

Please don't do that (at least not without replacing it with equivalent
functionality elsewhere)!  This parameter is ++useful to me, both for
day-to-day interactive use of gnuplot, for movies (with perl scripts
generating gnuplot commands to produce each frame), and for final
publication-quality figures.

ciao,

-- 
-- Jonathan Thornburg <jt...@ae...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam