color box positioning for splot

[Petr Mikulik]

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

[Daniel J Sebald]

Post by Petr Mikulik
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

[Hans-Bernhard Broeker]

Post by Petr Mikulik
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.

[Daniel J Sebald]

Post by Hans-Bernhard Broeker

Post by Petr Mikulik
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
first/second (i.e. data coordinates)
graph
screen
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
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/

[Hans-Bernhard Broeker]

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.

[Daniel J Sebald]

Post by Hans-Bernhard Broeker
[...]

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.

Post by Hans-Bernhard Broeker

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.

Post by Hans-Bernhard Broeker
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/~***@acer-access.com/

(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.

Post by Hans-Bernhard Broeker

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).

Post by Hans-Bernhard Broeker
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.

Post by Hans-Bernhard Broeker
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.

Post by Hans-Bernhard Broeker

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

[Hans-Bernhard Broeker]

Post by Daniel J Sebald
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.

Post by Daniel J Sebald
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.

Post by Daniel J Sebald
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.

Post by Daniel J Sebald
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.

[Petr Mikulik]

Post by Hans-Bernhard Broeker

Post by Daniel J Sebald
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

[Daniel J Sebald]

Post by Petr Mikulik

Post by Hans-Bernhard Broeker

Post by Daniel J Sebald
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

[Daniel J Sebald]

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

Post by Petr Mikulik

Post by Hans-Bernhard Broeker

Post by Daniel J Sebald
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
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

[Hans-Bernhard Broeker]

Post by Daniel J Sebald
I don't have time to modify and test a quick fix for the colorbox.

I did one and put it into CVS.

It works as announced in my original reply: it places the color box in
exactly the position it has in default 'set view' settings, regardless of
what the current view settings are. This could have been done by
resetting the view matrix to default, but I chose a more blunt way: ran
the existing code in a debugger to step through map3d_xy when called from
the colorbox generator, and wrote down the position of the color box in
"view coordinates". It's really a quick and dirty fix, but like all such,
it works ;-)

Daniel: your thoughts about xleft and friends are only partly right.
The actual mapping for 3D plots does *not* actually use those. It
uses the variables xscaler, xmiddle, yscaler and ymiddle, instead, so
the actual code snippet I inserted looks like this:

cb_x_from = xmiddle + 0.709 * xscaler;
cb_x_to = xmiddle + 0.778 * xscaler;
cb_y_from = ymiddle - 0.147 * yscaler;
cb_y_to = ymiddle + 0.497 * yscaler;

The constants are what I ripped out of that debugger session, the rest is
the expected mapping from view coordinates to terminal coordinates, as
used by map3d_xy() and the TERMCOORD() macro in util3d.

Some other parts of the 3D plotting engine (outputting the title and key,
e.g.) do use xleft and friends, but that's because they work directly in
2D, neglecting the whole 3D stuff.

[Daniel J Sebald]

Post by Hans-Bernhard Broeker

Post by Daniel J Sebald
I don't have time to modify and test a quick fix for the colorbox.

I did one and put it into CVS.
It works as announced in my original reply: it places the color box in
exactly the position it has in default 'set view' settings, regardless of
what the current view settings are. This could have been done by
resetting the view matrix to default, but I chose a more blunt way: ran
the existing code in a debugger to step through map3d_xy when called from
the colorbox generator, and wrote down the position of the color box in
"view coordinates". It's really a quick and dirty fix, but like all such,
it works ;-)

I was skeptical about finding a quick fix, but this is a worthy
improvement. The graph brushes up against the colorbox in some views
(which is the same issue as with the key, I guess), but it will do.

Doubting Daniel

[Hans-Bernhard Broeker]

On Tue, 16 Dec 2003, Daniel J Sebald wrote:

[...]

Post by Daniel J Sebald
I was skeptical about finding a quick fix, but this is a worthy
improvement. The graph brushes up against the colorbox in some views
(which is the same issue as with the key, I guess), but it will do.

Those views are mainly those where the z rotation is an odd multiple of
45 degrees, i.e. those where the 3D box has maximum width.

If you don't like the current placement, you or Petr feel free to modify
the constants I put in there. There's quite some space left between the
current position if the cbox and the right border of a default plot. May
the gods save us from users who 'set size 0.7,1', though...