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

Subject: Re: Bug in PostScript arrows [ was Re: Updated HTML version of demo scripts now on SourceForge

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

> > I don't see any dashes, but yes - Arrow styles 1,3,4, and 5 in the demo
> > produce arrowheads only, with no shaft.
> >
> > I wonder when this broke, and what broke it?
>
> Found it.
> It was broken by a patch from Mar 2003 that removed PS_FLUSH_PATH
> from the start of PS_filled_polygon(). ChangeLog says:
>
> 2003-03-22  Petr Mikulik  <mi...@ph...>
>         * term/post.trm(PS_filled_polygon): Don't call PS_FLUSH_PATH but reset
>         ps_path_count instead (flush is automatic). Fixes broken pm3d map
>         layout (required by pm3dConvert*.awk scripts) due to "stroke\n" in
>         PS_FLUSH_PATH.
>
> Restoring the PS_FLUSH_PATH in post.trm would fix the current problem.
>
> Petr:
>
>     Can you re-examine the problem with the awk scripts?  Because it
> seems that the flush is in fact needed here.   It is not correct that the
> flush of the previous element is automatic.  Without an explicit "stroke"
> command, any line followed immediately by a filled polygon is never drawn.

As I remember, my patch fixed broken filled objects -- pm3d and
filledcurves. This gnuplot-automatic "stroke" made the stroke before
"closepath" or "fillpath" operators thus coloring only parts of (some?
large?) filled objects. "stroke" can be used after "{close|fill}path"
(but it is not necessary I think).

As a test, try "set pm3d map; splot x" (or "splot y") (maybe adjust
sampling) with output to a color postscript file, pass it through
pm3dConvert....awk script and see whether it is OK in ghostview.

Also with some of "plot ... with filledcurves".

---
Petr Mikulik

Re: color box positioning for splot

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

I don't have time to modify and test a quick fix for the colorbox. 
 However, looking at the code I can give a suggestion of what to try. 
 In the 2D plot and 3D plot seems to be common _global_ variables 
xright, xleft, ybot, ytop.  When the 2D plot borders are drawn, the 
vectors are based directly on these variables.  My guess is that for 3D 
plots these same variables (which currently seem to be modified 
accordingly) serve a similar purpose of being the general view extent of 
the 3D axes.  So, in the draw_smooth_color_box() routine, try basing the 
computation of the color box extent on xright, xleft, ybot, ytop rather 
than using the plot axes values and projecting via map3d_xy().  To me, 
that projection seems like extra, unneeded effort if the plot extent 
information is already given in xright, etc.

After you (whoever wants to try this) do that, if you want to try 
touching things up find the last location in graph3d.c where xright, 
etc. are set equal to some value then make an adjustment based upon the 
position of the color box.  For example, in the image patch is the 
adjustment

#ifdef WITH_IMAGE
#ifdef PM3D
#define COLORBOX_SCALE 0.125
#define WIDEST_COLORBOX_TICTEXT 3
    /* Make room for the color box if it will be seen for the IMAGE plot 
style. */
    if ((plots->lp_properties.use_palette) && (color_box.where != 
SMCOLOR_BOX_NO) && (color_box.where != SMCOLOR_BOX_USER)) {
        xright -= (int) (xright-xleft)*COLORBOX_SCALE;
        xright -= (int) ((t->h_char) * WIDEST_COLORBOX_TICTEXT);
    }
#endif
#endif

You'll notice this is only a temporary addition to the image patch 
because I was hoping in the future it could be made nicer and common 
between 2D and 3D plots.  The above is only for right, vertical 
placement.  (Bottom would modify ybot, left would modify xleft, top 
would modify ytop.)  In the future it would be nice to support right 
vertical, left vertical, bottom horizontal, top horizontal.  Also, in 
the future it would be nice to easily control the colorbox by specifying 
the width (i.e., the COLORBOX_SCALE in the code above) as a percentage 
of the overall plot.  In the above example the color box area is 12.5% 
of the overall plot width for a vertical colorbox.

Dan


Petr Mikulik wrote:

>>>OK, so you are saying the rotating colorbox in 3D is embarrassing enough
>>>to warrant a quick fix.  :-)
>>>      
>>>
>
>  
>
>>Not quite --- it's Petr who wants this quick fix.
>>    
>>
>
>Exactly, I want just a simple, easy and trivial fix to replace "my"
>numbers of auto positioning the 3D colorbox by "somebody else"'s
>numbers/funciton so that when rotating splot by mouse it does not circulate
>around. Otherwise, this will be immediatly a FAQ (tested on other people).
>
>It don't want to touch any other code else -- yes, we had a discussion about
>colorbox positioning with Daniel, but that's not relevant to this issue.
>
>Unfortunately, I don't have time to understand these transformations and
>implement my requested feature. Hans-Bernhard, could you please try this?
>Otherwise, it will be let as is.
>
>---
>Petr Mikulik
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: color box positioning for splot

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

