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

Re: Bugs in new key placement code

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:

>> The 3D plots do have such a border.  Its real shape is not a 
>> rectangle, though. It's an ellipse, inside which the plot can take 
>> different
>> orientations according to 'set view'.
> 
> Sort of; until zooming as it currently exists is factored into the 
> picture.  

That style of zooming (the <zscale> parameter of 'set view', really) is 
a horrible hack, period.  If ever we get a chance to do it, I strongly 
suggest we kill that feature and be done with it.

The cost of fixing key layout is a complete overhaul of the splot layout 
engine.  boundary3d() has become at least as complex as boundary(), 
probably more.  The key is really only a minor aspect of the real problem.

Re: feature request: a new flag for line style

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

Petr Mikulik wrote:
> Rather than adding new term APIs again, which one of the current is 
> already similar? I think that is XX_linewidth(), which changes line 
> width for the current path. Thus if it is changed to
>     XX->linewidth(double lw, t_linetype_opts *opts)

No.  Stop that. Please.

Whoever came up with the idea that an incompatible modification to an 
existing API entry was a better idea than adding a new one?  Our 
terminal API layer is expressly *designed* to support adding new 
terminal entries with very little hassle.  A change of signature of an 
existing API call is orders of magnitudes worse than just adding a new one.

Re: feature request: a new flag for line style

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

