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

Simple question

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

This works:

gnuplot> system "date"; plot x; system "date"
Wed May 30 01:47:09 CDT 2007
Wed May 30 01:47:09 CDT 2007

Why not this?

gnuplot> system "date"; load 'mixture.gp'; system "date"
Wed May 30 01:48:13 CDT 2007
                                            ^
          warning: ignoring rest of line

Simple answer?

Re: Hidden3d Bug Fix

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

Ethan A Merritt wrote:
> On Monday 28 May 2007 21:10, Daniel J Sebald wrote:
> 
>>OK, summary:
>>
>>1) The alternative line removal algorithm patch fixes the bits and pieces 
>>problem reported by Thomas.
> 
> 
> I see a patch "hiddenlines_djs_29may2007.patch". 
> Is that the one you are referring to here?

Yes.

>>2) The degenerate polygon patch fixes the red/green (inside/outside) problem 
>>also reported by Thomas.
> 
> 
> This is "degenpoly_djs_29may2007.patch", right?

Yes.

Dan

Re: Hidden3d Bug Fix

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

On Monday 28 May 2007 21:10, Daniel J Sebald wrote:
> OK, summary:
> 
> 1) The alternative line removal algorithm patch fixes the bits and pieces 
> problem reported by Thomas.

I see a patch "hiddenlines_djs_29may2007.patch". 
Is that the one you are referring to here?

> 2) The degenerate polygon patch fixes the red/green (inside/outside) problem 
> also reported by Thomas.

This is "degenpoly_djs_29may2007.patch", right?

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

Re: Hidden3d Bug Fix

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

I placed another hidden3d line bug fix on SourceForge, [1727198] Hidden lines: 
Degenerate polygons creating problems.  This is the source of the inside/outside 
line problem.  Current CVS tries to make something meaningful for a plane 
equation out of two points and consequently would get the frontfacing setting 
wrong and the orientation wrong messing up the cover test.  The patch is a real 
short one.

OK, summary:

1) The alternative line removal algorithm patch fixes the bits and pieces 
problem reported by Thomas.

2) The degenerate polygon patch fixes the red/green (inside/outside) problem 
also reported by Thomas.

3) There still remains an issue with touching polygons facing different 
directions (one front, one back) not being able to resolve which edge color 
should be shown.  This rarely occurs except in that figure 8 tube demo.  Not 
sure this can be fixed without adding a little more info about where the edge 
originates from.

4) There still remains an issue with the seam showing for a 360 degree object 
such as the glass or the globe.  I suspect the problem is that the different 
vertices are a source of problem even though these vertices come out to be 
exactly the same.  Could use V_EQUAL() to check for duplicate vertices, but eh 
save that for a rainy day.

Dan

Re: Hidden3d Bug Fix

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

Daniel J Sebald wrote:

> [5]  The sort_edges_by_z() shouldn't be necessary in the quad-tree 
> version of the code since there isn't a speed-up test hinged on the 
> order of edges. However, it doesn't hurt things and in fact it helps.  I 
> tried without it and got pretty much the same results but in some 
> circumstances a line will show through.  The reason is described in [6], 
> but in any case, I've left the sort as is.

Actually, the sorting of edges doesn't appear to be critical in the quad-tree 
compilation.  With that edge sort removed there seems to be a small speedup for 
bigger meshes, but not significant.

What I am seeing was actually always there in the glass.dat example, which is 
the seam at the start and end of a scan line that shows through.  I entered that 
as a bug in SourceForge but I'm not sure what can be done with that.  Maybe add 
something that if V_EQUAL() on two vertices tests true replace the vertex with 
the previous?

What might be worth a change in terms of speed up is to make the quad tree 
granularity dynamic and have it be on the order of the isosamples setting in 
both x and y directions.  I have a Gaussian 2D plot in which I set the 
isosamples to 60.  By changing the granularity from 10 to 50 there is a speed 
improvement of about 40%.

Also, I'm still wondering if for larger meshes, say iso_x * iso_y > 500, we 
should have the mouse 3D rotation turn off hidden lines until the user lets go 
of the mouse button at which point the hidden line version is drawn again. 
Otherwise panning is so choppy.

Dan

Re: Hidden3d Bug Fix

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

Hans-Bernhard Bröker wrote:
 > Daniel J Sebald wrote:
 >
 >> I put a bug fix for the hidden3d spics and specs bug on SourceForge.
 >> Patch #1726236.  Please move that into CVS soon.
 >
 >
 > Not without further discussion, please.  Fiddling with the EPSILON
 > doesn't really fix any problem --- it only moves it elsewhere.

OK, I agree with you on the EPSILON issue.  I've abandoned the EPSILON^2 idea on 
area quantities.  Enough on that...

