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

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

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

Franz has found the patch which started to cause this problem.
Ethan, can you please look at it?

Thanks, Petr

---------- Forwarded message ----------
Date: Tue, 16 Dec 2003 17:19:05 +0100 (CET)
From: Franz Bakan <fb...@gm...>
To: "os2...@wa..." <os2...@wa...>,
     Petr Mikulik <mi...@ph...>
Subject: Re: problems compiling gnuplot

Hi Petr, Hi list,

On Mon, 15 Dec 2003 16:23:44 +0100 (CET), Petr Mikulik wrote:

>> I tried a little bit now and x11 works very limited:
>>
>> Within HOBX11 it works like this:
>>
>>  gnuplot>set term x11
>>  gnuplot> plot sin(x)
>>
>> X11-window opens and the x11-clock-cursor appears but no plot.
>> When I now press 'return' in the gnuplot-VIO window the plot appears in
>> the X11-Winwow.
>
>Ok, I see them same problems too (with XFree86 as well as with PMX).
>If I recompile gnuplot without MOUSE, then it works OK.
>
>One guess: there is somewhere code using PIPE_IPC (and thus stdin/stdout of
>gnuplot_x11) which is not encapsulated by #ifdef PIPE_IPC ... #endif.
>
>Note that PIPE_IPC is unixish communication gnuplot_x11 => gnuplot, while
>OS/2 is using OS2_IPC for this.
>
>
>> Because your binaries from May 2003 work without such problems with HOBX11
>
>Maybe you could try to download some later version of gnuplot, by a command
>like
>	cvs -z3 -D "June 1, 2003" checkout -P gnuplot

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/gnuplot checkout -D "June 21, 2003" -P -d gnuplot-2003-06-21

is the working syntax.

>and see where it was still working => thus figure out which patch made
>the problem ... if my guess is OK.

done and now I can tell you that

20. June 2003 works  and  21. June 2003 doesn't.

So one of these patches are the culprit:

>From Changelog:

2003-06-20  Ethan Merritt  <merritt@u.washington.edu>

        * src/gplt_x11.c:
        It turns out that yesterday's patch breaks the "pause -1" command
        (it always returns immediately).  I have temporarily disabled the
        new code while I track down the problem.  The offending line is now
        protected by #ifdef X11_FONT_UPDATE.

        * term/x11.trm:
        Add an interlock so that the gnuplot_x11<->x11.trm font info exchange
        is only performed once per splot, rather than every time the view is
        changed using the mouse.

2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

        * src/gplt_x11.c src/graphics.c src/mouse.c src/mousecmn.h term/x11.trm
        Use existing mouse communication pipe to send X11 font characteristics
        back from gnuplot_x11 to x11.trm. This allows gnuplot to lay out the
        plot with v_char and h_char sizes that are correct for the current
        default X11 font. This patch slightly changes the timing of initial
        operations over the pipe, and adds a FFLUSH(), so there is a remote
        possibility that it also fixes a reported problem in which gnuplot_x11
        eats CPU cycles while supposedly idle. This patch should have no effect
        if gnuplot is configured with --disable-mouse.

        * term/pslatex.trm: Escape % to %% inside printf() statement.

Re: x11 prints garbage to stdout on OS/2

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

On Tue, 16 Dec 2003, Petr Mikulik wrote:

> There is a report, which I can confirm, that X11 terminal under OS/2
> 
> - prints a lot of garbage onto the gnuplot xterm, or
> - blocks until you hit <Enter>
> 
> In the latter case, gnuplot continues to plot OK.
> 
> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC around
> it, and thus all the communication goes into the screen. Or reading stdin
> where it should not, or like that. Can somebody have a look to this issue?
> Thanks. I haven't found a problem in gplt_x11.c, maybe somewhere else?

By far the most likely place for this to happen is not gplt_x11.c, but
x11.trm.  Looking at that "garbage" should help a lot to clear that up.

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