> It could be then either used as
>    plot f(x) with lines linejoin 1 linecap 1
> or
>    plot f(x) with lines linejoin round linecap rounded
> or
>    plot f(x) with lines round rounded % not the keywords for such usage
>
> or perhaps even on the style-level (so that one assigns a certaint
> type of linejoin to a certain linestyle, say "set linestyle 2 linejoin
> rounded", but I don't ask for that).
>
> If two special commands term->linejoin() and term->linecap() would be
> added, most drivers could simply ignore it, while those who care could
> take it into conideration and produce results of higher quality.

Rather than adding new term APIs again, which one of the current is already 
similar? I think that is XX_linewidth(), which changes line width for the 
current path. Thus if it is changed to
 	XX->linewidth(double lw, t_linetype_opts *opts)

then you could change whichever line properties you want. (Now you can think 
how to draw a line with a fading color :-)

---
PM

Re: line corners with terminals for vector graphics

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

>>         set pm3d interpolate nx,ny
>>
>> That does currently a bit of what you want (but not pixel-wise.)
>
> High nx & ny also mean long processing time when opening such files
> (it takes forever to zoom in and out and to move along such a page)
> and still only suboptimal results.

Yes, it eats a lot of memory.

> This makes the grid "finer", but not smooth.
>
> PostScript (and PDF) support smooth shading, which means that you can
> only define a color in the corners and PostScript will take care for
> "pixels" in the middle.

Wasn't this question discussion during the OpenGL driver? It is a bit 
similar (colors for vertices). Aha, not the question here, since we are in 
2D projections, not in 3D coordinats.

It would need to add
 	float r,g,b;
into the definition of gpiPoint.

Then there are these possibilities:
1. Add also
 	int fade_color
    into gpiPoint. Then
 	void XX_filled_polygon (int points, gpiPoint *corners)
    won't change. 
2. Change
         void XX_filled_polygon (int points, gpiPoint *corners, t_fade *fade)
    The last new param will be ignored by most terminals.
3. As term->set_color() is called before each term->filled_polygon(),
    the fading option could be passed at this point.

It is probably not difficult to implement. You can have a nice play.

---
PM

feature request: a new flag for line style

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

Hello,

I have a feature request regarding my (last?) post about
rounded/mitered corners in functions and I think that it shouldn't be
so difficult to implement.

PostScript and all related terminals (MetaPost, PStricks, all dialects
of LaTeX supported by PostScript features, ...) support different
types of "line caps" and "line joins" (see page 14 on
http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch1.ps).

(butt / round / square) line cap
(mitered / rounded / beveled) line join

The style may depend on what one wants to to, so it cannot be
generally said that one style is more appropriate than the other and
one would line to mix them as well. For example it is nice to have
sharp corners in frames, but it looks horrible to see such corners in
a plot of a wild function: one is merely looking at those artificial
corners then rather than at function values.

"plot with" currently supports many keywords: linetype, linewidth,
linecolor, (pointtype, pointsize, fillstyle, ...), but there is no
support for rounded vs. sharp line joins. Is there any chance to add
this keyword?

It could be then either used as
    plot f(x) with lines linejoin 1 linecap 1
or
    plot f(x) with lines linejoin round linecap rounded
or
    plot f(x) with lines round rounded % not the keywords for such usage

or globally as

set linejoin mitered
set linecap butt

or perhaps even on the style-level (so that one assigns a certaint
type of linejoin to a certain linestyle, say "set linestyle 2 linejoin
rounded", but I don't ask for that).

If two special commands term->linejoin() and term->linecap() would be
added, most drivers could simply ignore it, while those who care could
take it into conideration and produce results of higher quality.

The attached example roughly illustrates the differences (which are
connected to both problems: lack of support of those lines and lack of
proper support for drawing closed paths - the latter is slightly in
progress I hope), you may open the file with both: a text editor and
GhostView.

Thank you,
    Mojca

Re: line corners with terminals for vector graphics

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

On 2/5/06, Petr Mikulik wrote:
> > implement that. Even more fancy method would be to determine the color
> > of each pixel separately (by calculating normal vector & consequently
> > the color for each pixel separately), but the first method would be
> > far enough, the second one would take too much effort for too little
> > gain in comparison to the first method.
>
> See
>         set pm3d interpolate nx,ny
>
> That does currently a bit of what you want (but not pixel-wise.)

This makes the grid "finer", but not smooth.

Consider my question equivalent to "can we draw a circle" if the
program is only able to draw straight line segments. It's not the
point in dividing lines into shorter segments, but in the proper
support for splines or whatever. No, I didn't mean that gnuplot should
support splines (although it would be nice to) since a line can be
divided into segments which are short enough, but in 2D plots the
number of possible divisions in one direction is limited.

PostScript (and PDF) support smooth shading, which means that you can
only define a color in the corners and PostScript will take care for
"pixels" in the middle.

See the example on http://pub.mojca.org/ps/smooth/. It's a bad
approximation of a rainbow, but a good approximation of what gnuplot
could be capable of with probably not that much effort. No matter how
much you zoom in or out, you won't notice sharp steps.

High nx & ny also mean long processing time when opening such files
(it takes forever to zoom in and out and to move along such a page)
and still only suboptimal results.

Mathematica can't do that, but gnuplot could be better.

Mojca

Re: Bugs in new key placement code

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

Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>=20
>> I don't see how you *could* unify the 2D key and the 3D key.
>=20
>=20
> That should actually be quite simple.  The reason it's not is that the=20
> 3D code and the 2D code are currently a *lot* more different than they=20
> really have to be.
>=20
>> They are intrinsically different.  The 2D case has a fixed
>> plot border (not the canvas border, the plot border) within
>> which we normally position the key.  3D plots *have* no
>> such border except in the special case of `set view map`.
>=20
>=20
> The 3D plots do have such a border.  Its real shape is not a rectangle,=
=20
> though. It's an ellipse, inside which the plot can take different
> orientations according to 'set view'.

Sort of; until zooming as it currently exists is factored into the pictur=
e.  Then the border is rectangular and lines near the border behave stran=
gely.

> Yes, there are a lot of things going on there that range from the very=20
> strange to the outright buggy.  The fact that the relevant function,=20
> boundary3d(), is so much shorter than its 2D cousin boundary(), even=20
> though its job really is a good deal more complicated, serves as a=20
> warning that much ground is left to be covered here:

Exactly.  Couldn't have said it better.

 no space is=20
> reserved for tics, ticlabels, axis labels, the time stamp; the t, b and=
=20
> r margins are ignored, as well as 'set offsets'.
>=20
> There are two obvious choices for the rectangle with respect to which=20
> the key positioning should work:
>=20
> * struct plot_boundary
>=20
> * the 4/7 downscaled one that contains the graph in 'set view 0,0'
> position.
>=20
> The current code uses struct plot_boundary, which leaves the key outsid=
e
> the actual plot area simply because the elliptical area used by actual=20
> data doesn't reach all the way into the corners of the rectangle.

Yes, but just barely.  The balance doesn't look good.

Dan

Re: Thoughts about gnuplot license and copyrights

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

Dear gnuplot developpers,

I have been very impressed by the overall enthusiasm last month about=20
the future of gnuplot (42 messages !). The discussion has been=20
constructive. Some time went by, and I think it would be interesting to=20
sum up the points of view, and probably ask to Thomas Williams what *he*=20
thinks of this.

So the main issue is that the current license drives gnuplot to a=20
"single point of failure", because releases rely on the agreement of=20
copyright holders, who will be gone one day.

The proposed solutions are, from the easier to the most radical :

* don't do anything, and wait to see gnuplot die in the more-or-less=20
long run

* change the license by contacting all copyright holders.
What license ? A license just permissive enough to make releases allowed=20
without relying on a fragile individual :
    - a modified gnuplot license that names a legal body, a group of=20
people, like a foundation, which is allowed to make releases,
    or
    - gpl, because it is "standard", well-known, written by people aware=20
of the laws, or
    or
    - another appropriate license.

* transfer the copyrights to a legal body, existing or to be created,=20
immortal by design, which will be the group allowed to make releases,=20
but also to enforce the license if needed, and eventually to raise funds=20
or to register and enforce a trademark

All of the solutions that really handle gnuplot's future (all but the=20
first) are legally viable and imply a decision from the copyrights' holde=
rs.

Finally, one person has remained definitely silent for this discussion :=20
Thomas Williams. Lars, can you try to ask him for his position about the=20
license issue, as you proposed in one of your messages ?

Thank you very much for your consideration.

Best regards,

Timoth=E9e Lecomte

Re: Bugs in new key placement code

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

Ethan A Merritt wrote:
> I don't see how you *could* unify the 2D key and the 3D key.

That should actually be quite simple.  The reason it's not is that the 
3D code and the 2D code are currently a *lot* more different than they 
really have to be.

> They are intrinsically different.  The 2D case has a fixed
> plot border (not the canvas border, the plot border) within
> which we normally position the key.  3D plots *have* no
> such border except in the special case of `set view map`.

The 3D plots do have such a border.  Its real shape is not a rectangle, 
though. It's an ellipse, inside which the plot can take different
orientations according to 'set view'.

The 2D layout of 3D plots currently works like this:

* 'set size' & 'set origin' define a rectangular area on the page.
This is what the 4.0 'help glossary' calls "a plot".

* Inside this rectangular area, there's a "canvas", stored in struct 
plot_boundary.  It's margins relative to the plot area are controlled by:

   + left:   'set lmargin' or a default (2 chars + 1 tic),
   + right:  (2 chars + 1 tic) + ('set key outside'? key box width)
   + bottom: 2.5 chars + 1 pixel(?) + ('set key below'? key box height)
   + top:    'set title' + 1.5 chars + 1 pixel(?)

* the center of this canvas becomes the center of the 3D output
   (xmiddle, ymiddle).  The design size of the 3D graph box is 1/sqrt(3)
   (approximated as 4/7) of the canvas (--> xscaler, yscaler), but the
   actual area occupied by the data is a circle enscribed into the
   plot_boundary rectangle.  This is the rectangle filled with data in
   'set view 0,0,1,1' splots.  In other orientations, some parts of
   the box will be outside this region, but they'll always stay
   inside the plot_boundary region above.

* 'set view' controls the mapping from normalized 3D graph coordinates
onto this 2D region.

Yes, there are a lot of things going on there that range from the very 
strange to the outright buggy.  The fact that the relevant function, 
boundary3d(), is so much shorter than its 2D cousin boundary(), even 
though its job really is a good deal more complicated, serves as a 
warning that much ground is left to be covered here: no space is 
reserved for tics, ticlabels, axis labels, the time stamp; the t, b and 
r margins are ignored, as well as 'set offsets'.

There are two obvious choices for the rectangle with respect to which 
the key positioning should work:

* struct plot_boundary

* the 4/7 downscaled one that contains the graph in 'set view 0,0'
position.

The current code uses struct plot_boundary, which leaves the key outside
the actual plot area simply because the elliptical area used by actual 
data doesn't reach all the way into the corners of the rectangle.

Re: Bugs in new key placement code

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

> The change as far as generating the 3d plot should be trivial.  I'd hope that 
> all one need do is change the settings for the limits the 3d code uses.
>
> Now, as for zooming, I think it would be nice for the mouse to act as it 
> currently does, but don't allow plotting outside the plot border (the dotted 
> line) even when zooming.  (A nicely place min or max should fix that problem 
> where zooming in too far causes some lines to alias into different 
> directions.)