Well, rather than discuss the bug, let me offer up an alternative implementation 
of Test 4 through Test 9 of the hidden3d code.  It is in patch [ 1725993 ] 
Alternate Hidden3d Edge Segmentation.  I think it is a more organized algorithm 
and it inherently does all this classification stuff by way of the mathematical 
equations.  I kept the few mathematical snippets of Test 4-9 such as plane 
equation and cross product area for inside/outside polygon and put them in a 
more mathematical surrounding.  The rest was removed.  I think the result is 
really easy to follow.  Give it a try and let me know of any problems.

Here are the main points.

[1]  I added the following short utilities for sake of reuse and organization.

/* Find the intersection of a line and plane in 3d space in
  * terms of parameterization u where v = v1 + u * (v2 - v1) */
intersect_line_plane(p_vertex v1, p_vertex v2, t_plane p)

/* Find the intersection of two lines in 2d space in terms
  * of parameterization u where v = v1 + u * (v2 - v1) */
intersect_line_line(p_vertex v1, p_vertex v2, p_vertex w1, p_vertex w2)

/* Check whether the point is covered by the plane in 3d space
  *
  * 0 - point not covered
  * 1 - point covered and does not lie in plane
  * 2 - point covered and lies in plane
  */
cover_point_poly(p_vertex v1, p_vertex v2, double u, p_polygon poly)