x11 prints garbage to stdout on OS/2

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

There is a report, which I can confirm, that X11 terminal under OS/2

- prints a lot of garbage onto the gnuplot xterm, or
- blocks until you hit <Enter>

In the latter case, gnuplot continues to plot OK.

I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC around
it, and thus all the communication goes into the screen. Or reading stdin
where it should not, or like that. Can somebody have a look to this issue?
Thanks. I haven't found a problem in gplt_x11.c, maybe somewhere else?

(Note: OS/2 communication is surrounded by OS2_IPC)

---
Petr Mikulik

Re: News in gnuplot.doc

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

> > Ethan has added new section "What is New in Version 4.0". I've just added
> > some items in it. Please, have a look and extend it as necessary as you
> > think.
>
> Having this section feels like a maintenance problem --- we now have to
> maintain the same information in two places, NEWS and gnuplot.doc.

No, they are different. NEWS is more or less (un)organized, with lines added
during the time development -- well, it shows progress of gnuplot.

"New" section in gnuplot.doc is a nicely written polished version of changes
from 3.7 to 4.0 with hypertext facility to the corresponding places in the
file. It is grouped by functionality, not by time.

> > I have searched some docs about using "history file", i.e.  automatic saving
> > and restoring of the command history.  Is it there or not?  I though it is,
> > but I could not find it.
>
> It's not in 'help history', which means that if it either doesn't exist,
> or it's in the wrong place.  Either way, this would have to be fixed.

I don't know whether it exists -- maybe with GNU readline? I remember it was
discussed, but don't remember the result.

> > x11.trm: It may be worth to write into docs that piping with "set mouse" can
> > be used only if pipe must be (un??)buffered, the external caller program
> > must issue a command like setmode(????, O_????).
>
> You seem to know best about it ---> you write it.

That's it, I don't know exactly how is it now -- I think Ethan is the most
informed in this matter. Can you please write a bit about that?

Maybe there can be a link from "help batch/interactive" .. and maybe also to
"pgnuplot" for windows?

---
Petr Mikulik

Re: News in gnuplot.doc

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

On Tue, 16 Dec 2003, Petr Mikulik wrote:

> Ethan has added new section "What is New in Version 4.0". I've just added
> some items in it. Please, have a look and extend it as necessary as you
> think.

Having this section feels like a maintenance problem --- we now have to
maintain the same information in two places, NEWS and gnuplot.doc.

Can we perhaps have a mechanism that generates one from the other (only
active in autoconf "maintainer mode")?

> I have searched some docs about using "history file", i.e.  automatic saving
> and restoring of the command history.  Is it there or not?  I though it is,
> but I could not find it.

It's not in 'help history', which means that if it either doesn't exist,
or it's in the wrong place.  Either way, this would have to be fixed.

> Should "test time" command be documented? Who knows/uses it?

I don't think it should be documented.  It's useful almost only to us
developers.  It may be best to remove its implementation rather than add
documentation of it, as far as I'm concerned.

> x11.trm: It may be worth to write into docs that piping with "set mouse" can
> be used only if pipe must be (un??)buffered, the external caller program
> must issue a command like setmode(????, O_????).

You seem to know best about it ---> you write it.

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

News in gnuplot.doc

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

Ethan has added new section "What is New in Version 4.0". I've just added
some items in it. Please, have a look and extend it as necessary as you
think.

Maybe some (more) words about fontpath, gdfontpath and truetype fonts?


And some additional notes to the docs:
--------------------------------------

I have searched some docs about using "history file", i.e.  automatic saving
and restoring of the command history.  Is it there or not?  I though it is,
but I could not find it.


Should "test time" command be documented? Who knows/uses it?


x11.trm: It may be worth to write into docs that piping with "set mouse" can
be used only if pipe must be (un??)buffered, the external caller program
must issue a command like setmode(????, O_????).


---
Petr Mikulik

Re: webify.pl and HTML demos

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