That would be very useful to use rmargin for extending the "margin" for the 
key and the colorbar as your figure shows. Currently this is not possible, 
which does inherent problems how to draw colorbar with long tic labels and 
a title. This would really need to be fixed before 4.2 as we want users 
don't draw beyond the plot canvas.

---
PM

Re: Bugs in new key placement code

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

Ethan A Merritt wrote:
> On Monday 06 February 2006 11:00 pm, Daniel J Sebald wrote:
> 
>>The question is:  Put effort into touching up the 3d keys, 
>>or put effort into unifying plot layout, effectively fixing 3d keys? 
> 
> 
> I don't see how you *could* unify the 2D key and the 3D key.
> They are intrinsically different.  The 2D case has a fixed
> plot border (not the canvas border, the plot border) within
> which we normally position the key.  3D plots *have* no
> such border except in the special case of `set view map`.

I think of the plot, 2d or 3d, as having an inherent rectangular space in which it can be plot (more on zooming later).  For the 3d plots currently, I assume the canvas border is the allotted region.  In the attached PNG I've attempted to illustrate.  The solid line is what I think you are calling canvas border.  The top graph shows the plot border the same as the canvas border.  The bottom graph shows that room is first made for the key and/or colorbar.  The plot border is shrunk and consequently the 3d plot is shifted to the left making the layout look better than having the color bar in the plot itself.

A person could always leave out the margin and manually place the key if he or she wants the plot to occupy as much space as possible.

The change as far as generating the 3d plot should be trivial.  I'd hope that all one need do is change the settings for the limits the 3d code uses.

Now, as for zooming, I think it would be nice for the mouse to act as it currently does, but don't allow plotting outside the plot border (the dotted line) even when zooming.  (A nicely place min or max should fix that problem where zooming in too far causes some lines to alias into different directions.)

You've talked in several instances now of plot and canvas border.  Formalizing that would be nice.  (And sub-borders for for multiplot?  Don't know.)