The new algorithm takes the approach that if we look at a line segment v1, v2 
and a triangular region that might cover it and create a hidden section, there 
are four points along that segment that cuts can be made.  Call these u1, u2, 
u3, and u4.  Some u will be outside the range (0,1) and discarded.  The rest are 
ordered and then each segment is tested as being covered by the triangle.  (See 
Patch #1725993 for a PDF file that gives a better explanation.)

[2]  An important part of this approach is to classify the end points of segments as

0 - not covered by polygon
1 - covered by polygon
2 - on the polygon

the logic that follows from that is to draw the line either of the two points is
not covered *or* if both points are on the polygon.

With the new algorithm and drawing rule results are pretty much the same as with
the existing version.  However, there are differences.  And I think that if one
looks at the hidden demos

load 'animate2.dem'
load 'animate.dem'
load 'binary.dem'
load 'contours.dem'
load 'hidden.dem'
load 'image2.dem'
load 'molecule.dem'
load 'multimsh.dem'
load 'pm3d.dem'
load 'pointsize.dem'
load 'random.dem'
load 'rgb_variable.dem'
load 'scatter.dem'
load 'singulr.dem'
load 'surface1.dem'
load 'transparent_solids.dem'
load 'world.dem'

you'll notice little differences (be sure to rotate the plots using the mouse) 
in which I think the patch performs in a preferred manner.  For example, I've 
attached PNGs for one example without (before_patch.png) and with the patch 
(after_patch.png).  The result with the patch properly hides the axis lines.

[3]  I removed this test from split_line_at_ratio():

      if (EQ(w, 0.0))
  	return vnum1;
      if (EQ(w, 1.0))
  	return vnum2;

because there is still the additional test

     /* additional checks to prevent adding unnecessary vertices */
     if (V_EQUAL(v, vlist + vnum1)) {
	droplast_dynarray(&vertices);
	return vnum1;
     }
     if (V_EQUAL(v, vlist + vnum2)) {
	droplast_dynarray(&vertices);
	return vnum2;
     }

and I like the second test better than the first.  The reason I don't like the 
first test is that the value "w" is between 0 and 1 and is the parameter similar 
to u in v = v1 + u * (v2 - v1).  But "w" doesn't say anything about the final 
distance because v1 and v2 could be relatively close or relative distant 
depending upon the length of the line.  (Remember, things like axes can be a 
factor of 10 or 100 longer than the mesh edges.)

[4]  Here's a bonus FIXME with the patch:  I cleaned up the vertices created by 
in_front(), i.e.,

- * it. FIXME: allocates new vertices when splitting, but never frees
- * them, currently. */

by simply keeping track of vertices.end at the start of in_front(), and right
before the two return locations of the function remove the vertices until
vertices.end matches what it was at the beginning of in_front().

[5]  The sort_edges_by_z() shouldn't be necessary in the quad-tree version of 
the code since there isn't a speed-up test hinged on the order of edges. 
However, it doesn't hurt things and in fact it helps.  I tried without it and 
got pretty much the same results but in some circumstances a line will show 
through.  The reason is described in [6], but in any case, I've left the sort as is.

[6]  In all the demos above using hidden lines, with the patch I've noticed no 
flaws except one.  It is shown in the attached PNG file "tiny_flaw.png".  Look 
inside the upper left tube and you'll notice a red line that should be green. 
This happens because (conjecture!) there is a parallel crossing there where the 
red edge and the green edge are coincident.  Therefore when the corresponding 
polygons from which these edges originate are cover tested, both the green and 
red lines are on the other polygon's plane.  Hence by rule [2], both are 
visible.  Based upon the sort_edges_by_z, the red comes out ahead of the green.

This is the same kind of thing as when we discussed the pm3d ordering and for 
now it is an "oh well" kind of thing.  The way to fix this is to somehow keep 
information about which polygon element the edge originates from.  (Lines, 
points and axes have now polygon they originate from so they must simply be 
treated as the way the currently are.)  For example, if each edge simply had the 
centroid of the element it originated from, we'd be able to tell if it is the 
green line or red line in the above example that should be printed.  We'd know 
which side is facing the viewer, i.e., green in this case.

Dan

PS:  If interested, we might be able to implement a hidden surface algorithm 
using some formulas of http://local.wasp.uwa.edu.au/~pbourke/geometry/.  But the 
real work is setting up the networks (or whatever it would be called in the case 
of surfaces).

Hidden3d Bug Fix

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

I put a bug fix for the hidden3d spics and specs bug on SourceForge.  Patch 
#1726236.  Please move that into CVS soon.  I have another patch after that one 
is applied.

Thanks,

Dan

Re: gnuplot with wxt on MacOS, time for decisions

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

> On Tuesday 22 May 2007 14:47, Timothée Lecomte wrote:
>> Ethan or Hans-Bernhard maybe, I'd appreciate if you wanted to give a
>> quick
>> look at the patch and tell me if this approach (not the details) looks
>> right to you.
>
> The conditional dependencies look suspicious to me.
>
> In wxt_gui.h I see this:
>  #if defined(__WXGTK__) || defined(__WXMAC__)
>  # define WXT_MULTITHREADED
>  #elif defined(__WXMSW__)
>  # define WXT_MONOTHREADED
>
> But then in wxt_gui.cpp I see:
>
>  #ifdef WXT_MULTITHREADED
>  extern "C" int gnu_main(int argc, char **argv);
>  int main(int argc, char **argv)
>  {
>  #ifdef __WXMSW__
>        /* the following is done in wxEntry() with wxMSW only */
>        wxSetInstance(GetModuleHandle(NULL));
>        wxApp::m_nCmdShow = SW_SHOW;
>  #endif /*__WXMSW__*/
>
>
> Is it really possible for __WXMSW__ to be defined inside of
> a block marked #ifdef WXT_MULTITHREADED ?
>
> --
> Ethan A Merritt
>

You're right, the previous code did not handle the Windows case.
I've committed the comments and debugging messages changes to CVS, fixed
the code in my local copy to work for Windows too. Attached is the
corresponding patch against current CVS copy.

Thanks.

Timothée

Re: gnuplot with wxt on MacOS, time for decisions

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

On Tuesday 22 May 2007 14:47, Timoth=C3=A9e Lecomte wrote:
> Ethan or Hans-Bernhard maybe, I'd appreciate if you wanted to give a quick
> look at the patch and tell me if this approach (not the details) looks
> right to you.

The conditional dependencies look suspicious to me.

In wxt_gui.h I see this:
 #if defined(__WXGTK__) || defined(__WXMAC__)
 # define WXT_MULTITHREADED
 #elif defined(__WXMSW__)
 # define WXT_MONOTHREADED

But then in wxt_gui.cpp I see:

 #ifdef WXT_MULTITHREADED
 extern "C" int gnu_main(int argc, char **argv);
 int main(int argc, char **argv)
 {
 #ifdef __WXMSW__
       /* the following is done in wxEntry() with wxMSW only */
       wxSetInstance(GetModuleHandle(NULL));
       wxApp::m_nCmdShow =3D SW_SHOW;
 #endif /*__WXMSW__*/


Is it really possible for __WXMSW__ to be defined inside of
a block marked #ifdef WXT_MULTITHREADED ?

=2D-=20
Ethan A Merritt

Re: gnuplot with wxt on MacOS, time for decisions

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

Dear all,

I finally chose (as usual ?) the shortest way from the current code to
make wxt work on MacOS, i.e.:

> 2nd solution = invert the threads' roles (i.e. the shortest path from
> where we are now):
> - the main thread runs the GUI event loop, and gnuplot gnu_main()
> (plot.c:278) runs in the second thread.
> - terminal callbacks (such as term->graphics, term->text) do every GUI
> action asynchronously, by posting messages to the GUI event loop
> - corner cases:
>     *signals masks have to be carefully set, so that ^C ends up in the
> second thread (easy)
>     *doing everything asynchronously can be painful, sometimes it's
> actually synchronous, so you have to wait for the other thread to finish
> before continuing (I am thinking of term->init() where new windows are
> created) (easy, but not really beautiful programming)
>     * this adds a startup overhead, because wxWidgets has to be
> initialized at launch-time for the threads facility (I don't see how to
> switch the two thread contexts when they are already running) (currently
> it's initialized when first used).

The good news is that few things (window creation mainly) have to be
really done in the GUI thread, so it wasn't much of a pain.
Most of the work is already in CVS. The last patch that actually switches
the two threads is attached. It is a patch against today's CVS. Mojca or
Joe, please test if you want to.
Ethan or Hans-Bernhard maybe, I'd appreciate if you wanted to give a quick
look at the patch and tell me if this approach (not the details) looks
right to you.

Remaining bits to fix: add 24x24 icons for the toolbar (standard on
MacOS), fix oversampling (problems with text position, maybe a buggy cairo
or pango version), make 'persist'-effect work (does it work on aquaterm by
the way ?)

Best regards,

Timothée

Re: How can I print the y values from a data file with plots?

[<HBB...@t-...>]

Yang Yunseok wrote:

> But I have spend a lot of time to find out how I can print the value I 
> want to show in a data file.

Your question is somewhat unclear.  What you actually appear to want, 
from the example you posted, is to put a number somewhere on the plot, 
not "print it ... in a data file".  What you didn't say is where that 
number is supposed to come from, i.e. how gnuplot is supposed to know 
which of the data points gets this extra annotation.

How can I print the y values from a data file with plots?

[Yang Y. <yy...@ha...>]

<style> p {margin-top:0px;margin-bottom:0px;} </style>
<table border=0 width=100% bgcolor='' cellpadding=0 cellspacing=0 align=center>
	<tr>
	<td valign=top style='padding:8pt;'><font size=2 face='굴림'>
<P>Dear Helpers,</P>
<P>&nbsp;</P>
<P>I tried to darw a lot of plots with gnuplot.</P>
<P>I think it's good. This helps me have more free time.</P>
<P>But I have spend a lot of time to find out how I can print the value I want to show in a data file.</P>
<P>MS Excel produces a plot with some value on a graph.</P>
<P>I want to see like that.</P>
<P>Would you help me?</P>
<P>&nbsp;</P>
<P>Example)</P>
<P>|</P>
<P>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2</P>
<P>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </P>
<P>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +</P>
<P>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +</P>
<P>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +</P>
<P>|<BR>
|</P>
<P>----------------------------------------------</P></font></td></tr>
</table>


<!-- __Hanmail-sig-Start__ -->

			  <br><br><a href="mailto:yy...@ha..."><img src="http://nametag.hanmail.net/6OYM4DL.34d54JroVKXeKg00" border="0"></a>
<!-- __Hanmail-sig-End__ -->

 

<!-- __Hanmail-tail-Start__ -->
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<tr height="9">
 <td>&nbsp;</td>
</tr>
<tr height="1">
 <td background="http://mailimg.hanmail.net/05mail/img_dotline.gif" style="font-size:0px;background-repeat:repeat-x;">
 </td>
</tr>
<tr>
 <td height="32">


  <div style="float:right;width:293px;height:27px;overflow:hidden;">
   <a href="http://allim.daum.net/servlet/Redirect?sid=footer060925_daumdirect" target="_blank" style=" color:#333333; font-size:12px; font-family:굴림,굴림체; font-weight:bold;"><img src="http://mailimg.hanmail.net/05mail/footer_banner/daumdirect_footer_29327.gif" width="293" height="27"  style="vertical-align:middle;border:0;" /></a>
  </div>

  <div style="margin-top:3px;font-size:12px;color:#333333;font-weight:normal;font-family:굴림,굴림체;">

    <br style="line-height:5px;" />   [나의 라이브러리, 한메일] <a href="http://allim.daum.net/servlet/Redirect?sid=footer_shrek3070514"  style=" color:#ea770d; font-size:12px; font-family:굴림,굴림체; font-weight:normal; text-decoration:none;" target="new"> <슈렉3>를 보고싶다면? 클릭! </a>
 
  </div>
 </td>
</tr>
</table>


<!-- __Hanmail-tail-End__ -->


<img src="http://wwl784.hanmail.net:4280/@from=yyang&rcpt=gnuplot%2Dbeta%40lists%2Esourceforge%2Enet&msgid=%3C20070518192111%2EHM%2Ez000000000J9H4B%40yyang%2Ewwl784%2Ehanmail%2Enet%3E">

Re: Notification that plot window has closed [Feature Request 1719259]

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

On Thursday 17 May 2007 06:39, Petr Mikulik wrote:
> > Feature Request 1719259 asks for a mechanism to notify the
> > user or scripting environment that the plot window has been
> > closed.
> 
> Here is the patch for src/win/wgraph.c:
> 
> --- wgraph-orig.c       2006-11-13 00:43:46.000000000 +0100
> +++ wgraph.c    2007-05-17 15:32:35.000000000 +0200
> @@ -406,6 +406,8 @@
>  void WDPROC
>  GraphClose(LPGW lpgw)
>  {
> +//Wnd_exec_event(lpgw, (LPARAM)0, GE_keypress, GP_Cancel);//Why not?
> +       Wnd_exec_event(lpgw, (LPARAM)0, GE_reset, 0);
>         /* close window */
>         if (lpgw->hWndGraph)
>                 DestroyWindow(lpgw->hWndGraph);
> 
> 

Thanks.

> I first tried with the GE_keypress+GP_Cancel event (like in x11), it did not 
> work, then I tried GE_reset (like in wxt), it works. Why?

I'm not sure.
Maybe because going through event_reset clears the keystroke modifier flags?
Maybe the event is not recognized as coming from the "current" plot window?
The dummy keystroke event created by event_reset() in this new path forces
current = TRUE. 

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

Re: Notification that plot window has closed [Feature Request 1719259]

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

> Feature Request 1719259 asks for a mechanism to notify the
> user or scripting environment that the plot window has been
> closed.
> 
> In x11 this is easy, because we already receive an event from
> the window manager when the window closes and can use it as a
> trigger to call event_reset(). I am wondering how easy this
> would be from the other interactive terminals.
> 
> How could one detect that the wxt plot window has been closed?
> Windows?

Here is the patch for src/win/wgraph.c:

--- wgraph-orig.c       2006-11-13 00:43:46.000000000 +0100
+++ wgraph.c    2007-05-17 15:32:35.000000000 +0200
@@ -406,6 +406,8 @@
 void WDPROC
 GraphClose(LPGW lpgw)
 {
+//Wnd_exec_event(lpgw, (LPARAM)0, GE_keypress, GP_Cancel);//Why not?
+       Wnd_exec_event(lpgw, (LPARAM)0, GE_reset, 0);
        /* close window */
        if (lpgw->hWndGraph)
                DestroyWindow(lpgw->hWndGraph);


I first tried with the GE_keypress+GP_Cancel event (like in x11), it did not 
work, then I tried GE_reset (like in wxt), it works. Why?

Petr

Notification that plot window has closed [Feature Request 1719259]

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

Feature Request 1719259 asks for a mechanism to notify the
user or scripting environment that the plot window has been
closed.

In x11 this is easy, because we already receive an event from
the window manager when the window closes and can use it as a
trigger to call event_reset(). I am wondering how easy this
would be from the other interactive terminals.

How could one detect that the wxt plot window has been closed?
The aquaterm plot window?
Windows?
os2?


-- 
Ethan A Merritt

Re: PDF version 1.4 & XeTeX

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

On 5/16/07, Ethan Merritt wrote:
> On Wednesday 16 May 2007 04:47, Mojca Miklavec wrote:
> > Hello,
> >
> > I'm posting a bit weird question here. A user on the XeTeX mailing
> > list reported a problem, because XeTeX doesn't know how to interpret
> > PDF version 1.4 and thus he wasn't able to include a gnuplot-generated
> > (set term pdf) graph into his LaTeX document.
>
> PDF     Acrobat Version
> 1.3     Acrobat 4
> 1.4     Acrobat 5
> 1.5     Acrobat 6
> 1.6     Acrobat 7

I know. And now also:

1.7     Acrobat 8

But I just figured out what the problem was. The problem was not in
XeTeX, but in "ebb" for calculating bounding boxes, which uses
dvipdfmx libraries, which have
     static unsigned pdf_version = 3;
and then the program complains about "too-high pdf version", when it
just needs to calculate the bounding box. Really stupid. XeTeX
supports pdf version 1.4, but not 1.5, and pdfTeX also has problems
with newer versions.

Forget about my stupid remark. 1.4 is really something that should be
supported in any reasonable program.

> > My question is: is version 1.4 needed for some reason (advanced
> > functionality, apart from smaller PDF files)? I.e: would it still work
> > if one decided to lower the PDF version to 1.3 for example and
> > recompiled gnuplot manually?
>
> According to the PDFLib manual, PDF Version 1.4 is needed for
> transparency, pattern-fill, and shading.

PDFReference (http://www.adobe.com/devnet/pdf/pdfs/PDFReference13.pdf)
states that v1.3 supports all of them, but don't bother too much. It's
really that other tools need to be fixed, not gnuplot.

> I don't know exactly what
> would happen if you forced the compatibility level to 1.3 and then tried
> to create a plot that used these features.
>
> > (x)dvipdfm(x) will have to be improved sooner or later, and there are
> > other means to help (lower the version with acrobat etc.), but I'm
> > just curious if there are means to lower the version from withing
> > gnuplot ...
>
> If you link to a very old version of PDFlib this will happen automatically.
> If you link to a more recent version, gnuplot requests compatibility
> level 1.4 (the default would be higher than this, not lower).

Thanks again. And sorry for remarks that were really not in place.

Mojca

Re: PDF version 1.4 & XeTeX

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

On Wednesday 16 May 2007 04:47, Mojca Miklavec wrote:
> Hello,
> 
> I'm posting a bit weird question here. A user on the XeTeX mailing
> list reported a problem, because XeTeX doesn't know how to interpret
> PDF version 1.4 and thus he wasn't able to include a gnuplot-generated
> (set term pdf) graph into his LaTeX document.

PDF	Acrobat Version
1.3	Acrobat 4
1.4	Acrobat 5	
1.5	Acrobat 6
1.6	Acrobat 7
 
> My question is: is version 1.4 needed for some reason (advanced
> functionality, apart from smaller PDF files)? I.e: would it still work
> if one decided to lower the PDF version to 1.3 for example and
> recompiled gnuplot manually?

According to the PDFLib manual, PDF Version 1.4 is needed for 
transparency, pattern-fill, and shading.   I don't know exactly what
would happen if you forced the compatibility level to 1.3 and then tried
to create a plot that used these features.

> (x)dvipdfm(x) will have to be improved sooner or later, and there are
> other means to help (lower the version with acrobat etc.), but I'm
> just curious if there are means to lower the version from withing
> gnuplot ...

If you link to a very old version of PDFlib this will happen automatically.
If you link to a more recent version, gnuplot requests compatibility
level 1.4 (the default would be higher than this, not lower).


-- 
Ethan A Merritt

PDF version 1.4 & XeTeX

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

Hello,

I'm posting a bit weird question here. A user on the XeTeX mailing
list reported a problem, because XeTeX doesn't know how to interpret
PDF version 1.4 and thus he wasn't able to include a gnuplot-generated
(set term pdf) graph into his LaTeX document.

My question is: is version 1.4 needed for some reason (advanced
functionality, apart from smaller PDF files)? I.e: would it still work
if one decided to lower the PDF version to 1.3 for example and
recompiled gnuplot manually?

(x)dvipdfm(x) will have to be improved sooner or later, and there are
other means to help (lower the version with acrobat etc.), but I'm
just curious if there are means to lower the version from withing
gnuplot ...

Thanks a lot,
    Mojca

Re: Time formats [was Re: Feature request - assignment in expressions]

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

On Saturday 12 May 2007 07:13, pl...@pi... wrote:
> My other problem is that the code snip I posted seems to be correctly  
> calculating the areas of the increamental trapezoidal segements but fails  
> to add the existing value of my area variable.
> 
> 
> area=0; started=0;prev_x=0;prev_y=0;
> add_aug(x,y)=assign("area",(started)?\
>                                       area + (x-prev_x)*(y-prev_y)/2.0  
> + 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) \
>                                      :( 0.0*assign("started",1)  
> + 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) ) \
>                     );
> 
> 
> plot  datafile   using  
> 1:(add_aug(strptime("%H:%M",stringcolumn(1))/3600*2,P( Th4($3-2.0)   
> -(Th7($5)-0.52) ))) axes x1y2  with lines s f t "aug" \
> 
> 
> 
> So referencing area inside assign("area", ) seems to return zero, whereas  
> the other calls to assign() work and references to the other variables  
> inside assign() produces expected results.
> 
> Can you confirm that bug and hopefully correct it?

Too complicated for my poor brain.  
Please try to reduce this to a much simpler test script
that demonstrates an error.

The obvious test:
	sum(x) = assign("sum",x+sum)
	plot <foo> using 1:($2+0*sum($2))
seems to work just fine

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

gnuplot 4.2 for DOS and DJGPP

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

I wanted to recompile gnuplot 4.2 for DOS (recycling an old experimental 
PC). I have updated Makefile for DJGPP (committed to cvs for 4.3, but works 
with 4.2 as well).

However, drawing on SVGA is a bit strange:
- "test" command passes perfectly
- "splot x" draws OK on every 2nd attempt, the surface not being
  drawn otherwise
- "splot x, 10+x, 20+x" draws only the first surface
- "plot x" does not draw anything on the 1st "plot", then draws
  only the border

All works fine when compiled gnuplot 4.0. Since there are no differences 
between djsvga.trm from 4.0 and 4.2, I wonder why this can happen?
Could someone try it?

Note: you can try it even under Linux, by xdosemu or qemu.

---
PM

Re: 4.2 tarball broken?

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

Navneeth Chandrasekaran wrote:
> I tried installing 4.2 from source in Ubuntu Feisty. While untarring the
> files, I got an error.
> 
> gnuplot-4.2.0/src/command.h
> gnuplot-4.2.0/src/contour.c
> tar: Skipping to next header
> 
> gzip: stdin: invalid compressed data--crc error
> 
> gzip: stdin: invalid compressed data--length error
> tar: Child returned status 1
> tar: Error exit delayed from previous errors

This sounds like something more for the Ubuntu packaging people.


> How can I overcome this problem?

You may try the platform independent tar file

http://gnuplot.info/download.html

or try the CVS version

http://gnuplot.info/development/index.html

if you have all the right compilation tools.

Dan

4.2 tarball broken?

[Navneeth C. <nav...@gm...>]

I tried installing 4.2 from source in Ubuntu Feisty. While untarring the
files, I got an error.

gnuplot-4.2.0/src/command.h
gnuplot-4.2.0/src/contour.c
tar: Skipping to next header

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
tar: Child returned status 1
tar: Error exit delayed from previous errors

How can I overcome this problem?

Thanks,
Navneeth

Re: Time formats [was Re: Feature request - assignment in expressions]

[<pl...@pi...>]

Hi again,

just found a bit of time to have another look at this. A couple of small=
  =

probs, one with assign() , the other with strptime you suggested I look =
at.

On Tue, 08 May 2007 20:01:06 +0200, Ethan Merritt  =

<merritt@u.washington.edu> wrote:

> On Tuesday 08 May 2007 09:43, Juergen Wieferink wrote:
>>
>> > I have never understood the time-handling code.  I suspect that the=

>> > whole special case time format mechanism is no longer needed, as th=
e  =

>> same
>> > goal can be achieved using general string-handling functions.
>> > In your case, you probably need to use some combination of  =

>> stringcolumn()
>> > strptime() strftime() rather than setting a time format.
>>

I tried using strptime with the same time format that works with my data=
  =

but found I had to divide by 3600 just to get it on the plot. However it=
  =

did get around the trucation to the nearest hour I was seeing when passi=
ng  =

the result of timecolumn().

So it seems that strptime() does not always parse the data in the same w=
ay  =

as with timefmt as the help suggests.

It seems that this time feature has been somewhat tacked on to fullfil  =

requests for this format but that it has not been implement, or at least=
  =

implemented in the same way through out.

If you are working on the code to deal with this in a more structured wa=
y  =

I think that would be very benefitial, current behavious seems to vary  =

somewhat depending on where and how time format is used.



>> I don't think so.  I see two problems (probably there are more):
>> * Automatic tic generation is date/time aware.  This could be
>>   adjusted manually, but the automatic tics wouldn't be too sensible.=

>
> Could be.  As I said, I am not familiar with the time format options.
>
>> * Tic label generation.  The command "set format" just takes a
>>   format string, which is used either for date/time or ordinary
>>   numbers.  The functions strptime() and strftime() only work with a
>>   more flexible "set format" which takes a string valued expression, =
 =

>> which
>>   is evaluated at plot time.
>
> Sure.  But that could be a useful addition in its own right.
> I didn't mean to say that the time format options could be deprecated
> with no additional work; I just meant that the basic pieces are in pla=
ce
> to replace them with a more general mechanism.
>
> Don't forget that we have several long-standing requests to extend
> the time format system so that it can handle intervals smaller than
> a second, and also to allow it to handle spherical coordinate systems
> deg/min/sec/fractional-sec
>
> One could write a lot of special-purpose code to handle these
> extensions, but I would rather see the effort spent on implementing
> a generic mechanism of which the existing time formats and the
> proposed geographic variants are just user-configurable examples.
>
>

My other problem is that the code snip I posted seems to be correctly  =

calculating the areas of the increamental trapezoidal segements but fail=
s  =

to add the existing value of my area variable.


area=3D0; started=3D0;prev_x=3D0;prev_y=3D0;
add_aug(x,y)=3Dassign("area",(started)?\
                                      area + (x-prev_x)*(y-prev_y)/2.0  =

+ 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) \
                                     :( 0.0*assign("started",1)  =

+ 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) ) \
                    );


plot  datafile   using  =

1:(add_aug(strptime("%H:%M",stringcolumn(1))/3600*2,P( Th4($3-2.0)   =

-(Th7($5)-0.52) ))) axes x1y2  with lines s f t "aug" \



So referencing area inside assign("area", ) seems to return zero, wherea=
s  =

the other calls to assign() work and references to the other variables  =

inside assign() produces expected results.

Can you confirm that bug and hopefully correct it?

Many thanks.

Re: Feature request - assignment in expressions

[<pl...@pi...>]

On Tue, 08 May 2007 17:57:54 +0200, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

>
> Please continue to play with it.  We need to discover what limitations=
  =

> and
> drawbacks this simple implementation may have before seriously  =

> considering
> to add some variant to the program.


area=3D0; started=3D0;prev_x=3D0;prev_y=3D0;
add_aug(x,y)=3Dassign("area",(started)?area+(x-prev_x)*(y-prev_y)/2.+0.*=
assign("prev_x",x)+0.*assign("prev_y",y):(0.*assign("started",1)+0.*assi=
gn("prev_x",x)+0.*assign("prev_y",y)));

This should do a trapezoidal area under graph but I have not been able t=
o  =

check it's result because of time trunkage.

Anyway, plotting the return value it seems to be doing the right thing.

;)