Petr Mikulik wrote:

>>>OK, so you are saying the rotating colorbox in 3D is embarrassing enough
>>>to warrant a quick fix.  :-)
>>>      
>>>
>
>  
>
>>Not quite --- it's Petr who wants this quick fix.
>>    
>>
>
>Exactly, I want just a simple, easy and trivial fix to replace "my"
>numbers of auto positioning the 3D colorbox by "somebody else"'s
>numbers/funciton so that when rotating splot by mouse it does not circulate
>around. Otherwise, this will be immediatly a FAQ (tested on other people).
>

No doubt.  If this were a commercial product, the appropriate industry 
idiom would be "show stopper".

Dan

Re: color box positioning for splot

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

>> OK, so you are saying the rotating colorbox in 3D is embarrassing enough
>> to warrant a quick fix.  :-)

> Not quite --- it's Petr who wants this quick fix.

Exactly, I want just a simple, easy and trivial fix to replace "my"
numbers of auto positioning the 3D colorbox by "somebody else"'s
numbers/funciton so that when rotating splot by mouse it does not circulate
around. Otherwise, this will be immediatly a FAQ (tested on other people).

It don't want to touch any other code else -- yes, we had a discussion about
colorbox positioning with Daniel, but that's not relevant to this issue.

Unfortunately, I don't have time to understand these transformations and
implement my requested feature. Hans-Bernhard, could you please try this?
Otherwise, it will be let as is.

---
Petr Mikulik

Re: Bug in PostScript arrows [ was Re: Updated HTML version of demo scripts now on SourceForge

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

On Saturday 13 December 2003 04:39 pm, Ethan A Merritt wrote:
> On Saturday 13 December 2003 10:35 am, Daniel J Sebald wrote:
> > I noticed that the postscript output for the 'arrowstyle.dem' demo is
> > missing some lines for only some of the arrows and also some of the
> > arrowheads have dashed lines in them, but not all.  Anyone else see this?
>
> I don't see any dashes, but yes - Arrow styles 1,3,4, and 5 in the demo
> produce arrowheads only, with no shaft.
>
> I wonder when this broke, and what broke it?

Found it.
It was broken by a patch from Mar 2003 that removed PS_FLUSH_PATH
from the start of PS_filled_polygon(). ChangeLog says:

2003-03-22  Petr Mikulik  <mi...@ph...>
        * term/post.trm(PS_filled_polygon): Don't call PS_FLUSH_PATH but reset
        ps_path_count instead (flush is automatic). Fixes broken pm3d map
        layout (required by pm3dConvert*.awk scripts) due to "stroke\n" in
        PS_FLUSH_PATH.

Restoring the PS_FLUSH_PATH in post.trm would fix the current problem.

Petr:

    Can you re-examine the problem with the awk scripts?  Because it
seems that the flush is in fact needed here.   It is not correct that the 
flush of the previous element is automatic.  Without an explicit "stroke"
command, any line followed immediately by a filled polygon is never drawn.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: color box positioning for splot

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

On Sat, 13 Dec 2003, Daniel J Sebald wrote:

> Exactly.  I think this is what got me looking into margins, not only on 
> the X11 displays but also the PSLaTeX output.  There doesn't need to be 
> such a big margin there, UNLESS it has something to do with allowing 
> enough room so that rotating the image doesn't cause a different view of 
> the 3D graph to extend off the screen.  

I think that's what the original reason for that magic factor of 4/7 is
--- but there doesn't seem to be anybody left whom we could ask if that's
actually the case.  The only real hint so far was that 4/7 is pretty close
to 1/sqrt(3), the relevant factor that would achieve this.

> This could be the issue with why PSLaTeX doesn't work.  It might be
> basing its margins and background on the original 3D graph and not the
> rotated.  Consequently, it cuts off some of the graph.

The pslatex driver is rather a separate issue from that of screen usage by
3D plots.  The basic problem is that the bounding box output by all our
postscript drivers depends only on 'set size' (but not the ratio!) and
'set origin', which doesn't really describe the 3D plots well.

> Well, get rid of the large margins and adjust them based upon the 
> presence of a colorbox.  There's the solution.  

Getting rid of them may not be quite that simple.  In the effect, you'ld
have to change the actual size of the 'page' ex post, just like 'set size
ratio -number' now does it, and with all the ugly problems that creates
for the postscript bounding box, among others.

I suspect we have yet another missing terminal API capability on our
hands, here.  There's no way for the core code to tell the terminal driver
that it decided it wouldn't use all of the page size the driver offers.  
That's the *real* reason why the bounding boxes are usually wrong in 'set
size square -1' and 3D plots.  The driver peeking into the xsize and 
xoffset global variables used by the core is really an ugly kludge.

> OK, so you are saying the rotating colorbox in 3D is embarrassing enough 
> to warrant a quick fix.  :-)