In addition, if we go with the idea that there is no plot border for 3d and no margins, then the solution is not to fix the 3d key example you've given, but to disallow the words (rmargin, bmargin, etc.) in the case of 3d placement because they make no sense.

Dan

Re: Bugs in new key placement code

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

On Monday 06 February 2006 11:00 pm, Daniel J Sebald wrote:
> 
> The question is:  Put effort into touching up the 3d keys, 
> or put effort into unifying plot layout, effectively fixing 3d keys? 

I don't see how you *could* unify the 2D key and the 3D key.
They are intrinsically different.  The 2D case has a fixed
plot border (not the canvas border, the plot border) within
which we normally position the key.  3D plots *have* no
such border except in the special case of `set view map`.

So even if you unified many of the 2D and 3D routines,
I think you would still need two parallel bits of code for
key placement.

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

Re: Bugs in new key placement code

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

Ethan A Merritt wrote:

> 
> By which I mean that the key box got smaller.
> It was originally the correct size to contain the
> set of titles.  But for some reason this command
> causes it to shrink vertically, so the final title
> now appears below the key box. That's got to be
> a bug, pure and simple.  Once we figure out how big
> the box needs to be, it should be drawn at that size
> no matter where on the graph window it sits.

Yes, I saw that.  I could make a guess why the box is too small... I don't know, maybe because the way things are laid out the key code thinks there isn't much room so chooses a small box to fit within its allotted space.


>>And now it is the same sort of thing with margin key placement in 3d. 
> 
> 
> I'm not worrying overly much about the placement.
> It's the fact that the *size* is not calculated consistently.
> Most of the time it is correct, but some key placement options
> seem to break the size calculation.

In 3d.  I've tried this for "plot" and the box is correct.

The point is, there are two sets of key code.  That for 3d needs some fixes.

>>Because my personal feeling is that 2d/3d should be laid out the same in 
>>terms of margins, so that code should be unified.
> 
> 
> I disagree, but not strongly.  

Why?

> Anyhow, that's not what I'm complaining about.

I know.  But I'm inquiring with people if from a coding standpoint they feel there should be two different sets of layout or just one.  (I think Hans pointed out a long time ago that graph3d.c came from graphics.c by tagging a "3d" to most of the functions within.)

If someone can argue the layout should be kept separate, fine.  But I can't see a good reason to do so, and the points of consistency (for the user's sake) and ease of maintaining code (for the programmer's sake) are what I'm emphasizing.

The question is:  Put effort into touching up the 3d keys, or put effort into unifying plot layout, effectively fixing 3d keys?

I'm guessing Ethan would rather see those 3d keys fixed than attempt to unify 3d/2d key code.

> 
> Since the time I originally sent this message, the centering code
> seems to have been fixed.  Intentionally or unintentionally - I don't know.
> But the incorrect centering I pointed to originally is no longer there
> in current cvs.

OK.

Dan

Re: Bugs in new key placement code

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

On Sunday 05 February 2006 05:21 pm, you wrote:
> Alright, I've had a look at this issue.  
> I'm not so sure these are bugs in the new key placement code.  
> Rather, they are "bugs" in the old code, especially the 3d plots...  

Huh?  I think you are not focusing on the same issue
that I am.  Or possibly you are not even seeing the problem.
I'm not talking about the margin spacing at all.
Yeah, it's imperfect, but I don't care so much about that.
What I'm pointing out as a bug is ...


> >   set key box title "Foo"
> >   splot 1,2,3,4,5
> > 
> > Everything is OK so far.  Now try:
> > 
> >   set key rmargin
> >   replot
> > 
> > That's not what I expected, but let's proceed.
> > 
> >   set key tmargin
> >   replot
> > 
> > Huh?  The box is no longer correct.

By which I mean that the key box got smaller.
It was originally the correct size to contain the
set of titles.  But for some reason this command
causes it to shrink vertically, so the final title
now appears below the key box. That's got to be
a bug, pure and simple.  Once we figure out how big
the box needs to be, it should be drawn at that size
no matter where on the graph window it sits.

  
> And now it is the same sort of thing with margin key placement in 3d. 

I'm not worrying overly much about the placement.
It's the fact that the *size* is not calculated consistently.
Most of the time it is correct, but some key placement options
seem to break the size calculation.

> Because my personal feeling is that 2d/3d should be laid out the same in 
> terms of margins, so that code should be unified.

I disagree, but not strongly.  
Anyhow, that's not what I'm complaining about.

Since the time I originally sent this message, the centering code
seems to have been fixed.  Intentionally or unintentionally - I don't know.
But the incorrect centering I pointed to originally is no longer there
in current cvs.

> I'm not offering or committing to do any of this right now in light of
> the conversation of the last month regarding the future of gnuplot.  

Oh?  I didn't think much new came out of that discussion.
We're still in exactly the state we always were.
Except that we are now, I hope, much closer to a 4.2 release :-)

[gotta go back to emptying out that bug list]

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

Re: Bugs in new key placement code

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

Alright, I've had a look at this issue.  I'm not so sure these are bugs in the new key placement code.  Rather, they are "bugs" in the old code, especially the 3d plots...