Re: Feature request - assignment in expressions

[<pl...@pi...>]

On Tue, 08 May 2007 17:57:54 +0200, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Monday 07 May 2007 23:56, pl...@pi... wrote:
>>
>> thanks very much for picking this up. That seems quite close to what I  
>> was
>> requesting. I extended your example to pick up the x value of the ymax  
>> as
>> well. The plot gives the sample-and-hold plot as expected. Proof of
>> principle. Nice one.
>>
>> The nice thing is this can be limitted by setting the range before plot.
>> This is a nice quick solution that avoids quite a bit of effort messing
>> about with external scripts for simple stuff like this. A nice addition.
>
> Please continue to play with it.  We need to discover what limitations  
> and
> drawbacks this simple implementation may have before seriously  
> considering
> to add some variant to the program.
>
> I hope we can come up with a nicer syntax, as it seems ugly to me to hide
> this inside the 'using' clause.

Yes it feels like a bit of a cludge but I'm happy to have a cludge rather  
than an impasse. I think the 'after' syntax is seems much more integrated.


  Thinking out loud....  what about a
> parallel clause with a name like 'after'.  The operations in the 'after'
> clause would be carried out before passing the data through for actual
> plotting:
>
>    plot <foo>  using 1:2 after track_max($2) with lines
>
> perhaps it should allow multiple operations:
>
>    plot <foo> using 1:2 after {track_max($2), track_min($2), sum($2)}  
> with lines
>
>
> More thoughts:
>
> - (Pro) As compared to filtering through an external script, this  
> mechanism
>   has the advantage that it can affect internal gnuplot user variables.
>
> - (Con) This is incompatible with the revised zooming/refresh code
>   that I am working on.  There the idea is to avoid re-reading the input
>   data if all you want to do is replot it.  But the assign/after  
> mechanism
>   is applied during data input, so it would be bypassed by any such  
> shortcut.
>
> - Having to use the name of the variable rather than the variable itself
>   may make sense to a low-level programmer, but is likely to be confusing
>   to many users.  Suggestions for a syntax that hides this level of
>   complexity would be welcome.  Or perhaps some additional cleverness in
>   the parset is possible.  We have one such function already,
>   exists("VARNAME"), but that one is also confusing.
>
Yes , it's a shame if you have to do it that way, I assumed you'd just  
done that for speed to test the idea because it was simpler to code.