Not quite --- it's Petr who wants this quick fix.  I just tried to provide
him (or whoever volunteers to do it) with the necessary insights on the
workings of our 3D code, since he expressed he couldn't seem to find out
how to actually do it.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Bug in PostScript arrows [ was Re: Updated HTML version of demo scripts now on SourceForge

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

On Saturday 13 December 2003 10:35 am, Daniel J Sebald wrote:
> I noticed that the postscript output for the 'arrowstyle.dem' demo is
> missing some lines for only some of the arrows and also some of the
> arrowheads have dashed lines in them, but not all.  Anyone else see this?

I don't see any dashes, but yes - Arrow styles 1,3,4, and 5 in the demo
produce arrowheads only, with no shaft.

I wonder when this broke, and what broke it?

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Updated HTML version of demo scripts now on SourceForge

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

Ethan A Merritt wrote:

>I wrote a perl script to auto-generate a web page for each gnuplot demo 
>script.  The perl script itself is now in the CVS tree as demo/webify.pl
>I used it to create web pages for almost all of the current demos.
>They are on
>	http://gnuplot.sourceforge.net/demo/
>
>There were some problems with the pm3d.dem run, and the
>vector.dem run didn't work at all.
>

Oooo, nice.  Very impressive.

...

I noticed that the postscript output for the 'arrowstyle.dem' demo is 
missing some lines for only some of the arrows and also some of the 
arrowheads have dashed lines in them, but not all.  Anyone else see this?

Dan

Re: color box positioning for splot

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

Hans-Bernhard Broeker wrote:

>On Fri, 12 Dec 2003, Daniel J Sebald wrote:
>[...]
>
>  
>
>>If you ask me, even without doing a rotation, the graph just doesn't
>>look right.
>>    
>>
>
>That's mainly a question about *where* the color box gets put, then, not
>how the 'view' setting affects its placement, but shouldn't.  That didn't
>appear to be covered by Petr's question.  Maybe you discussed so much in
>private that you forgot what part of that long story the rest of us never
>heard of.
>

Yes.  That's the case.  I myself can't remember everything now, and I 
think it is better to put this off to post 4.0 and then have a 
discussion about it.  The bottom line is that I added colorboxes to 2D 
images and thought that the 3D method of basing the position on the 
plotting axes is silly.  Rather, I just shifted the plotting window and 
left room for the colorbox.  The plot simply readjusts itself.  Simple. 
 I think also in our discussions, Petr and I thought controlling the 
size of the colorbox was difficult as it currently exists.

>>If the colorbox is removed, there is a nice even border around the plot.
>>    
>>
>
>That this margin is even is nice alright.  Its very existence, however,
>arguably isn't.  Esp. since the way it's generated completely neglects a
>couple of important settings, most importantly all the margins except
>lmargin, and also 'set size ratio'. 
>

Exactly.  I think this is what got me looking into margins, not only on 
the X11 displays but also the PSLaTeX output.  There doesn't need to be 
such a big margin there, UNLESS it has something to do with allowing 
enough room so that rotating the image doesn't cause a different view of 
the 3D graph to extend off the screen.  This could be the issue with why 
PSLaTeX doesn't work.  It might be basing its margins and background on 
the original 3D graph and not the rotated.  Consequently, it cuts off 
some of the graph.

>I personally think that the current arrangement of the colour box and plot
>is reasonably fine.  The graph itself is better off being centered in the
>window.  Given we have those rather uselessly wide margins to the side of
>the 3D graph anyway, I don't see any harm done putting optional plot
>decorations like the color box out there.
>

Well, get rid of the large margins and adjust them based upon the 
presence of a colorbox.  There's the solution.  It would be the same 
routine for both 2D and 3D.  There is an example in the image demo that 
I've put at

http://acer-access.com/~ds...@ac.../

(Click on "Gnuplot Stuff", and then "colorboxdem.png".)

Check out how slick that looks.  The colorbox isn't wider than it need 
be.  The plots are all balanced, with more space between the individual 
multiplots.  I doubt a 3D colorbox example would look that good as it 
currently exists.

>>But when the color box is present, the plot image isn't altered; the
>>color box is just stuffed in one of the margins.  I'm arguing that the
>>colorbox position code should open that margin a bit more and place the
>>colorbox as a separate entity. Repositioning the plotting region
>>shouldn't be that difficult.  It would be the same for both 2d and 3d.
>>    
>>
>
>In a nutshell, that would mean you want boundary3d() to behave more
>similarly, or maybe even just *call*, its 2D sibling: boundary().
>

Right.  My point is that there is more shared between 2D and 3D plots 
than the gnuplot code would suggest.  I think there should be a 
"graphics.c" (the majority of routines including positioning and drawing 
of color boxes), a "graph2d.c" (probably a small file), a "graph3d.c" 
(probably a bit bigger than graph2d.c because it holds some translation 
routines).

>  Fine
>with me if someone gets it done, but unless we want to put 4.0 on hold for
>another several months of bugfixing after a change in such a rather
>fragile part of the code, I recommend against trying this right now.
>  
>

That was my point.  This is easily a 6 month cycle of mods/debug/tryout. 
 It is something that requires intense effort and time.

>For the time being, the change I outlined would do exactly what Petr did
>(seem to) ask for: it makes the position of the color box independent of
>'set view' by fixing it to terminal-independant and view-independent
>position.  One could argue that the correct position should be given in
>the same coordinate system as user-specified color box placements, i.e.
>"screen" coordinates, but that's a separate issue.
>

OK, so you are saying the rotating colorbox in 3D is embarrassing enough 
to warrant a quick fix.  :-)  That's fine with me.