Ethan Merritt wrote:
> Try the following:
> 
>   set key box title "Foo"
>   splot 1,2,3,4,5
> 
> Everything is OK so far.  Now try:
> 
>   set key rmargin
>   replot
> 
> That's not what I expected, but let's proceed.
> 
>   set key tmargin
>   replot
> 
> Huh?  The box is no longer correct.
> 
>   set key lmargin
>   replot
> 
> Seems to be a no-op. Key is still broken.
> 
>   set key title "A much longer title"
>   replot
> 
> And now it's obvious that the title centering is not
> correct, either.
> 

The reason none of this makes sense is an issue that goes way back.  I recall Hans saying something about "we have to fix that" in an exasperating tone regarding the fact that 3d plots never really have had a margin.  (Take a close look at the layout when typing the above commands... the plot itself never moves.)  The color box was always plopped down on the right edge, but no room was ever left for it, so the plot looked unbalanced.

And now it is the same sort of thing with margin key placement in 3d.  I realize it could be made a tad better than it is, but I probably figured at the time to not even touch 3d layout until the issue of margins was worked out.  Let it be because anything I would have done would probably have not agreed with someone.  That, and the fact that I think it would have been wasted coding effort on my part in the long run.

The issue, I suppose, is that 3d plots have interactive rotation and zoom.  That operation might conflict with any key, color box, etc.

Why wasted coding effort?  Because my personal feeling is that 2d/3d should be laid out the same in terms of margins, so that code should be unified.  From what I recall, I cleaned up 2d layout nicely, so my suggestion would be to somehow move that to a file or organize it in a way that can be reused by both 2d and 3d.  There's no way I could have pulled that off without complaints.

I guess I'm pleading no quick fix here.  Who want's to maintain two different sets of key code?  But it will require someone with a big block of time.  (More a little further down.)

So, I think the group has to decide:  revamp?  Or band-aid the 3d code?


> Now let's start again (2D this time)
> 
>   reset
>   set key box title "A much longer title"
>   plot 1,2,3,4,5
> 
> In 2D the title is centered, but the box is not adjusted
> to fit it.

OK, so I think this is the only "bug".  (2d key behavior is all that concerns me right now.)  I can't recall changing anything in the interior of the key, so all the things about Left/Right space etc. I'm not sure I've influenced.  Maybe I overlooked something and changed interior behavior, but not sure.

Anyway, attached is a line change that will put a little more space outside the title.  Is that what you were concerned about Ethan?

But notice that this still doesn't fix matters.  Try these lines:

  set key box title "A much longer title"
  plot 1,2,3,4,5

  set key Left
  replot

Still no space at left of sample text.  One could go tweaking that, but it's liable to break something.  Recall we have instances of multicolumn keys now.  What makes the code difficult to read is all the constants "+ 2" here, "- 1.5" there.  These should all be defines or a variable.

Perhaps there should be a variable that controls the amount of space surrounding things.  I don't know.

My suggestion would be:

1) Make a committment to combining plot layout for 2d and 3d into the same reusable code.  Otherwise, it's a double migraine.

2) Restructure the C files and code using the 2d margins and key as the initial start.  Then start looking to make interiors of keys better and more versatile.

3) There is now multicolumn keys, sort of.  Perhaps formalize that and also maybe formalize multiple key concept.  Draw up an Xfig diagram that can be converted to EPS or combine tex/PS showing all the elements of key and key layout; the little spaces here, the number of columns there, alignment, etc.  (I.e., do the documentation first... basically a diagram similar to the page layout parameters of Figure C.3 of appendix C.5.3 in Lamport's LaTeX book.)  Submit that to the list for agreement.

4) Code away to meet those definitions, which basically would mean replacing all the "+ 2", "0.5 *", etc. with definitions as shown in the documentation from 3.

5) Maybe add a Center to Left/Right/Center.  In the "A much longer title" example Ethan gave, neither the Left nor the Right looks particularly great.

Without a solid concept of keys and layout, it's just shuffling cards around in the house.  It would have to be a summer project, but I'm not offering or committing to do any of this right now in light of the conversation of the last month regarding the future of gnuplot.

Dan

Re: Problem with help file

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

Prof. Dr. Thomas Burkhardt wrote:
> When I try to use the help from wgnuplot under windows 2000 
> (wgnuplot.hlp?), I always get a message from winhlp32.exe telling me 
> that wgnuplot.hlp would have been written in a language that is not 
> supported. What is going wrong?

You downloaded the wrong binary package.  The first one we ever uploaded 
for 4.0 had this bug.  We replaced it by a fixed version within a day, 
but some of the download sites never picked up the update.  Download 
from the SourceForge.net "Files" page for gnuplot, and it'll work.

Problem with help file

[Prof. D. T. B. <tb...@un...>]