>> This presents me with some small issues remaining to be solved:
>>
>> 1. My xdata is time format , I imagine your patch does not try to fit  
>> all
>> cases but in assigning the x value it gets truncated to the nearest  
>> hour,
>> 12:45 becomes 12.0
>
> I have never understood the time-handling code.  I suspect that the
> whole special case time format mechanism is no longer needed, as the same
> goal can be achieved using general string-handling functions.
> In your case, you probably need to use some combination of stringcolumn()
> strptime() strftime() rather than setting a time format.
>
>> 2. my inexperience with gnuplot, it seems that if I try to set a label
>> after the plot command (which I need to do for xmax,ymax) it does not
>> show. The same command before plot command does work but it's at (0,0).
>
> Of course.  When you draw a new graph by issuing the command "plot" or
> "splot", it uses the currently defined labels.
> If you define a label afterwards, how could it possibly appear in the
> already-drawn plot?  If you don't mind reading the data a second time,
> you could "replot" to pick up the new labels.
>
Redoing the whole job just to add a label seems a bit extravagant. I  
thought there may be some trick with multiplot that I had not discovered  
yet. Your reply suggests there is not.

This seems an illogical restriction from a users point of view even if it  
makes sense in the way gnuplot stores label info.

maybe there should be some mechanism if there isn't , eg. set label ....  
replot.

BTW I posted a bug to the bugs list about time data not being respected by  
table mode . Although I noticed the cursor is now display time data  
correctly, having gone to cvs, this does seem to be an area that still  
needs implementing consistantly.

I'll try to do an trapezoidal A.U.G  using your mod., I had to put this  
out to awk which was an annoying waste of effort. It will be a good test.

Thanks for your interest.