>>Hey, I just looked at the "pslatex" mode because I recalled a problem
>>with 3d borders there.  I see that "pslatex"'s output is slightly
>>different than it used to be.  No longer are there separate files for
>>the postscript and Tex.
>>    
>>
>
>You looked incorrectly then, I guess.  The option needed to get separate
>files is 'auxfile', and it's still alive and well, as far as I'm aware of.
>

Ah.  Thanks.

Dan

Re: color box positioning for splot

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

On Fri, 12 Dec 2003, Daniel J Sebald wrote:
[...]

> If you ask me, even without doing a rotation, the graph just doesn't
> look right.

That's mainly a question about *where* the color box gets put, then, not
how the 'view' setting affects its placement, but shouldn't.  That didn't
appear to be covered by Petr's question.  Maybe you discussed so much in
private that you forgot what part of that long story the rest of us never
heard of.

> If the colorbox is removed, there is a nice even border around the plot.

That this margin is even is nice alright.  Its very existence, however,
arguably isn't.  Esp. since the way it's generated completely neglects a
couple of important settings, most importantly all the margins except
lmargin, and also 'set size ratio'. 

I personally think that the current arrangement of the colour box and plot
is reasonably fine.  The graph itself is better off being centered in the
window.  Given we have those rather uselessly wide margins to the side of
the 3D graph anyway, I don't see any harm done putting optional plot
decorations like the color box out there.

> But when the color box is present, the plot image isn't altered; the
> color box is just stuffed in one of the margins.  I'm arguing that the
> colorbox position code should open that margin a bit more and place the
> colorbox as a separate entity. Repositioning the plotting region
> shouldn't be that difficult.  It would be the same for both 2d and 3d.

In a nutshell, that would mean you want boundary3d() to behave more
similarly, or maybe even just *call*, its 2D sibling: boundary().  Fine
with me if someone gets it done, but unless we want to put 4.0 on hold for
another several months of bugfixing after a change in such a rather
fragile part of the code, I recommend against trying this right now.

For the time being, the change I outlined would do exactly what Petr did
(seem to) ask for: it makes the position of the color box independent of
'set view' by fixing it to terminal-independant and view-independent
position.  One could argue that the correct position should be given in
the same coordinate system as user-specified color box placements, i.e.
"screen" coordinates, but that's a separate issue.

> Hey, I just looked at the "pslatex" mode because I recalled a problem
> with 3d borders there.  I see that "pslatex"'s output is slightly
> different than it used to be.  No longer are there separate files for
> the postscript and Tex.

You looked incorrectly then, I guess.  The option needed to get separate
files is 'auxfile', and it's still alive and well, as far as I'm aware of.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Updated HTML version of demo scripts now on SourceForge

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

I wrote a perl script to auto-generate a web page for each gnuplot demo 
script.  The perl script itself is now in the CVS tree as demo/webify.pl
I used it to create web pages for almost all of the current demos.
They are on
	http://gnuplot.sourceforge.net/demo/

There were some problems with the pm3d.dem run, and the
vector.dem run didn't work at all.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: color box positioning for splot

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

Hans-Bernhard Broeker wrote:

>On Fri, 12 Dec 2003, Petr Mikulik wrote:
>
>  
>
>>Colorbox should stay at that position where it is for the default view.
>>    
>>
>
>Then it mustn't be output in terms of data coordinates, but in "view
>coordinates" or even directly in screen coordinates.  The difference
>between the two is the matrix multiplication carried out by functions
>map3d_xy() and map3d_xyz() in util3d.c.
>
>So you would have to avoid calling either of those (or referring to
>trans_mat, for that matter) in draw_color_smooth_box().
>
>A little background: 3D plots have four distinct coordinate systems, not
>just the three we expose to the user in the 2D case:
>
>	first/second  (i.e. data coordinates)
>	graph         
>	screen
>
>In 3D, the processing goes like this:
>
>data points ---- (ranges, map_x3d() & friend) ----> normalized coordinates
>  
>normalized coordinates (set view, map3d_xyz()) ---> view coordinates
>
>view coordinates ----> ([xy]scaler, [xy]middle) ---> terminal coordinates
>
>Of these, the "normalized" most closely match the 2D "graph" coordinates,
>and terminal coordinates are essentially the same as "screen".  View 
>coordinates fall somewhere between those. 
>
>For reference, the results in default 'set view' for the corners of the
>colour box are:
>
>res = {0.70899346400575247, -0.14693375672974057, 2.1484375602010033,
>  6.1537877952320801e-313}
>res = {0.77827549630850756, 0.49701905283832915, 2.1484375602010033,
>  6.1537877952320801e-313}
>
>(It's the first two coordinates only, in each case, that count).
>Apply scaler and middle and use those as cb_{x|y}_{from|to}, and you 
>should be in business.
>

That is all correct, but you're underestimating the
appropriate change that needs to be made.  Do as
Petr said,

set pm3d
splot x*y

If you ask me, even without doing a rotation, the
graph just doesn't look right.  If the colorbox is
removed, there is a nice even border around the
plot.  But when the color box is present, the plot
image isn't altered; the color box is just stuffed
in one of the margins.  I'm arguing that the colorbox
position code should open that margin a bit more
and place the colorbox as a separate entity.
Repositioning the plotting region shouldn't be that
difficult.  It would be the same for both 2d and 3d.

Hey, I just looked at the "pslatex" mode because
I recalled a problem with 3d borders there.  I see
that "pslatex"'s output is slightly different than it
used to be.  No longer are there separate files for
the postscript and Tex.  It seems to work in a fairly
similar fashion so I tried some 3d plots...  Without
a 3d rotation, and with the borders set to zero, the
plot comes out nice.  But, doing a rotation and then
plotting results in a figure that, after a few steps
with latex and dvips, has a portion of the plot chopped
off.  Some work is needed there.

My feeling is that to do the colorbox and margins
in a nice way is a lot more work than expected.

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/





-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: color box positioning for splot

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

On Fri, 12 Dec 2003, Petr Mikulik wrote:

> Colorbox should stay at that position where it is for the default view.

Then it mustn't be output in terms of data coordinates, but in "view
coordinates" or even directly in screen coordinates.  The difference
between the two is the matrix multiplication carried out by functions
map3d_xy() and map3d_xyz() in util3d.c.

So you would have to avoid calling either of those (or referring to
trans_mat, for that matter) in draw_color_smooth_box().

A little background: 3D plots have four distinct coordinate systems, not
just the three we expose to the user in the 2D case:

	first/second  (i.e. data coordinates)
	graph         
	screen

In 3D, the processing goes like this:

data points ---- (ranges, map_x3d() & friend) ----> normalized coordinates
  
normalized coordinates (set view, map3d_xyz()) ---> view coordinates

view coordinates ----> ([xy]scaler, [xy]middle) ---> terminal coordinates

Of these, the "normalized" most closely match the 2D "graph" coordinates,
and terminal coordinates are essentially the same as "screen".  View 
coordinates fall somewhere between those. 

For reference, the results in default 'set view' for the corners of the
colour box are:

res = {0.70899346400575247, -0.14693375672974057, 2.1484375602010033,
  6.1537877952320801e-313}
res = {0.77827549630850756, 0.49701905283832915, 2.1484375602010033,
  6.1537877952320801e-313}

(It's the first two coordinates only, in each case, that count).
Apply scaler and middle and use those as cb_{x|y}_{from|to}, and you 
should be in business.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: color box positioning for splot

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

Petr Mikulik wrote:

>I'd like to ask here again: Could somebody have a look how to fix position
>of the color box when a surface is rotated (by mouse or by 'set view'
>commands). It's fine for 'set view map', but not for other views. E.g.
>	set pm3d
>	splot x*y
>.. and rotate the surface by mouse
>
>Colorbox should stay at that position where it is for the default view.
>
>I had a look to the source of 3d positions, but I failed to figure it out. I
>hope somebody will be more lucky.
>
>This fix would be nice for the forthcoming 4.0 release...
>

I can understand wanting this change, as you and I talked about this
outside the list and I want to see this fixed as much as anyone, but
I've feared the "fix a few things first" approach to making a release.

There are a couple things about this.  You and I agreed that a nicer
control of the colorbox position is in order.  Also, I made a comment
a while back that I think there should be more consistency amoung
2d and 3d plots.  The "image" patch allows a colorbox for 2d plots,
similar to "map" mode for 3d.  The code is fine for the 2d colorbox in
the patch, but the organization is a kludge.  It is in two different 
locations
for 2d and 3d, and the two are done in different ways.  My opinion is
to combine the two in a consistent fashion, reusing the colorbox
placement code.  It is something outside of the plot (or it should be,
unlike the quick fix of the 3d plot method) and will be the same for
2d/3d.  It simply takes up some space and repositions the plotting area
of the actual plot.

If there is to be any progress and things done "right", then one has to
allow major changes and allow the code to destabilize for a while.
One can put some effort into fixing and debugging that, then after 4.0
if there seems to be a need for colorboxes in 2d plots then one may
end up reprogramming some of it.

Dan

color box positioning for splot

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

I'd like to ask here again: Could somebody have a look how to fix position
of the color box when a surface is rotated (by mouse or by 'set view'
commands). It's fine for 'set view map', but not for other views. E.g.
	set pm3d
	splot x*y
.. and rotate the surface by mouse

Colorbox should stay at that position where it is for the default view.

I had a look to the source of 3d positions, but I failed to figure it out. I
hope somebody will be more lucky.

This fix would be nice for the forthcoming 4.0 release...

---
Petr Mikulik

Re: new command: raise

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

> There is something we need to be careful about with the "raise"
> command.  Raising windows one at a time is fine; there is the
> XRaiseWindow() function.  However, raising all the Gnuplot
> plots at once might pose a bit of a problem.  The raise routine to be
> "nice".

> No solution is better than a bad solution in this case.  So, there
> has to be a method to maintain the order as the window manager
> sees it for just that group of plots associated with gnuplot_x11.

I propose that you try to implement it, and we see how nicely it works.

> "raise" to bring up the Gnuplot plots.  But gnuplot_x11 will go through
> its list and raise them one at a time in which case plots 1 and 2 will
> go back down to the bottom of the pile.  The user will not like that
> and there will be complaints.

1. the user will know about it from the "raise" command documentation

2. he does not mind about the windows order at all if his windows do not
overlap (that's what you usually organize if you want to see of your plots
simultaneously) -- so the worries about window manager and particular order
are quite irrelevant

---
Petr Mikulik

Re: test palette rgb

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

> 'help test palette' says
>   The optional parameter, a permutation of letters rgb, determines the sequence of
>   r,g,b profiles drawn one after the other --- try this yourself for `set palette
>   gray`. The default sequence is rgb.
>
> When I try this with the x11, post or png terminals, I do not see any difference in
> the resulting plot no matter whether I say  rgb or grb or brg or whatever.
> The order of labels on the curves change, but that is the only thing different.
>
> Am I doing something wrong, or is this a bug, or am I not understanding
> what the output is supposed to show?

Try this:

set palette gray
test palette rgb
pause
test palette rbg
pause
test palette bgr

...it shows different things.
If it not clear from the docs, you can modify it.

---
Petr Mikulik

Re: test palette rgb

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

Petr:

'help test palette' says
  The optional parameter, a permutation of letters rgb, determines the se=
quence of
  r,g,b profiles drawn one after the other --- try this yourself for `set=
 palette
  gray`. The default sequence is rgb.

When I try this with the x11, post or png terminals, I do not see any dif=
ference in=20
the resulting plot no matter whether I say  rgb or grb or brg or whatever=
=2E
The order of labels on the curves change, but that is the only thing diff=
erent.

Am I doing something wrong, or is this a bug, or am I not understanding
what the output is supposed to show?

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

Re: new command: raise

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

Daniel J Sebald wrote:

> Petr Mikulik wrote:
>
>>> I have done a little bit of research into the X11 protocols,
>>> and here is what I have found. 
>>

 From doing a "man XRaiseWindow" I gather that "stack" and "depth"
are in fact the same thing, i.e., "stack" pertains to the appearance on
the desktop.

There is something we need to be careful about with the "raise"
command.  Raising windows one at a time is fine; there is the
XRaiseWindow() function.  However, raising all the Gnuplot
plots at once might pose a bit of a problem.  The raise routine to be
"nice".  That is, say I make plots
1 through 8, in that order so that the linked list within gnuplot_x11
is sequential.  But then, I raise plot 1 and 2 to the front, _via the
window manager_, not via the "raise #" command.  There is no
way for gnuplot_x11 to know that that was done.  Only the window
manager knows that.  OK, I go off do something else and then type
"raise" to bring up the Gnuplot plots.  But gnuplot_x11 will go through
its list and raise them one at a time in which case plots 1 and 2 will
go back down to the bottom of the pile.  The user will not like that
and there will be complaints.

No solution is better than a bad solution in this case.  So, there
has to be a method to maintain the order as the window manager
sees it for just that group of plots associated with gnuplot_x11.
Otherwise, no go.  I'm looking to see if there is a command or
option that will raise all subwindows of a given window.  There
is a circulate command for subwindows, even that might work if
one calls circulate for the number of windows there are.  That
way all the subwindows come up eventually and maintain their
order.

Dan

Re: new command: raise

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

Petr Mikulik wrote:

>>I have done a little bit of research into the X11 protocols,
>>and here is what I have found.
>>
>>The X11 standard strongly discourages client programs from
>>trying to control window placement or position in the stack
>>(i.e. raise/lower) except by making a request of the window
>>manager.
>>    
>>
>
>It would say that's a complete nonsense. *I* want to decide myself what I
>want to have a look to, not sb else...
>
>In particular:
>
>1. "plot x" => gnuplot raises its x11 window. No problem  with any
>window manager.
>
>2. Further, hitting <space> in graphical window => gnuplot's console is
>raised.  No problem.
>
>So I really don't know what do you mean in your letter.
>

This is the problem with X11 documentation; it isn't precisely clear 
about things, neither is a good concept given.  The obvious is given and 
all the intricacies are left for us to guess...  We may be making too 
much out of this.  It may be simply that the documentation intends that 
the programmer should never directly have the window do these sorts of 
things.  Rather you should request the manager to tell the window to do 
something.  That way you avoid any conflicts in a multitasking system 
where something could happen to remove or change the window, unknown to 
the programmer.

Dan

Re: new command: raise

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

Ethan Merritt wrote:

>I have done a little bit of research into the X11 protocols,
>and here is what I have found.
>
>The X11 standard strongly discourages client programs from
>trying to control window placement or position in the stack
>(i.e. raise/lower) except by making a request of the window 
>manager.  Basically this means that if you can't do what you
>want in the window manager, then you can't do it from the 
>application program either.  The application can set a
>"please raise me" attribute for a window, but the window
>manager decides whether or not to pay any attention to this.
>
>I think the bottom line is that gnuplot_x11 is free to mark
>all its windows as belonging to the same "window_group"
>if it wants to, but whether this has the effect that Petr wants
>(raise them all at once) will depend entirely on the window
>manager.
>
>Let me quote from a couple of relevant sections from
>Scheifler & Gettys "X Window System" reference manual.
>
><begin quote>
>4.1.5 Configuring the Window
>[...]
>	Convention
>Clients that use a ConfigureWindow request to request a change
>in their position in the stack should do so using None in the sibling
>field. [...] Doing this is deprecated, and window managers are in any
>case free to position windows in the stack as they see fit.
><end quote> 
>
>
><begin quote>
>4.1.11 Window Groups
>A set of top-level windows that should be treated from the
>user's point of view as related (even though they may belong
>to a number of clients) should be linked together using the
>window_group field of the WM_HINTS structure. [...]
>It is up to the window manager to determine the policy for
>treating the windows in a group. At present, there is no way
>for a client to request a group, as opposed to an individual,
>operation.
><end quote>
>

Are "stack" and "depth" the same thing? I pointed out before that X11
seems to have a routine dedicated to raising a window, i.e., the depth
of the window in terms of visibility. All other window properties seem
to be handled by another function, and those properties seem to be all
the other items that are listed when you look at the upper-left corner
of the X11 window. The menu has "maximize", "unmaximize", "in group"...
and one labelled "depth". Honestly, I'm not an expert on what every one
of those does. But, I'm wondering if "stack" in the documentation refers
to internally how X11 arranges things in its linked list of windows,
i.e.,the order in which signals are sent around the system.

Dan

version

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

  >

>
>***
>
>This discussion takes us to new dimensions of gnuplot -- and the end of year
>is almost here ...  thus I would propose the following:
>
>- add this command "raise" as I proposed, with a simple X11 implementation
>as proposed
>

I could write a patch this weekend some time.

>- release gnuplot 3.8k next week, and gnuplot 4.0 in January
>

I would say that the "raise" isn't essential to a release.  It could 
remain as a patch.  Since it will likely be a small patch, my guess is 
that it won't be as susceptible to changes in CVS and won't need 
updating so much.

But certainly, moving toward a 4.0 release is a good idea.  (If I 
understand correctly, 4.0 will be an "official" release, not a beta sort 
of thing.)

>- do all these nice interactive terminal changes afterwards, with enough
>time for discussions
>

Well, I guess this was my idea.  But I myself am not totally sold on 
this.  Doing this is sort of a big change, or addition, to the paradigm, 
and I'm afraid that it may take things down a path of people requesting 
additional support, and soon we have something that is more than 
intended and perhaps totally different from a better scheme.  (Maybe the 
scheme Hans discussed where there are multiple plots.**)  I guess it is 
the syntax that is really the "standard" in Gnuplot [Changing things 
behind the scenes isn't always so crucial... "ignore that man behind the 
curtain" ;)], and 'raise' seems the logical choice.  But still.  I see 
the beta releases as being ways of putting those patches that are 
clearly desirable into the code then allowing developers to try them 
out, suggest changes and knock the rough edges off of them.  [Case in 
point is the image patch.  Having Petr's and Ethan's feedback has made 
it much nicer than what I originally did.]  I would say aim for 4.0, tag 
the version, then start introducing some of the new ideas and let things 
destabilize a bit.

Dan

** But that is a BIG change.  It would require saving the actual plot 
commands in a linked list, not too bad.  But also it would require the 
capturing of the state of the system "set variables" before any change 
in the terminal window.  I assume that would mean organizing all those 
variables into a nice table format.

Re: new command: raise

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

> I have done a little bit of research into the X11 protocols,
> and here is what I have found.
>
> The X11 standard strongly discourages client programs from
> trying to control window placement or position in the stack
> (i.e. raise/lower) except by making a request of the window
> manager.

It would say that's a complete nonsense. *I* want to decide myself what I
want to have a look to, not sb else...

In particular:

1. "plot x" => gnuplot raises its x11 window. No problem  with any
window manager.

2. Further, hitting <space> in graphical window => gnuplot's console is
raised.  No problem.

So I really don't know what do you mean in your letter.

> application program either.  The application can set a
> "please raise me" attribute for a window, but the window
> manager decides whether or not to pay any attention to this.

Raising window is an X11 function .. and window manager is also just an X11
application too...

> treating the windows in a group. At present, there is no way
> for a client to request a group, as opposed to an individual,
> operation.

Thus, the client apps has to raise its window one after the other, as I
have proposed.

---
Petr Mikulik

Re: new command: raise

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

Petr Mikulik wrote:

>>How about a 'v' for "lower".  If "raise #" makes sense as a
>>command, then wouldn't "lower #" find a similar sort of
>>usefulness?
>>    
>>
>
>Whatever you may like can be there.
>Just notice that "^" is not sent as a new "pipe command", but as a suboption
>for a "special" command.
>

Oh.

>>I originally proposed that there also be functionality for
>>minimizing, maximizing, etc.  Ethan said this is bloat,
>>    
>>
>
>Currently, I don't see any reason for these additional commands -- they can
>be achieved anywhere but an icon on the titlebar.
>

I don't either any longer.

>But how would you launch it?
>How to do it portable?
>
>set term interactive close
>set term interactive 4 maximize
>
>?? rather than
>set term [pm or x11 or windows or ...]
>

I was thinking a

"set term x11 interactive" would make x11 or whatever the
interactive terminal.  Then any of the "window manager"
terminal commands

raise
minimize
maximize
close
hide

would be directed to the interactive terminal as opposed to the
plot terminal.  Of course, they will often be the same terminal.

That would be too many commands for what it provides.

Dan

Re: new command: raise

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

I have done a little bit of research into the X11 protocols,
and here is what I have found.

The X11 standard strongly discourages client programs from
trying to control window placement or position in the stack
(i.e. raise/lower) except by making a request of the window=20
manager.  Basically this means that if you can't do what you
want in the window manager, then you can't do it from the=20
application program either.  The application can set a
"please raise me" attribute for a window, but the window
manager decides whether or not to pay any attention to this.

I think the bottom line is that gnuplot_x11 is free to mark
all its windows as belonging to the same "window_group"
if it wants to, but whether this has the effect that Petr wants
(raise them all at once) will depend entirely on the window
manager.

Let me quote from a couple of relevant sections from
Scheifler & Gettys "X Window System" reference manual.

<begin quote>
4.1.5 Configuring the Window
[...]
=09Convention
Clients that use a ConfigureWindow request to request a change
in their position in the stack should do so using None in the sibling
field. [...] Doing this is deprecated, and window managers are in any
case free to position windows in the stack as they see fit.
<end quote>=20


<begin quote>
4.1.11 Window Groups
A set of top-level windows that should be treated from the
user's point of view as related (even though they may belong
to a number of clients) should be linked together using the
window_group field of the WM_HINTS structure. [...]
It is up to the window manager to determine the policy for
treating the windows in a group. At present, there is no way
for a client to request a group, as opposed to an individual,
operation.
<end quote>

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