When I try to use the help from wgnuplot under windows 2000=20
(wgnuplot.hlp?), I always get a message from winhlp32.exe telling me=20
that wgnuplot.hlp would have been written in a language that is not=20
supported. What is going wrong? Your help is very much appreciated!=20
Thanks a lot!
--=20
-------------------------------------------------------------------------=
------------
Prof. Dr. Thomas Burkhardt
Finanzierung, Finanzdienstleistungen und eFinance
Fachbereich 4: Institut f=FCr Management
Universit=E4t Koblenz-Landau, Campus Koblenz
Haus: Universit=E4tsstr. 1, D-56070 Koblenz
Post: Postfach 20 16 02, 56016 Koblenz
Tel. 0261/287-2855, Fax: 0261/287-100-2855
e-mail: tb...@un...

Sekretariat: Marlene G=F6bel
e-mail: mg...@un...
Tel.: +49-0261-287-2866, Fax:  +49-0261-287-100-2866

Re: line corners with terminals for vector graphics

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

On Saturday 04 February 2006 07:50 pm, Mojca Miklavec wrote:
> On 2/5/06, Hans-Bernhard Br=F6ker wrote:
> >
> > We don't need a term->polyline().  The only thing needed to complete
> > the existing API in this area would be a term->closecycle() or some
> > such, to distinguish between open and closed polylines.

We don't need that either.
I've just placed a patch for post.trm on SourceForge that simply
keeps track of where the current polyline started. If that point is
reached again, then the polyline is closed off with "closepath stroke"
rather than "<xend> <yend> lineto stroke".

Seems to work fine, but have a look and see if you can improve it
further.    As noted in a code comment, it seems to have the side
effect of triggering a subsequent "1.000 UL".
Harmless, but unnecessary.

> I thought this was a valid sequence of commands
>    move(0,0)
>    vect(1,2)
>    put_text(3,3,"abc")
>    vect(0,1)

It is a legal sequence of commands, although I don't think it
can be generated by any existing operation in gnuplot.
The second vect() command above will start a new polyline whose
origin is somewhere in the string.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: line corners with terminals for vector graphics

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

On 2/5/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > At the very beginning I wanted to ask for an additional function
> > (polyline), but then I figured out that the Metapost terminal has a
> > nice workaround for it: it always saves the last point and if the next
> > line continues in the same point (without changing line type or color
> > inbetween), it draws a continuous path rather than two separate lines.
>
> There's no sane reason for implementing any "workaround" for this ---
> the terminal driver API already *has* a polyline function.  That's why
> we have two functions, term->move() and term->vect(), instead of a
> single term->draw_line(from,to).  Each term->move() conceptually starts
> a new polyline, each term->vect() extends it by one leg, any other call
> but term->vect() ends it.
>
> We don't need a term->polyline().  The only thing needed to complete
> the existing API in this area would be a term->closecycle() or some
> such, to distinguish between open and closed polylines.

Thanks. It should also be described in the documentation that way.
It's not mentioned anywhere that every command other than vect() ends
a line. I thouht that
    move(0,0)
    vect(1,2)
    linetype(2)
    vect(0,1)
or
    move(0,0)
    vect(1,2)
    put_text(3,3,"abc")
    vect(0,1)
was a valid sequence of commands (according to your description it's
not). I followed the code sample in metapost.trm, which handles that
case "properly" (breaks the line in first case and continues the line
in the second case). Also,
    move(0,0)
    vector(1,1)
    move(1,1)
    vector(2,1)
would draw a continuous line in metapost rather than two separate ones.


