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

Re: Argh: Why are arrows clipped to the graph?

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

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote:
> > I don't know if I agree on that one.  Are you saying that one
> > can't have a fraction of an arrow at the edge of the canvas
> > (i.e., say the tip extends just past the canvas limit, but is
> > not visible)?  That has to be allowed, otherwise one can't use
> > the many features of PostScript.
>
> If you try this with the pdf terminal, it will crash.
> Therefore if you want a program that doesn't crash, you have
> to clip off the protruding piece of the arrow before sending
> it to the driver.  Yes, I know PostScript won't crash if you
> draw outside the boundaries.  But don't you think we should
> aim for code that works (or at least doesn't crash) on all
> the other terminal types as well?

Why do so many routines have clipping? In my opinion we have about four
things that have to be clipped, in most terminals:

points
lines
filled polygons
text

Since arrows are produced by lines and filled polygons in most terminals,
clipping would be done automatically by the routines producing the lines
and the polygons. As a positive side effect, only the part of the arrow
head would be cut off that is outside the canvas.

But that does not solve the current problem that things are cut off which
are inside the canvas.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

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

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> > > > I once have provided a patch that worked, storing both the term boundaries
> > > > as they are now and the canvas size. It wasn't applied to cvs. I remember
> > > > that you were one of the people that complained that this was not the
> > > > right way to do it. But it worked.
> > >
> > > I do not recall seeing such a patch.
> > > Could you remind me which one that is?
> > > I don't see anything on SourceForge that seems to match your description.
> >
> > #1104264, Fix buggy clipping of arrows in large splots
> > #1105611, Introduce 'set pagesize' command
> >
> > > > term->xmax means the position, where the screen coordinate is 1
> > > > term->ymax means the position, where the screen coordinate is 1
> > > > term->xcanvas is the maximal screen coordinate in the canvas
> > > > term->ycanvas is the second maximal screen coordinate in the canvas
> > > >
> > > > This has been provided by my rejected patch, to remind you once again.
>
> Err, that feature is not found in either of the patches you mentioned.
>
> The "Fix buggy clipping" patch does not touch any terminal drivers.

And what do the patches

        /* EAM FIXME - Is this a sufficient test for out-of-bounds? */
-       if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
+       if ((x < 0) ||
+           (multiplot && (x > term->xmax * global_xsize)) ||
+           (!multiplot && (x > term->xmax * xsize)) ||
+           (y < 0) ||
+           (multiplot && (y > term->ymax * global_ysize)) ||
+           (!multiplot && (y > term->ymax * ysize))) {

and

-    if ((0 < x && x < term->xmax) && (0 < y && y < term->ymax))
+    FPRINTF((stderr,"on_page(): %d,%g   %d,%g\n",
+            term->xmax,global_xsize,term->ymax,global_ysize));
+    if ((0 < x && x < term->xmax * global_xsize)
+       && (0 < y && y < term->ymax * global_ysize))

do? They affect clipping due to a 'set size' before 'set terminal'.
Or what does

-    xleft += t->xmax * xoffset;
-    xright += t->xmax * xoffset;
-    ytop += t->ymax * yoffset;
-    ybot += t->ymax * yoffset;
+    xleft += xpagemax * xoffset;
+    xright += xpagemax * xoffset;
+    ytop += ypagemax * yoffset;
+    ybot += ypagemax * yoffset;

and

-    if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
+    if (*sx < 0 || *sx > xpagemax ||
+       *sy < 0 || *sy > ypagemax) {
+       FPRINTF((stderr,"place_arrow3d: skipping out-of-bounds arrow\n"));

do? Yes, clipping. They do not cover all problems we have now because at
the time I started with the patch only arrows in splots were clipped at
screen 1,1. But the maximal coordinate of set size before set terminal
already was stored independently on the term->xmax and term->ymax. They
worked. I did not say that they were elegant (which they for sure
weren't). But they could have served as a start into the right direction.

> The "set pagesize" patch introduces a pair of global scaled values
> xpagesize and ypagesize, but does not add anything like
> term->canvas_xmin,
> term->canvas_xmax,
> term->canvas_ymin,
> term->canvas_ymax
> which is what you would need in order to do clipping.

Yes, it would be more elegant to do it in the term struct. But, I say it
once again, the old approach exactly did what it was supposed do, but
outside of the struct term. This approach did not have the need to touch
the terminals.

I will be glad if sometimes a working clipping will be available.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

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

On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote:
> 
> I don't know if I agree on that one.  Are you saying that one
> can't have a fraction of an arrow at the edge of the canvas
> (i.e., say the tip extends just past the canvas limit, but is
> not visible)?  That has to be allowed, otherwise one can't use
> the many features of PostScript.

If you try this with the pdf terminal, it will crash.
Therefore if you want a program that doesn't crash, you have
to clip off the protruding piece of the arrow before sending
it to the driver.  Yes, I know PostScript won't crash if you
draw outside the boundaries.  But don't you think we should
aim for code that works (or at least doesn't crash) on all
the other terminal types as well?

> Maybe
> a "legacy terminal" is in order... something to prevent the need
> for coding up "if terminal has this feature, then this, otherwise
> that" all over the place in the core code.

We have that now.  These are the routines  do_XXX() in  term.c.
They provide a generic fallback for terminals that don't
supply their own routine to do XXX.

In the case of arrows, the generic code is called do_arrow(),
and is supposed to be usable by all terminals
that do not provide their own specific arrow drawing routine.
That is precisely what we are now fighting with; it isn't generic
enough, because it causes some terminals to segfault, or abort,
or draw garbage if the arrows go outside the current canvas.

If you, or Harald, feel that the generic code is not appropriate
for the PostScript driver, then of course you are free to write
a terminal-specific PS_arrow() routine.  I'm sure you could draw
nicer looking arrows that way, just as the metapost driver does,
for example.


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

Re: Argh: Why are arrows clipped to the graph?

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

On Wednesday 09 November 2005 03:10 pm, Harald Harders wrote:
> On Wed, 9 Nov 2005, Ethan Merritt wrote:
> 
> > On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote:
> > >
> > > I once have provided a patch that worked, storing both the term boundaries
> > > as they are now and the canvas size. It wasn't applied to cvs. I remember
> > > that you were one of the people that complained that this was not the
> > > right way to do it. But it worked.
> >
> > I do not recall seeing such a patch.
> > Could you remind me which one that is?
> > I don't see anything on SourceForge that seems to match your description.
> 
> #1104264, Fix buggy clipping of arrows in large splots
> #1105611, Introduce 'set pagesize' command
> 
> > > term->xmax means the position, where the screen coordinate is 1
> > > term->ymax means the position, where the screen coordinate is 1
> > > term->xcanvas is the maximal screen coordinate in the canvas
> > > term->ycanvas is the second maximal screen coordinate in the canvas
> > >
> > > This has been provided by my rejected patch, to remind you once again.

Err, that feature is not found in either of the patches you mentioned.

The "Fix buggy clipping" patch does not touch any terminal drivers.

The "set pagesize" patch introduces a pair of global scaled values
xpagesize and ypagesize, but does not add anything like
term->canvas_xmin,
term->canvas_xmax,
term->canvas_ymin,
term->canvas_ymax
which is what you would need in order to do clipping.

Although at this point I would prefer to add something like
(BoundingBox *)(term->canvas)
I.e., a structure containing all of the above that could be
passed directly to the clipping routines as a pointer.


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

Re: Argh: Why are arrows clipped to the graph?

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

Harald Harders wrote:
> On Wed, 9 Nov 2005, Ethan Merritt wrote:

>>Finally, we need to agree on what is or is not enforced with
>>regards to plotting outside the canvas limits.  I continue
>>to maintain that this should be categorically prevented, by
>>clipping to the current canvas in the core routines.
> 
> 
> I agree.

I don't know if I agree on that one.  Are you saying that one
can't have a fraction of an arrow at the edge of the canvas
(i.e., say the tip extends just past the canvas limit, but is
not visible)?  That has to be allowed, otherwise one can't use
the many features of PostScript.

There is a bit of a conundrum with gnuplot's "terminal" concept.
The throw back to the time it was conceptualized makes me think
"rudimentary terminal".  I don't know about other people's
opinions, but I just don't like the idea of not striving to
utilize the features of plotting utilities, like were mentioned,
PostScript, png, jpg, pdf, etc.  The philosophy (which really
wasn't a big issue ten years ago because of limited utilities)
seems to be implement things generically with the most rudimentary
elements.  If development slows down because people don't have
the time, that's one thing.  Bottlenecks is something different.

As a brainstorm kind of thing, I sort of like the strategy of
having a "fallback prototype".  Use an arrow as an example.  Say
there is some legacy gnuplot code that draws an arrow using just
lines and/or fill.  But there are a number of drawing utilities
that support arrows outright.  It would be nice to set aside the
legacy code as a "fallback prototype" and have a new terminal
routine for arrows.  The fallback prototype would have the same
arguments as the new terminal routine.  The concept would hold
true for a large number of items in ever-evolving software.  It'd
basically be an organized way to allow new things to work their
way into the code instead of running into these headaches.  Maybe
a "legacy terminal" is in order... something to prevent the need
for coding up "if terminal has this feature, then this, otherwise
that" all over the place in the core code.

Dan

Re: Argh: Why are arrows clipped to the graph?

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

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote:
> >
> > I once have provided a patch that worked, storing both the term boundaries
> > as they are now and the canvas size. It wasn't applied to cvs. I remember
> > that you were one of the people that complained that this was not the
> > right way to do it. But it worked.
>
> I do not recall seeing such a patch.
> Could you remind me which one that is?
> I don't see anything on SourceForge that seems to match your description.

#1104264, Fix buggy clipping of arrows in large splots
#1105611, Introduce 'set pagesize' command

> > term->xmax means the position, where the screen coordinate is 1
> > term->ymax means the position, where the screen coordinate is 1
> > term->xcanvas is the maximal screen coordinate in the canvas
> > term->ycanvas is the second maximal screen coordinate in the canvas
> >
> > This has been provided by my rejected patch, to remind you once again.
>
> I would be glad to look at such a patch.

I can imagine that these two patches do not cover all terminals, but they
at least add a feedback out of the postscript terminal.

> Too bad it means revisiting every single terminal driver.

It looks like.

I forgot to attach the example file I was talking about in the last mail.
Here it comes.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

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

Ethan Merritt wrote:
> On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote:

>>This has been provided by my rejected patch, to remind you once again.
> 
> 
> I would be glad to look at such a patch.
> As I said, I don't recall seeing anything like that.
> So you extended the TERM_TABLE entries for all terminal types to hold
> canvas size values?  That sounds like a lot more work than attempting
> to maintain the canvas size in the core code, but you may be right 
> that in the long run it is the only approach that can succeed.
> Too bad it means revisiting every single terminal driver.

This is just what I was trying to get at with my last entry!

:-)

Dan

Re: Argh: Why are arrows clipped to the graph?

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

On Wednesday 09 November 2005 02:32 pm, Harald Harders wrote:
> 
> I once have provided a patch that worked, storing both the term boundaries
> as they are now and the canvas size. It wasn't applied to cvs. I remember
> that you were one of the people that complained that this was not the
> right way to do it. But it worked.

I do not recall seeing such a patch.
Could you remind me which one that is?
I don't see anything on SourceForge that seems to match your description.


 
> term->xmax means the position, where the screen coordinate is 1
> term->ymax means the position, where the screen coordinate is 1
> term->xcanvas is the maximal screen coordinate in the canvas
> term->ycanvas is the second maximal screen coordinate in the canvas
> 
> This has been provided by my rejected patch, to remind you once again.

I would be glad to look at such a patch.
As I said, I don't recall seeing anything like that.
So you extended the TERM_TABLE entries for all terminal types to hold
canvas size values?  That sounds like a lot more work than attempting
to maintain the canvas size in the core code, but you may be right 
that in the long run it is the only approach that can succeed.
Too bad it means revisiting every single terminal driver.


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

Re: Argh: Why are arrows clipped to the graph?

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

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> On Wednesday 09 November 2005 12:49 pm, Harald Harders wrote:
> > Ethan,
> >
> > please tell me the cause why this plot file only plots two arrows in
> > total and one partly?
>
> Damn.  Well, I added a work-around for the clipping problem
> reported by Juergen Wieferink.  The problem, and the work-around
> patch, were circulated. Juergen reported that the work-around
> was successful, so I put it in cvs, but it appears to have broken
> your intended use.
>
> I will revert the (1-line) patch that fixed Juergen's problem,
> leaving us where we were before.

I have changed term_start_plot() locally to set far too big canvas
coordinates and also reverted the patch. This works for me because I am
only using Postscript-Based terminals.

> > Of course, arrows produced by a plot command are supposed to be bounded by
> > the graph boundaries. But 'set arrow' has to enable the user to put them
> > everywhere within the canvas.
>
> Yes....   But how to do this when the postscript driver does not
> tell us how big its canvas is?

I once have provided a patch that worked, storing both the term boundaries
as they are now and the canvas size. It wasn't applied to cvs. I remember
that you were one of the people that complained that this was not the
right way to do it. But it worked.

> For that matter, you yourself have been complaining about buggy
> clipping and contributing patches to fix it.  So how do you come
> around now to saying it all "worked fine"?

It used to work fine with postscript ages ago. Then, some clipping
routines were added that broke large plots. I have added a working patch.
CVS was changed again and broke even more and made my patch not working
anymore. I am not willing to do further work on this topic. I just want to
get a working gnuplot that provides the usage of the hole canvas even if
it has strange screen coordinate. And I want to preserve these strange
screen coordinates (at least as an option) since a change would break
hundreds of old scripts. (We do not have to discuss that a better size
mechanism should be added, but added, not replaced).

> I welcome your help in fixing this mess.  As we discussed,
> there needs to be a size option to the "set term post ..."
> command that lets you specify how big the bounding box is.

Yes, in addition to the current behaviour. First, the current behaviour
has to be fixed. The only way to do this is to change the meaning of some
variables and add more, unfortunately:

term->xmax means the position, where the screen coordinate is 1
term->ymax means the position, where the screen coordinate is 1
term->xcanvas is the maximal screen coordinate in the canvas
term->ycanvas is the second maximal screen coordinate in the canvas

This has been provided by my rejected patch, to remind you once again.

> Secondly, the postscript terminal calculates its own plotting
> limits internally but never tells the core code what they are.
> That needs to be fixed also.

Has been available.

> Finally, we need to agree on what is or is not enforced with
> regards to plotting outside the canvas limits.  I continue
> to maintain that this should be categorically prevented, by
> clipping to the current canvas in the core routines.

I agree.

> I.e. no more setting size greater than 1.0.

I definitely do not agree. I agree that the default way should be to have
upper right canvas corner has screen coordinates 1,1. And it is definitely
nonsense to allow reduction of size below 1.0 but to disallow an increase.
Either the upper right corner is 1,1 in all cases or everything is
allowed. Since the old and current behaviour allows sizes different from
one, this has to be preserved: To preserve the compatibility to old
scripts, the old behaviour definitely has to be preserved. For me, this
would mean that hundreds of old scripts would not work anymore.
And I am sure that many many others would have the same problem. Beware
that in Postscript this was the only possibility to produce plots in a
different size than 1,1. Thus, every postscript plot in a non-default size
would be affected.

I propose to rename the command to change the canvas size to
'set size canvas' instead of 'set size' before 'set terminal' and to
maintain the rest of the current behaviour. It would be okay to change one
single line in all my scripts.

> But even if you all over-rule me on that one, we still need
> to get the different drivers to behave the same way with regard
> to size > 1.

With 'set size canvas' this would be no problem.

> But even if you all over-rule me on that one, we still need
> to get the different drivers to behave the same way with regard
> to size > 1.

Try asdf.gpl:
In the first three examples, the canvas is changed to 1,2 and the plot
scaled accordingly, without the recent one-line-change in gnuplot (and
with ignored canvas clipping), the arrows are printed correctly. In xfig
and png, the text above screen 1 is ignored.
x11 scales the plot and and scales the screen coordinate system, but does
not change the canvas, i.e., window size.

It sounds strange that png produces a 320x480 picture after requesting a
320x240 picture. But it is consistent.

Which other terminals do not work similarly? If it is not wanted to be
able to change window sizes of interactive terminals from within gnuplot
(why not?), they have to be exceptions.

Best regards
Harald

PS: I still think that introducing absolute measures as mm, inch, etc.
would be a good idea. But before starting work on that, the old behaviour
has to be fixed.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

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

On Wednesday 09 November 2005 12:49 pm, Harald Harders wrote:
> Ethan,
> 
> please tell me the cause why this plot file only plots two arrows in
> total and one partly? 

Damn.  Well, I added a work-around for the clipping problem
reported by Juergen Wieferink.  The problem, and the work-around
patch, were circulated. Juergen reported that the work-around
was successful, so I put it in cvs, but it appears to have broken
your intended use.

I will revert the (1-line) patch that fixed Juergen's problem,
leaving us where we were before.

This is really hopeless.  The postscript driver in particular
is just plain broken.  It does not correctly report back the
current canvas size so that the core routines can do the clipping.
But if the core routines do *not* do the clipping, then other
drivers die horribly when you feed that same plot to them.

> Of course, arrows produced by a plot command are supposed to be bounded by
> the graph boundaries. But 'set arrow' has to enable the user to put them
> everywhere within the canvas.

Yes....   But how to do this when the postscript driver does not
tell us how big its canvas is?

> Before you started to fiddle about the clipping and canvas stuff,
> everything worked fine. 

No. It did not.  It is horribly inconsistent from one driver to
another.  You yourself may be happy with the way the postscript
driver works, but there is no way you can say that it is "fine"
that those same plots cause the pdf/cgm/svg/emf terminals to
segfault.  

For that matter, you yourself have been complaining about buggy
clipping and contributing patches to fix it.  So how do you come
around now to saying it all "worked fine"?

> What is the cause for these "improvements" that 
> restrain the user unnecessarily?

Trying to work around broken drivers, in particular the broken
postscript driver.  Trying to clear out long-standing bug reports
that the pdf driver error-exits when arrows extend beyond the
plot.  Trying to fix the problem that the cgm and emf drivers
also error-exit when objects of any sort are not clipped to the
canvas. Trying to make the interactive terminals like x11, and
the static terminals like postscript, act the same way so that
you can preview your plots interactively before printing them.

I welcome your help in fixing this mess.  As we discussed, 
there needs to be a size option to the "set term post ..."
command that lets you specify how big the bounding box is.

Secondly, the postscript terminal calculates its own plotting
limits internally but never tells the core code what they are.
That needs to be fixed also.

Finally, we need to agree on what is or is not enforced with
regards to plotting outside the canvas limits.  I continue
to maintain that this should be categorically prevented, by
clipping to the current canvas in the core routines.
I.e. no more setting size greater than 1.0.
But even if you all over-rule me on that one, we still need
to get the different drivers to behave the same way with regard
to size > 1.

	Ethan


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

Argh: Why are arrows clipped to the graph?

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

Ethan,

please tell me the cause why this plot file only plots two arrows in
total and one partly? One is omitted totally in the postscript terminal.
In x11 terminal, the arrows are okay.

set terminal postscript eps
set output 'asdf.eps'
set arrow from graph -0.05,0 to graph 1,1
set arrow from graph 0.0,0 to graph 1,1
set arrow from graph 0.05,0 to graph 1,1
set arrow from screen 0,1 to screen 1,0
plot sin(x)
set output
set term x11
replot
pause -1

All arrows are within the bounds of the canvas. It has to be my own
decision if I want to plot arrows placed by "set arrow" only inside the
plot or at an arbitrary position in the canvas.

Of course, arrows produced by a plot command are supposed to be bounded by
the graph boundaries. But 'set arrow' has to enable the user to put them
everywhere within the canvas.

Before you started to fiddle about the clipping and canvas stuff,
everything worked fine. What is the cause for these "improvements" that
restrain the user unnecessarily?

If you want to, add an option 'bounded <coord>' to the 'set arrow'
command, e.g.
  set arrow .... bounded graph
to define boundaries for the arrow. But this may not be the default.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: wxWidgets terminal : new round

[<tim...@en...>]

Petr Mikulik a =E9crit :

>> I am happy to provide an updated patch for the wxWidgets terminal,=20
>> which goes, as
>> usually, a little further !
>
> It doesn't ./configure:
> (...)

Thanks for the report. It's a line corresponding to a macro coming from=20
pkg-config. I suppose that my version of pkg-config handles it=20
differently. I will add a assign_some_variable_to_something to cope with =
it.

> Ad cairo and pango: they also need package pixman.

As for cairo 1.0 and maybe earlier versions, libpixman has been merged=20
with cairo. Maybe I should ask for cairo>=3D1.0.

>
> All that is OK for the very fresh linuxes (i.e., I will have to=20
> upgrade my SUSE 9.2 boxes), but what about other wx platforms (Mac,=20
> Win, OS/2)? Will it be easy to install all of these dependencies?=20
> Cannot be all that done using the base wxWidgets? From a brief look=20
> the cairo is like the wx library, but it supports less platforms --=20
> isn't this a duplicate?

I have discussed it a little with Bastian Maerkisch off-list, and I will=20
try to explain my thoughts here :

I admit that I have taken some time before deciding to use those=20
libraries. It's a choice based on the balance between functionnality and=20
portability. wxWidgets is well designed to design frames, menus, etc. in=20
a cross-platform way, but is lacking some features as far as drawing is=20
concerned. In particular, text alignment is difficult, because gnuplot=20
aks to justify vertically, and it's not easy to achieve without=20
consistent text extents functions. On the other hand, cairo provides=20
perfect drawing routines, with powerful algorythms for antialiasing for=20
instance (I may seem to insistate an anti-aliasing, but it really makes=20
plots more beautiful), and pango is well-suited for text. Moreover, I=20
have convinced myself that pango and cairo are almost as cross-platform=20
as wxWidgets.

Cairo aims to be a universal drawing library on a lot of platforms. You=20
can convince yourself if you look at mozilla which already uses cairo to=20
handle svg contents in firefox 1.5. Moreover, at this time, I use cairo=20
in a totally cross-platform way, as I draw to an offscreen buffer, and I=20
let wxWidgets do the remaining work to draw to the screen. So we just=20
have to make cairo compile under targetted platforms... It is working=20
with windows, and google seems to say it's also done already by some=20
people on OS/2.

As far as pango is concerned, I am inclined to use it because the text=20
API in cairo is limited, and the doc says it's a "toy". This doc also=20
suggests to use pango. The only platform-dependent code in pango in the=20
way it finds fonts. The rendering is done through cairo directly. Pango=20
is used by gtk+, which is known to work on windows at least (and of=20
course X11). I hope we will be able to make pango also work on OS/2...

As far as "freshness" is concerned, you're right to say that linux users=20
may need some time to have cairo (pango has settled for a longer time)=20
in their distributions. However, by the time you - gnuplot main=20
developpers - decide to make an official release, I think there's no=20
need to worry ;-) Since gnome 2.12 which depends on Cairo 1.0 was=20
released a few weeks ago, Cairo will spread much quicker...

Well, let's talk with concrete figures/examples about platforms. Three=20
days ago, Bastian Maerkisch succeeded to compile the current patch under=20
windows with msvc, with minor tweaks in my code. On my side, I managed=20
to have a working code with pango (the last sf patch uses cairo only),=20
and it suits my needs. So I have switched to windows too, and since=20
yesterday, I have been able to compile and run my code under MinGW with=20
wxWidgets, Cairo and Pango. It's working pretty well, apart from mousing=20
mode since under windows term->waitforinput doesn't seemed to be used...

As a proof ;-), here are screenshots taken from windows XP running the=20
wxWidgets terminal, using Cairo and Pango:

(test) http://tipote.free.fr/wxt_windows1.png
(pm3d) http://tipote.free.fr/wxt_windows2.png

Moreover, here is a zip archive containing gnuplot binary for windows=20
compiled statically with wxWidgets, and dynamically with cairo and=20
pango. Dlls are included so you don't need to add anything : it "should"=20
work out-of-the-box.

(3MB zipped archive) http://tipote.free.fr/Gnuplot4.1.zip

Please note that there's a bug (hopefully not related to my patch) at=20
least on my box : I have to maximize the gnuplot main window, or it will=20
crash when lauching the wxt terminal. I think it's related to debugging=20
strings that I ask to print to stderr, but I don't understand it clearly.=
..

I will appreciate any comment about this scheme.
Thank you very much for your interest in my work.

Best regards,

Timoth=E9e Lecomte

Re: maximing/resizing multiple x11: change of palette

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

>> This is an old bug (August 2004, see below). What do you think nowadays
>> about fixing it?
>
> That bug is still in there?  I thought I had programmed that just as I had
> suggested below, i.e., a linked list of colormap.  (That is, don't
> duplicate colormaps for each plot unless it actually changes.)  Maybe that
> patch is still floating around somewhere.

Yes, the bug is still present.

---
PM

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:
> This is an old bug (August 2004, see below). What do you think nowadays 
> about fixing it?

That bug is still in there?  I thought I had programmed that just as I had suggested below, i.e., a linked list of colormap.  (That is, don't duplicate colormaps for each plot unless it actually changes.)  Maybe that patch is still floating around somewhere.

I've really been set back by some computer things (got back from long break and now can't communicate IP address to/from ISP).  There are a number of gnuplot things I've been meaning to get to soon.

Dan


> 
> Petr
> 
> ***
> 
> There is a bug in the color palette treatment in the X11 terminal: when
> using multiple X11 terminals, window redraw (requested e.g. by a window
> manager) will change its palette.
> 
> Try this script:
> 
> 
> set pm3d map
> 
> set term x11 10
> set title '10 gray levels'
> set palette gray
> set palette maxcolors 10
> splot x*x
> 
> set term x11 2
> set title '2 colors'
> set palette color
> set palette maxcolors 2
> splot x
> 
> 
> Now, maximize or resize window #10 by mouse => it will change from gray map
> with 10 gray levels to color map with 2 colors.
> 
> 
> 
> 
>>> Yes, every x11 windows should have its own copy of the palette. When 
>>> there
>>> is a new (re)plot, x11 should copy the current gnuplot palette into 
>>> palette
>>> of the active window, and use that.
>>
>>
>> I don't like hacking stuff, and this may take some consideration.  I'm 
>> wondering how this should be structured, and whether we should be 
>> conservative with palette usage in order to not consume too much 
>> memory. Are palettes memory consumers?  If so, it might be wise to not 
>> save a color map with every plot.  That is, say there is a fairly 
>> large palette, and then someone creates twenty plots.  If all those 
>> plots have a similar palette, it may be an inefficient use of memory.
>>
>> Rather, it might be wise to have a linked-list of palettes.  Whenever 
>> a new palette is created, it is put in the linked list.  Then, when a 
>> palette is changed at the gnuplot command line, gplt_x11.c will search 
>> through the plot list and see if any of the plots is using the old 
>> palette.  If not, that color map can be discarded from the list.
>>
>> It sounds unnecessarily tedious, but it really does seem like the 
>> thing to do, and it actually might simplify the various uses of 
>> XAllocColor and XFreeColors.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: maximing/resizing multiple x11: change of palette

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

This is an old bug (August 2004, see below). What do you think nowadays 
about fixing it?

Petr

***

There is a bug in the color palette treatment in the X11 terminal: when
using multiple X11 terminals, window redraw (requested e.g. by a window
manager) will change its palette.

Try this script:


set pm3d map

set term x11 10
set title '10 gray levels'
set palette gray
set palette maxcolors 10
splot x*x

set term x11 2
set title '2 colors'
set palette color
set palette maxcolors 2
splot x


Now, maximize or resize window #10 by mouse => it will change from gray map
with 10 gray levels to color map with 2 colors.




>> Yes, every x11 windows should have its own copy of the palette. When there
>> is a new (re)plot, x11 should copy the current gnuplot palette into palette
>> of the active window, and use that.
>
> I don't like hacking stuff, and this may take some consideration.  I'm 
> wondering how this should be structured, and whether we should be 
> conservative with palette usage in order to not consume too much memory. Are 
> palettes memory consumers?  If so, it might be wise to not save a color map 
> with every plot.  That is, say there is a fairly large palette, and then 
> someone creates twenty plots.  If all those plots have a similar palette, it 
> may be an inefficient use of memory.
>
> Rather, it might be wise to have a linked-list of palettes.  Whenever a new 
> palette is created, it is put in the linked list.  Then, when a palette is 
> changed at the gnuplot command line, gplt_x11.c will search through the plot 
> list and see if any of the plots is using the old palette.  If not, that 
> color map can be discarded from the list.
>
> It sounds unnecessarily tedious, but it really does seem like the thing to 
> do, and it actually might simplify the various uses of XAllocColor and 
> XFreeColors.

Re: wxWidgets terminal : new round

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

> I am happy to provide an updated patch for the wxWidgets terminal, which goes, as
> usually, a little further !

It doesn't ./configure:

checking for cairo >= 0.4?0...
./configure: line 13471: syntax error near unexpected token `else'
./configure: line 13471: `  else'

Here is the snapshot:

   if test $succeeded = yes; then

   else
      { { echo "$as_me:$LINENO: error: Cairo can't be found. The wxWidgets 
terminal need it. You can disable this terminal with --disable-wxwidgets."


There should be a command in between "then" and "else".

Ad cairo and pango: they also need package pixman.

All that is OK for the very fresh linuxes (i.e., I will have to upgrade my 
SUSE 9.2 boxes), but what about other wx platforms (Mac, Win, OS/2)? Will it 
be easy to install all of these dependencies? Cannot be all that done using 
the base wxWidgets? From a brief look the cairo is like the wx library, but 
it supports less platforms -- isn't this a duplicate?

---
PM

Re: color loop for gd.trm

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

shige 11/05 2005
----------------

Thank you for your kindly reply.

| Date: Thu, 27 Oct 2005 22:49:58 +0200 (CEST)
| From: Petr Mikulik <mi...@ph...>
| To: Shigeharu TAKENO <sh...@ie...>
| Cc: gnu...@li...
| Subject: Re: color loop for gd.trm
=====
| > | It would be really great if someone unitifies the sequence for at least 16
| > | colors.
| >
| > I am sorry I can't understand many good opinions from many
| > authors well, and I seem the topic have spreaded too widely.
| 
| If someone writes down a sequence of 16, 32, or ... colors which will be the 
| same on all terminals, than we can vote to put it there.

I understand.

| > In png terminal, we can set any color sequence. And some users
| > want to know how to set it to the same one of x11 (or win) term.
| > I use the color sequence setting of png terminal, but the test
| > command don't make the same image because png terminal use
| > original color over the user setting.
| 
| Currently "many" terminals have the same color seq as the postscript 
| terminal, for at least the first "few" color items.

I understand. Certainly png terminal also has the same color 
sequence from 1 to 5 as ps terminal. 

| > Is not useful to introduce such looping option (limitation of use
| > of colors) to png terminal ?
| 
| It would be nice to have this feature consistent for all terminals.

The period of the color sequence is 9 for ps terminal, 8 for x11,
and 15 for win, these are short. But for png, it is too long 
(256?), so I think the looping option is only for png terminal at
first.

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

gnuplot-related research paper?

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

Hello, all.

Do you have any recommendation of a journal paper or a proceeding paper
in English related to gnuplot internals or gnuplot applications to visualization?

One of my students is going to work on gnuplot-related development,
and he has some assignment to read English paper related to his
research subject.
# not a manual document, a journal paper is preferable.

Sorry for an off-topic.
-- 
  KITA Toshihiro
  http://t-kita.net/

Re: set canvas, set size and clipping

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

Ethan Merritt wrote:
> You could try the following minimal patch:
>
> --- gnuplot/src/term.c  2005-10-20 09:22:25.000000000 -0700
> +++ gnuplot-cvs/src/term.c      2005-11-03 09:22:40.618537816 -0800
> @@ -1157,7 +1158,8 @@
>
>      /* Clip arrows to canvas */
>      clip_save = clip_area;
> -    clip_area = &canvas;
> +    if (!(term->flags & TERM_CAN_CLIP))
> +       clip_area = &canvas;
>
>      /* Calculate and draw arrow heads.
>       * Draw no head for arrows with length = 0, or, to be more specific,
>
>
>
> That should fix your particular plot, but I'm not sure what all the
> ramifications are for other plots.

Cool.  This works for me.  I can't see any problems with any of my
plot scripts.  But I only use the postscript terminal (eps) and I'm
not familiar with this part of gnuplot.

Thank you very much,
Juergen

Re: set canvas, set size and clipping

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

On Thursday 03 November 2005 06:51 am, Juergen Wieferink wrote:
> I'm not a fan of the old "set 
> size" kludge, but I need something like this to work.  Will there be
> some "set canvas" or size specification in "set term" in the near
> future.  

I don't know how to fix this so that everyone is happy.
Different terminal types seem to have been written with an
intrinsically different idea of what the drawable region is.

As I said before, any consistent interpretation of "set size"
that we adopt for future work will break compatibility with
one or more terminal types, because they are not consistent
with each other now.

post.trm in particular seems to be internally inconsistent.

On the one hand it accepts the "set size" command to rescale
the actual vector coordinates that it produces, but on the
other hand it does not change the values of term->xmax, term->ymax
that it reports back to the core code.  So it is impossible
to do clipping correctly because the driver itself does not
provide the necessary information.

> Is there anything I can do to help? 

You could try the following minimal patch:

--- gnuplot/src/term.c  2005-10-20 09:22:25.000000000 -0700
+++ gnuplot-cvs/src/term.c      2005-11-03 09:22:40.618537816 -0800
@@ -1157,7 +1158,8 @@
 
     /* Clip arrows to canvas */
     clip_save = clip_area;
-    clip_area = &canvas;
+    if (!(term->flags & TERM_CAN_CLIP))
+       clip_area = &canvas;
 
     /* Calculate and draw arrow heads.
      * Draw no head for arrows with length = 0, or, to be more specific,



That should fix your particular plot, but I'm not sure what all the
ramifications are for other plots.


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

set canvas, set size and clipping

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

Hi,

I know that this has already been discussed, but know I'm personally
affected... :-(

The script:

  set term post eps 18
  set output "t.eps"
  set size 1./sqrt(2.), sqrt(2.)  # <-- this causes the problem
  set arrow from graph 0, first 0.5 to graph 1, first 0.5
  plot sin(x)
  set output

doesn't give me the specified arrow.  I'm not a fan of the old "set
size" kludge, but I need something like this to work.  Will there be
some "set canvas" or size specification in "set term" in the near
future.  Is there anything I can do to help?

I ask because I am stuck with the pre-clip-patch gnuplot as long as I
don't have a workaround for the above problem.


Thanks,
Juergen

RE: Make the Xrange equal to Yrange

[Nigel N. <nN...@au...>]

On 3 Nov 2005 Hernan Gonzalo Asorey wrote

> Hi! You could do this in C or C++ using some of the avalaibles
> libraries for c-gnuplot (try to look in google), or using fopen.
> Otherwise, you can do it the same in perl, printing the gnuplot
> script, and execute gnuplot using "exec".
>=20
>=20
> On 11/2/05 <br...@ph...> wrote:
> Max Velasques wrote:
>
> > I need to make some plots in 3D where I want to let the gnuplot=20
> > to find the better range for the X and Y axis, and after that=20
> > if the Xrange is bigger than Yrange I need to set Yrange=3DXrange.
> > Or if Yrange is bigger than Xrange I need to set Xrange=3DYrange.
> >=20
> > Exist some way of doing this?
>
> No.  If you need to do this, be prepared to do it from outside=20
> gnuplot.


A few changes to the main driver in plot.c allows one to build=20
gnuplot as a library, then one can drive gnuplot from a thread=20
within the address space of a sophisticated GUI, setting ranges=20
programmatically.  Add a list box to store command history and=20
you get a native, lightweight, in-proc replacement for ye olde=20
console.  Only hitch to this solution is (was?) the existence=20
of a few globals that in effect limit the GUI to manipulating=20
a single plot.

I hope to get back to exploring this (using wxWidgets) over=20
the Christmas period.

Nigel

Re: Make the Xrange equal to Yrange

[<as...@ib...>]

Hi! You could do this in C or C++ using some of the avalaibles
libraries for c-gnuplot (try to look in google), or using fopen.
Otherwise, you can do it the same in perl, printing the gnuplot
script, and execute gnuplot using "exec".


On 11/2/05, Hans-Bernhard Broeker <br...@ph...> wrote:
> Max Velasques wrote:
>
> > I need to make some plots in 3D where I want to let the gnuplot to find=
 the
> > better range for the X and Y axis, and after that if the Xrange is bigg=
er
> > than Yrange I need to set Yrange=3DXrange.
> > Or if Yrange is bigger than Xrange I need to set Xrange=3DYrange.
>
> > Exist some way of doing this?
>
> No.  If you need to do this, be prepared to do it from outside gnuplot.
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>


--
------------------------------------------------
Lic.  Hern=E1n  Gonzalo  Asorey
Instituto Balseiro
8400 - Bariloche - R=EDo Negro
Argentina
---------------------------------------------
as...@ib...

Re: Make the Xrange equal to Yrange

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

Max Velasques wrote:

> I need to make some plots in 3D where I want to let the gnuplot to find the
> better range for the X and Y axis, and after that if the Xrange is bigger
> than Yrange I need to set Yrange=Xrange.
> Or if Yrange is bigger than Xrange I need to set Xrange=Yrange.

> Exist some way of doing this?

No.  If you need to do this, be prepared to do it from outside gnuplot.

Make the Xrange equal to Yrange

[Max V. <max...@gm...>]

Hi,
I need to make some plots in 3D where I want to let the gnuplot to find the
better range for the X and Y axis, and after that if the Xrange is bigger
than Yrange I need to set Yrange=3DXrange.
Or if Yrange is bigger than Xrange I need to set Xrange=3DYrange.

Exist some way of doing this?

Thanks!!!

Max