> > 	save "|gpsavediff >electron-1.gp"
> >
> > Is this possible?
>
> It is possible, but the output from the gnuplot "save" command is
> not the best thing to provide people as a sample script because
> it is so wordy.

That's why I've proposed to pass it through the "gnuplot save diff" script
to write out only those commands changed wrt the "reset" status. (I'm
enclosing my favourite gpsavediff.)

It is convenient to have a look to a demo image and say "I want such an
image!" and just to download a simple script for this.

> More ideas for this demo page are welcome.  I only made a very
> quick script because I thought we really needed something more
> recent than the old 3.7 demo output.

Add a PDF file with these plots so that people can download it?

---
Petr Mikulik

Re: Subject: Re: Bug in PostScript arrows

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

On Sunday 14 December 2003 23:41, Petr Mikulik wrote:
>
> 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.

It is true that the awk scripts do not like having the "stroke"
present.  However, the stroke command is nevertheless correct
in cases where it is needed in order to complete the previous
line-drawing sequence.

I did not find any tests in which the *.ps output was incorrectly
rendered by gv with the PS_FLUSH_PATH present; only cases
where the awk scripts failed to parse it.

However, it is true that the original code called PS_FLUSH_PATH
in more cases than is strictly necessary.  I changed the call in=20
PS_filled_polygon to be conditional:

    /* Stroke the previous graphic element if required. */
    if (PS_relative_ok)
        PS_FLUSH_PATH;

This works for all the test cases I have tried, but I don't=20
guarantee there isn't some sequence of calls that will insert
a "stroke" somewhere that the awk scripts do not expect it.
If there is such a case, I think the fix will have to be in the awk scrip=
ts.

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

Re: webify.pl and HTML demos

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

On Monday 15 December 2003 02:04, Petr Mikulik wrote:
>
>   I have one idea: clicking on the image, or to a "download full script=
"
> link, or like, would retrieve commands just needed to reproduce the
> script, i.e.  something like
> =09plot ....
> =09save "|gpsavediff >electron-1.gp"
>
> Is this possible?

It is possible, but the output from the gnuplot "save" command is
not the best thing to provide people as a sample script because
it is so wordy.   I think maybe it is better to give a short explanation
on the top web page that the commands required to generate the
plots within each demo are cumulative.

More ideas for this demo page are welcome.  I only made a very
quick script because I thought we really needed something more
recent than the old 3.7 demo output.

If I find some time I will add thumbnails to the top level page and
try to make it more of a visual FAQ -
"How do I make a plot like this? <click on plot to see demo script>"=20

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

Re: color box positioning for splot

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

On Sun, 14 Dec 2003, Daniel J Sebald wrote:

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


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

webify.pl and HTML demos

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

	Hi Ethan,

the script & demos are nice.

  I have one idea: clicking on the image, or to a "download full script"
link, or like, would retrieve commands just needed to reproduce the script,
i.e.  something like
	plot ....
	save "|gpsavediff >electron-1.gp"

Currently, the text shown, is with respect to the previous plot, not with
respect to the "reset" status.

Is this possible?

---
Petr Mikulik

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

[Harald H. <h.h...@tu...>]

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

It is not necessary after fillpath but it _is_ necessary after closepath.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Institut f=FCr Werkstoffe                  D-38106 Braunschweig
Technische Universit=E4t Braunschweig      Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: Konsola and KDE list

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

> > What I would really love now is that "space-bar" hotkey working in x11
> > terminal in gnuplot running under KDE's Konsole. It works in xterm, gnome
> > terminal, but not in Konsole. I've tried to ask at several places, but
> > nobody answered.
> >
> > Does somebody an idea what to do now? Whom/where to ask for help?
>
>  KDE developer list?

This helped.
Feature implemented and commited. <space> hotkey works nice in KDE!

Somebody wants to support multitabs in gnome-terminal?

---
Petr Mikulik

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/