However, move() and vector() lead to much more dirty code in terminals
in comparison to polyline(). Move starts the line, which is OK, but
EVERY other command has to start with
    if(we're inside a line)
        finish that line first

After some thinking I figured out that polyline() instead of move()
and vector() would be less memory-efficient for extremely long lines,
but at least an "endline(bool closed)" could help cleaning up some
code. endline(false) would reduce the need for an additional "if" in
just about every function and endline(true) would be a magic
combination which would fix the reported "bug" without additional
trickery in the terminals.

(I'm sorry for a sking a stupid newbie question: how many bytes can be
assumed for int? IE: may xmax and ymax exceed 32000?)

Thanks,
    Mojca

Re: line corners with terminals for vector graphics

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

Mojca Miklavec wrote:
> On 2/5/06, Daniel J Sebald <dan...@ie...> wrote:
> 
> 
> Didn't try it now, but I guess it only draws solid polygons and
> simulates 3D. But I was asking for the what you describe as "to using
> elements that have shading within as opposed to having the monocolored
> elements". This is not that difficult to do in PostScript/PSTricks and
> could be also done in ConTeXt (based on metapost). PDF supports that
> as well, but might not be trivial with the current driver (don't know
> how it works).

It probably isn't a difficult thing to write a routine that does that.  I think Ethan's idea may have been to use such a routine that already exists in library and then utilize that somehow.  The difficult thing with gnuplot is usually figuring out a nice generic method that all terminals can use.

> With quite some effort, one could do something like "ray-tracing" (I
> don't know how it's called) and determine the color for each pixel
> separately by determining the normal vector to the surface in the
> point to which this pixel "corresponds to" (sorry, I guess that nobody
> understands that sentence).

Well, my understanding is that ray tracing is a very computationally intensive method of shading that mimicks real-world objects by bouncing light rays, either from some light source or the reverse direction.  I think the best that could be achieved with gnuplot might be some kind of faux lighting assuming the light source is at an infinite point in space.  But really, to have shading commands and such in gnuplot doesn't seem approrpriate.

Dan

Re: Strange behaviour of "set xtics"

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

Ethan A Merritt wrote:
>> Petr Mikulik wrote:

>>> but later 'frac' and 'zvalue' are used instead of <level>. I think it 
>>> should be changed to
>>>
>>>        set ticslevel <frac>
>>>        set xyplane <frac>
>>>        set xyplane at <zvalue>

> I will change the documentation, if people think that <frac> and <zvalue>
> are clearer.

Clarity is not the main issue, consistency is.  The same names used for 
<arguments> in the Syntax overview are supposed to be appear in the 
longhand explanation, so people know what to put where.   That's what 
they have <names> for in the first place.

Re: line corners with terminals for vector graphics

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

Mojca Miklavec wrote:
> At the very beginning I wanted to ask for an additional function
> (polyline), but then I figured out that the Metapost terminal has a
> nice workaround for it: it always saves the last point and if the next
> line continues in the same point (without changing line type or color
> inbetween), it draws a continuous path rather than two separate lines.

There's no sane reason for implementing any "workaround" for this --- 
the terminal driver API already *has* a polyline function.  That's why
we have two functions, term->move() and term->vect(), instead of a 
single term->draw_line(from,to).  Each term->move() conceptually starts 
a new polyline, each term->vect() extends it by one leg, any other call 
but term->vect() ends it.

We don't need a term->polyline().  The only thing needed to complete
the existing API in this area would be a term->closecycle() or some 
such, to distinguish between open and closed polylines.

Re: line corners with terminals for vector graphics

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

Mojca Miklavec <moj...@gm...> wrote:

> > Or these call sites could also use the method above --
> > draw a polygon boundary as N + 1/2N segments and let the
> > driver merge these into a polyline if possible.

I have decided that I do not like this option, because it
will look bad on pen plotters.  Of course maybe no one has
a pen plotter any more...

> In the terminal I'm currently writing (which is almost the same as
> metapost) I did the same for the first & last point: I save the first
> point and when I draw the next line segment I check if the last point
> is the same as the first one. In that case I "close" the line. There
> might be exceptions to this rule of course where the results are only
> suboptimal, but this will at least draw the border properly in 99%
> cases.

I have been trying the same thing in the PostScript driver.
It works fine for rectangles, but I must have failed to consider
some reasonably common case because several of the demo plots
no longer work correctly.  If I get the demos working 100%, I'll put
the patch on SourceForge so everyone can try it out.

> However, adding a new function like polyline(int npoints, int
> points[n][2], bool closed) would still be a cleaner solution. If a
> driver doesn't support it, it can still be drawn with n separate
> lines.

That assumes the points are all known in advance of the driver call.
That is probably always true for rectangles, but not for a general
closed curve plot.  So we would have to add a layer in the core code
that accumulates a complete curve.  I think.  Maybe there's a clever
way around it.   But in any event, I suspect that adding new core code
and adding a new driver entry to N drivers is going to be more work
than teaching the few drivers who care to recognize short closed
paths on the fly.

> I still have to study the 3d drawing capabilities in gnuplot, but I
> have a feeling that there's no function yet for drawing a polygon with
> colors specified in the corners, so that smooth shading could be used
> to get proper feeling of 3d (without "annoying" steps in shading). See
> http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch14.pdf for example.

This has come up before, although there wasn't much discussion.
To the best of my knowledge, only the svg driver could easily support
this.  It would be possible in TrueColor png and jpeg output, but it
would require adding some pretty messy code to gd.trm. I did look into
that at one point, and decided it was far too much trouble. I am not
enough of a PostScript guru to know how one might do it there.

> With quite some additional effort the bitmap terminals could be
> improved in that sense as well (each pixel could have the "proper"
> color; not really ray-tracing, but something similar).

I am CC'ing Dan Sebald on this one, because it occurs to me there's
an off chance that one could implement this by piggy-backing on his
"with rgbimage" code.  It might be possible to use libgd
to create the desired gradient-filled rectangle in memory, and then
feed that pixmap to any driver with a term->image entry point.

Daniel, do you think that might work?  If so, it would have the
major advantage of being an almost entirely separate code module.
If we're lucky, we might not have to touch individual drivers at
all.


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

Re: line corners with terminals for vector graphics

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

On 2/2/06, Ethan A Merritt wrote:
> On Wednesday 01 February 2006 06:22 pm, Mojca Miklavec wrote:
> >
> > I experienced some problems with MetaPost driver recently when drawing
> > a function similar to sin(1000*x), ie. with sharp turns up and down.
> > MetaPost draws a continuous line instead of isolated line segments,
> > which is OK and even much better in most cases. But it uses "sharp"
> > corners (instead of the rounded ones) which then stick out way above
> > and below the line where the function passes through. (I have to check
> > how this is solved in PostScript.)
>
> Postscript has a command "setlinejoin" which selects either
> mitred, rounded, or beveled corners.
>         http://www.capcode.de/help/setlinejoin
>
> Gnuplot's postscript driver allows you to select either
> "rounded" or "butt" (really mitred) in the "set term" command.
> Mike Sutton recently contributed an equivalent for the png/gif/jpeg
> driver.  The plan is to add the same option to additional terminal
> types if they can support it.

(Metapost should support that option too: currently it's hardcoded.)

One of my question was also: is it possible to set different linejoin
for different elements? It's for example best if rectangular elements
keep "mitered" linejoins, while function could be drawn with rounded
linejoins if needed. This is one of the things that a terminal can't
do. A terminal can solve the problem with closed paths (below), but
can't guess if the line being drawn is a function or a frame (unless I
try to draw the lines of type -1 and -2 with mitered linejoin and the
rest with the rounded ones).


On 2/2/06, Ethan Merritt wrote:
> On Thursday 02 February 2006 10:44 am, Hans-Bernhard Br=F6ker wrote:
> > Ethan Merritt wrote:
> > > I understand.  However, if you choose
> > >     set term post rounded
> > > then this corner is rendered identically to the others.
> > > This is one advantage of choosing the rounded joins and caps.
> >
> > It's also a rather indirect approach that only fixes the symptom, not
> > the problem.  Why should people be restricted to using round joins
> > just to get a non-silly display of the graph box?
>
> [shrug]
> Different problems may require different solutions.
>
> I took Mojca's question to be along the lines of "what could the
> metapost driver do differently?".  So I gave a driver-oriented
> answer.  For the very specific case of drawing the plot border,
> we could of course have the core code draw 1 + 1/8 of the
> way around the perimeter, which should give a clean join at
> all 4 corners.  That change would not help any other line joins,
> however.
>
> We could think about adding a new terminal entry
> point term->polyline(), which could handle this case and also
> draw nice boundaries around term->filled_polygon() areas.
> Or these call sites could also use the method above --
> draw a polygon boundary as N + 1/2N segments and let the
> driver merge these into a polyline if possible.
>
> On the other hand, even if we did this the joins at
> the endpoints of separately drawn vectors would be a problem.
> E.g. when 2 or 3 zero-axis lines meet at the origin.
> E.g. when different segments of a continuous line plot are
>         drawn separately so that they can have different colors.

If three lines of different color meet in the same point, there's no
solution anyway, I'm afraid.

At the very beginning I wanted to ask for an additional function
(polyline), but then I figured out that the Metapost terminal has a
nice workaround for it: it always saves the last point and if the next
line continues in the same point (without changing line type or color
inbetween), it draws a continuous path rather than two separate lines.

In the terminal I'm currently writing (which is almost the same as
metapost) I did the same for the first & last point: I save the first
point and when I draw the next line segment I check if the last point
is the same as the first one. In that case I "close" the line. There
might be exceptions to this rule of course where the results are only
suboptimal, but this will at least draw the border properly in 99%
cases.

However, adding a new function like polyline(int npoints, int
points[n][2], bool closed) would still be a cleaner solution. If a
driver doesn't support it, it can still be drawn with n separate
lines.

I still have to study the 3d drawing capabilities in gnuplot, but I
have a feeling that there's no function yet for drawing a polygon with
colors specified in the corners, so that smooth shading could be used
to get proper feeling of 3d (without "annoying" steps in shading). See
http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch14.pdf for example.
Not many terminals could make use of it (perhaps PostScript-based
ones, PDF and ConTeXt if author of ConTeXt's adds some trickery), but
I guess that the source wouldn't need so many changes to calculate the
color in edges of polygons.

With quite some additional effort the bitmap terminals could be
improved in that sense as well (each pixel could have the "proper"
color; not really ray-tracing, but something similar).

Thanks a lot,
    Mojca

Re: Strange behaviour of "set xtics"

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

On Saturday 04 February 2006 03:33 pm, Hans-Bernhard Br=F6ker wrote:
> Petr Mikulik wrote:
> > I considered "unset tics": tics are not drawn, but nothing else changes=
,=20
> > so neither the base plane.=20

When you "unset title", extra vertical space above the plot is not reserved.
When there is no xlabel, extra vertical space below the plot is not reserve=
d.
When there is no ylabel, extra space to the left of the plot is not reserve=
d.
So logically when there is no base plane, there should be no space reserved
for it.

> > but later 'frac' and 'zvalue' are used instead of <level>. I think it=20
> > should be changed to
> >=20
> >        set ticslevel <frac>
> >        set xyplane <frac>
> >        set xyplane at <zvalue>
>=20
> Ethan: since it appears you introduced 'set xyplane', I think this up to=
=20
> you.

I will change the documentation, if people think that <frac> and <zvalue>
are clearer.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742