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

Re: Solaris does not have trunc()

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

On Wednesday 17 February 2010 17:14:49 Shigeharu TAKENO wrote:
> shige 02/18 2010
> ----------------
> 
> src/term.c of current version 
> 
>  $Id: term.c,v 1.197 2010/02/17 06:21:31 sfeam Exp $
> 
> includes the function trunc(), but Solaris 9 does not have it. 

I noticed the same problem when I tried to build on a machine
at the lab today.  Although trunc() is part of the C99 standard,
unfortunately too many machines are not yet using a C99 compliant compiler.

But trunc() and rint() are not at all the same.
It does not work to replace one by the other.  

I will re-write the code in do_arc() to use explicit tests rather
than calling an external function.

	Ethan


> So, we needs the following patch on Solaris:
> 
> ----- From here -----
> --- src/term.c.ORG	Thu Feb 18 10:01:04 2010
> +++ src/term.c	Thu Feb 18 09:57:17 2010
> @@ -106,6 +106,10 @@
>  # endif                         /* MSC */
>  #endif /* _Windows */
>  
> +#ifdef __sun
> +# #define trunc(x) rint(x)
> +#endif
> +
>  static int termcomp __PROTO((const generic * a, const generic * b));
>  
>  /* Externally visible variables */
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+

Re: Solaris does not have trunc()

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

shige 02/18 2010
----------------

Sorry, I made a mistake.

I wrote:
| ----- From here -----
| --- src/term.c.ORG      Thu Feb 18 10:01:04 2010
| +++ src/term.c  Thu Feb 18 09:57:17 2010
| @@ -106,6 +106,10 @@
|  # endif                         /* MSC */
|  #endif /* _Windows */
|  
| +#ifdef __sun
| +# #define trunc(x) rint(x)
| +#endif
| +
|  static int termcomp __PROTO((const generic * a, const generic * b));
|  
|  /* Externally visible variables */
| ----- To here -----

Correct patch is the following:

----- From here -----
--- src/term.c.ORG      Thu Feb 18 10:01:04 2010
+++ src/term.c  Thu Feb 18 09:57:17 2010
@@ -106,6 +106,10 @@
 # endif                         /* MSC */
 #endif /* _Windows */
 
+#ifdef __sun
+# define trunc(x) rint(x)
+#endif
+
 static int termcomp __PROTO((const generic * a, const generic * b));
 
 /* Externally visible variables */
----- To here -----

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

Solaris does not have trunc()

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

shige 02/18 2010
----------------

src/term.c of current version 

 $Id: term.c,v 1.197 2010/02/17 06:21:31 sfeam Exp $

includes the function trunc(), but Solaris 9 does not have it. 
So, we needs the following patch on Solaris:

----- From here -----
--- src/term.c.ORG	Thu Feb 18 10:01:04 2010
+++ src/term.c	Thu Feb 18 09:57:17 2010
@@ -106,6 +106,10 @@
 # endif                         /* MSC */
 #endif /* _Windows */
 
+#ifdef __sun
+# #define trunc(x) rint(x)
+#endif
+
 static int termcomp __PROTO((const generic * a, const generic * b));
 
 /* Externally visible variables */
----- To here -----

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

Re: Ctrl+C - Re: windows terminal patches [1/6]

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

> Hello
> 
> I have tried to see what happens with pressing CTRL+C.
> 
> http://old.nabble.com/Re%3A-towards-4.4-(ctrl%2Bc-issue-for-gnuplot.exe(windows))-p27527817.html
> http://old.nabble.com/Re%3A-towards-4.4-(ctrl%2Bc-issue-for-gnuplot.exe(windows))-p27527993.html
> 
> This problem is not easy to fix completely. At this moment, I vote to Benjamin's proposal.
> 
> +#if defined(WGP_CONSOLE)
> + (void) signal(SIGINT, SIG_IGN);
> +#else
> (void) signal(SIGINT, (sigfunc) inter);
> +#endif
> 
> Addition of something like  /* Fix me */  is preferred for me.
> **********
> +#if defined(WGP_CONSOLE)
> + /* Fix me. CTRC+C crashes console mode gnuplot for windows. 
> failure of longjmp() is not easy to fix so that the signal of SIGINT is just ignored 
> at the moment */
> *******

Thanks, I've committed the code to cvs.

Petr

Re: dashes again

[Hans-Bernhard B. <HBB...@t-...>]

Petr Mikulik wrote:

> After usual "make install" it is not installed anywhere. I would expect it 
> in a gnuplot's directory such as share/gnuplot/4.5/x11

That expectation is based on incorrect assumptions.

Installing it there would be quite completely pointless.  App-default 
files need to be in a place where the X server looks for them to have 
any effect at all.

> In "help x11", solid|dashed is described. It does not say that something 
> is needed to be installed in order this works.

That's because it doesn't.

The system needs to be _configured_ for that to work --- dash patterns 
have to come from somewhere, and the X11 way of doing such things is to 
put them in the resource database.  There are lots of ways of doing 
that.  An app-default file installed in the right place is one of them, 
but an explicit call of xrdb -merge should be the last resort.

> That's confusing.

X11 is more flexible and more powerful than most of its current users 
are aware.

> But it gets the "-dashed" parameter. I think it should produce a warning 
> that this is ignored because something is not set.

And where do you propose gnuplot_x11 should output that warning?

> I wonder why some terminals support "dashlength" but not "solid|dash". 

Because those are two different things.  "dashlength" makes sense if the 
driver supports dashed lines, but "{solid|dashed}" only makes sense if 
the terminal can do both of those.  Pure black/white ones won't.

> That seems confusing. Should not all the dash-capable terminals support both 
> options?

Only if they're solid-capable, too.

Re: Ctrl+C - Re: windows terminal patches [1/6]

[Tatsuro M. <tma...@ya...>]

Hello

I have tried to see what happens with pressing CTRL+C.

http://old.nabble.com/Re%3A-towards-4.4-(ctrl%2Bc-issue-for-gnuplot.exe(windows))-p27527817.html
http://old.nabble.com/Re%3A-towards-4.4-(ctrl%2Bc-issue-for-gnuplot.exe(windows))-p27527993.html

This problem is not easy to fix completely. At this moment, I vote to Benjamin's proposal.

+#if defined(WGP_CONSOLE)
+ (void) signal(SIGINT, SIG_IGN);
+#else
(void) signal(SIGINT, (sigfunc) inter);
+#endif

Addition of something like  /* Fix me */  is preferred for me.
**********
+#if defined(WGP_CONSOLE)
+ /* Fix me. CTRC+C crashes console mode gnuplot for windows. 
failure of longjmp() is not easy to fix so that the signal of SIGINT is just ignored 
at the moment */
*******

Regards

Tatsuro

--- Petr Mikulik  wrote:

> > > Does this mean we can close out some or all of these bugs?
> > >  2848002   Ctrl+C crashes windows console build
> > 
> > No modification seems to be applied to plot.c
> > 
> >     (void) signal(SIGINT, (sigfunc) inter);
> > 
> > Perhaps this issue still remains.
> 
> Should I commit it to cvs?
> http://sourceforge.net/tracker/?func=detail&aid=2848002&group_id=2055&atid=102055
> 
> Are there any other patches that need a commit?
> 
> ---
> PM
> 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: dashes again

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

> > I raise questions about dash line patters from time to time (see e.g.
> > messages "unified dashes"). Usually it happens when I try to do
> > 	set term x11 dash
> > 	plot x,-x,1,2,3
> > and it comes out solid :-)
> > 
> > 1. It did not work in the morning, I had to find an older e-mail and
> >    find there
> >          xrdb -merge < Gnuplot.app-defaults
> > 
> > 1a. That seems to be a problem for ordinary users, because
> >    file  Gnuplot.app-defaults  is not "make install"ed.
> 
> Yes it is.  There is some dispute, however, about whether there is a
> standard place to install it. To resolve this, Christoph Junghans
> added an explicit configuration option.  It is noted in the Changelog
> as:
>  
> 2010-02-07  Christoph Junghans (ottxor)
>         * configure.in share/Makefile.am src/Makefile.am src/gplt_x11.c
>         src/variable.c: Configurable X11 application resource path.
>         Bug #2931287 #219323

After usual "make install" it is not installed anywhere. I would expect it 
in a gnuplot's directory such as share/gnuplot/4.5/x11

> > 1b. Further, gnuplot-x11 does not detect automatically that it cannot
> >    draw dash lines because that xrdb command was not executed. Why it
> >    does not help? 
> 
> Correction:  There is no requirement to run xrdb.  xrdb is one 
> particular way you can modify the current X resource values from the
> command line, but it is not the only way, not even the usual way.

In "help x11", solid|dashed is described. It does not say that something 
is needed to be installed in order this works. That's confusing.

> >    It should write a warning when "gnuplot -dashed" or 
> >    "set term x11 dash".
> 
> Gnuplot_x11 is not even running yet at the time you enter either of
> these commands.  It is started up later, at the time of the first plot.

But it gets the "-dashed" parameter. I think it should produce a warning 
that this is ignored because something is not set.

> > 2. "dash" support was added into wxt terminal in June 2009, just after
> >    4.4 branch separation. Shouldn't this be (back)ported to 4.4?
> 
> It is on my list of patches to apply after 4.4.0 is released.
> I posted the full list the other day, but here it is again:
>    winmain_va_copy      Allows building with Visual C
>    wxt_dashed           set term wxt ... {dashed|solid} {dashlength <dl>}
>    x11_mousewheel
>    wxt_mousewheel
>    pow_overflow         if i**j would cause integer overflow, return a float instead
>    int_overflow         Check internal integer multiplications for overflow
>    tikz                 remove conditional tests for version 4.3
>    candle_width         optional 6th column containing box width
>    rmargin              tweak left and right margins to be more like those prior to 4.2.4
>    jw-refactor          clean up the execute-from-string operations lf_push/lf_pop
>    cc-for-build         fix for building documentation during cross-compilation
>    percent_s            support the "%s" format specifier in strftime()
>    Kalinin_metapost     Fix inheritance of line thickness by text strings
>    suppress_PDFMark     rearrange postscript prolog to allow customization
>    timefmt              handle evaluated input values for time format "%s"
>    init_func_points     initialize full coordinate structure for 2D functions
> 
> These are all non-trivial changes that were made subsequent to the code 
> freeze for 4.4.0 (by "non-trivial" I mean "I was afraid they might possibly
> break something).  During the -rc1 period I've only been applying bug fixes
> and "trivial" changes to things like documentation.

OK

> > 3. Windows terminal supports solid, dash, dot-dash patterns via
> >    its menu in the graph window, but it does not support
> >       set term windows {solid|dashed}
> >    Benjamin, can you please implement it?
> > 
> > 4. Should "all usual" terminals support both options
> >       {solid|dash} {dashlength <dl>}  ?
> >    Currently:
> >      x11, svg: {solid|dash}
> >      wxt, postscript: {dashed|solid} {dashlength <dl>}
> >      png, pdf: {dashlength <dl>}
> 
> Not sure I understand your proposal.  Which terminals should be changed?

I wonder why some terminals support "dashlength" but not "solid|dash". 
That seems confusing. Should not all the dash-capable terminals support both 
options?

> >       set termoption {solid|dashed}
> 
> That would be tricky for postscript or pdf output if the file already
> is open, since the setting is currently done in the file header.
> But maybe it is possible.

Yes, it is possible to add
  /Solid false def
in the beginning of the plot, e.g. after
  /Helvetica findfont 140 scalefont setfont

---
PM

Ctrl+C - Re: windows terminal patches [1/6]

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

> > Does this mean we can close out some or all of these bugs?
> >  2848002   Ctrl+C crashes windows console build
> 
> No modification seems to be applied to plot.c
> 
>     (void) signal(SIGINT, (sigfunc) inter);
> 
> Perhaps this issue still remains.

Should I commit it to cvs?
http://sourceforge.net/tracker/?func=detail&aid=2848002&group_id=2055&atid=102055

Are there any other patches that need a commit?

---
PM

Re: windows terminal patches [1/6]

[Tatsuro M. <tma...@ya...>]

Hello

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> 
> --- Ethan Merritt  wrote:
> > Does this mean we can close out some or all of these bugs?
> >  2848002   Ctrl+C crashes windows console build
> 
> No modification seems to be applied to plot.c
> 
>     (void) signal(SIGINT, (sigfunc) inter);
> 
> Perhaps this issue still remains.

I have confirmed that the above is still unsolved.

Regards

Tatsuro

--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: windows terminal patches [1/6]

[Tatsuro M. <tma...@ya...>]

Hello

I have tested on windows xp

--- Benjamin Lindner  wrote:

> Petr Mikulik wrote:
> > 	Hello,
> >> I've updated the patches for the windows terminal to today's CVS snapshots for
> >> both 4.5.0 and 4.4.0 and added the corresponding changelog entries. They work
> >> under win xp and microsoft office.
> > 
> > thanks, I've committed all these patches.
> > 
> > I've tested them on Linux/Wine. There I've experienced crash when after
> > 	test
> > 	Ctrl-C in graph window (or copy to clipboard)
> > However, 
> > 	plot x
> > 	Ctrl-C in graph window (or copy to clipboard)
> > works fine (even when using title/ylabel with enhanced text strings).
> > 
> > Does this happen also on your set-up?
> 
> No I don't see this. both Ctrl+C and selecting the menu item work 
> correctly after a "test".

In my case, the above also worked correct.

BTW
gbuplot> test
Then copy to clipboard, paste to word 2003
The fill patterns are correct
The point type 7 seems to be normal

However, paste to
OpenOffice 3.1.0 OOO310m11 (build 9399)
The fill patterns are ignored and all are filled with black.
 
> > "Save as emf" also works correctly when I load that file into OpenOffice 
> > 3.2. Testing this by means of "test" command, I can see these two 
> > differences:
> > - fill patterns are ignored

First test was the same as what Petr reported.
However, after test, save emf file feature of 'test' screen worked fine.
Interestingly, even if, I have exit gnuplot once then 'test' from the first prompt, the feature of
save emf file of 'test' screen worked fine!

Regards

Tatsuro 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: windows terminal patches [1/6]

[Tatsuro M. <tma...@ya...>]

Hello


--- Ethan Merritt  wrote:
> Does this mean we can close out some or all of these bugs?
>  2848002   Ctrl+C crashes windows console build

No modification seems to be applied to plot.c

    (void) signal(SIGINT, (sigfunc) inter);

Perhaps this issue still remains.

Regards

Tatsuro

--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: dashes again

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

On Tuesday 16 February 2010 14:20:45 Petr Mikulik wrote:
> I raise questions about dash line patters from time to time (see e.g.
> messages "unified dashes"). Usually it happens when I try to do
> 	set term x11 dash
> 	plot x,-x,1,2,3
> and it comes out solid :-)
> 
> 1. It did not work in the morning, I had to find an older e-mail and
>    find there
>          xrdb -merge < Gnuplot.app-defaults
> 
> 1a. That seems to be a problem for ordinary users, because
>    file  Gnuplot.app-defaults  is not "make install"ed.

Yes it is.  There is some dispute, however, about whether there is a
standard place to install it. To resolve this, Christoph Junghans
added an explicit configuration option.  It is noted in the Changelog
as:
 
2010-02-07  Christoph Junghans (ottxor)
        * configure.in share/Makefile.am src/Makefile.am src/gplt_x11.c
        src/variable.c: Configurable X11 application resource path.
        Bug #2931287 #219323

> 1b. Further, gnuplot-x11 does not detect automatically that it cannot
>    draw dash lines because that xrdb command was not executed. Why it
>    does not help? 

Correction:  There is no requirement to run xrdb.  xrdb is one 
particular way you can modify the current X resource values from the
command line, but it is not the only way, not even the usual way.

>    It should write a warning when "gnuplot -dashed" or 
>    "set term x11 dash".

Gnuplot_x11 is not even running yet at the time you enter either of
these commands.  It is started up later, at the time of the first plot.

> 2. "dash" support was added into wxt terminal in June 2009, just after
>    4.4 branch separation. Shouldn't this be (back)ported to 4.4?

It is on my list of patches to apply after 4.4.0 is released.
I posted the full list the other day, but here it is again:
   winmain_va_copy      Allows building with Visual C
   wxt_dashed           set term wxt ... {dashed|solid} {dashlength <dl>}
   x11_mousewheel
   wxt_mousewheel
   pow_overflow         if i**j would cause integer overflow, return a float instead
   int_overflow         Check internal integer multiplications for overflow
   tikz                 remove conditional tests for version 4.3
   candle_width         optional 6th column containing box width
   rmargin              tweak left and right margins to be more like those prior to 4.2.4
   jw-refactor          clean up the execute-from-string operations lf_push/lf_pop
   cc-for-build         fix for building documentation during cross-compilation
   percent_s            support the "%s" format specifier in strftime()
   Kalinin_metapost     Fix inheritance of line thickness by text strings
   suppress_PDFMark     rearrange postscript prolog to allow customization
   timefmt              handle evaluated input values for time format "%s"
   init_func_points     initialize full coordinate structure for 2D functions

These are all non-trivial changes that were made subsequent to the code 
freeze for 4.4.0 (by "non-trivial" I mean "I was afraid they might possibly
break something).  During the -rc1 period I've only been applying bug fixes
and "trivial" changes to things like documentation.

> 3. Windows terminal supports solid, dash, dot-dash patterns via
>    its menu in the graph window, but it does not support
>       set term windows {solid|dashed}
>    Benjamin, can you please implement it?
> 
> 4. Should "all usual" terminals support both options
>       {solid|dash} {dashlength <dl>}  ?
>    Currently:
>      x11, svg: {solid|dash}
>      wxt, postscript: {dashed|solid} {dashlength <dl>}
>      png, pdf: {dashlength <dl>}

Not sure I understand your proposal.  Which terminals should be changed?

> and
>       set termoption {solid|dashed}

That would be tricky for postscript or pdf output if the file already
is open, since the setting is currently done in the file header.
But maybe it is possible.

	Ethan

dashes again

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

I raise questions about dash line patters from time to time (see e.g.
messages "unified dashes"). Usually it happens when I try to do
	set term x11 dash
	plot x,-x,1,2,3
and it comes out solid :-)

1. It did not work in the morning, I had to find an older e-mail and
   find there
         xrdb -merge < Gnuplot.app-defaults

1a. That seems to be a problem for ordinary users, because
   file  Gnuplot.app-defaults  is not "make install"ed.

1b. Further, gnuplot-x11 does not detect automatically that it cannot
   draw dash lines because that xrdb command was not executed. Why it
   does not help? It should write a warning when "gnuplot -dashed" or
   "set term x11 dash".

2. "dash" support was added into wxt terminal in June 2009, just after
   4.4 branch separation. Shouldn't this be (back)ported to 4.4?

3. Windows terminal supports solid, dash, dot-dash patterns via
   its menu in the graph window, but it does not support
      set term windows {solid|dashed}
   Benjamin, can you please implement it?

4. Should "all usual" terminals support both options
      {solid|dash} {dashlength <dl>}  ?
   Currently:
     x11, svg: {solid|dash}
     wxt, postscript: {dashed|solid} {dashlength <dl>}
     png, pdf: {dashlength <dl>}
and
      set termoption {solid|dashed}

---
PM

Wavelet Auditory Model Gnuplot Adaptation

[Mandeep B. <man...@gm...>]

Dear Gnuplot Developers:

My name is Mandeep Bedi and I am emailing you on behalf of the Wavelet
Auditory Model Group at the University of Maryland.  We are working on a
software project related to sound filtering and are interested in using
gnuplot for graphing data from our program and allowing user interface.  To
make gnuplot better suited for our project, we were interested in adding a
few features to it and would appreciate your feedback:

--The ability to "import" functions into gnuplot from from our project
library.  Our project is predominantly written in Java, and our idea is to
attach a shared object in the form of a .so file to gnuplot and then execute
a command that goes something like:

import function f(x) from 'wam.so'

so that we can use the function f(x) in our gnuplot script.

--We are also interested in adding functionality to gnuplot for importing
tabular data from our project, perhaps by a command like the following:

import datafile 'hello' from 'wam.so'

While gnuplot does already support file-reading, we are hoping to make more
use of the shared library idea introduced above, and were wondering what you
thought about this.

Thank you for your time.

Sincerely,
Mandeep Bedi

Re: windows terminal patches [1/6]

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

On Monday 15 February 2010 23:29:47 Petr Mikulik wrote:
> 	Hello,
> > 
> > I've updated the patches for the windows terminal to today's CVS snapshots for
> > both 4.5.0 and 4.4.0 and added the corresponding changelog entries. They work
> > under win xp and microsoft office.
> 
> thanks, I've committed all these patches.

Great!

Does this mean we can close out some or all of these bugs?
 2710337   screendump command under Windows
 2189383   win32 UI copy to clipboard unusable
 2848002   Ctrl+C crashes windows console build
 1918293   "Copy to Clipboard" on MS-Win32 clip "tails" of p,g,q and y


> I've tested them on Linux/Wine. There I've experienced crash when after
> 	test
> 	Ctrl-C in graph window (or copy to clipboard)
> However, 
> 	plot x
> 	Ctrl-C in graph window (or copy to clipboard)
> works fine (even when using title/ylabel with enhanced text strings).
> 
> Does this happen also on your set-up?

It would not surprise me that interrupting "test" fails, even though
interrupting a normal plot succeeds.  The "test" command does not set
up a full plot environment.  But it sounds fixable. 


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

Re: windows terminal patches [1/6]

[Benjamin L. <lin...@gm...>]

Petr Mikulik wrote:
> 	Hello,
>> I've updated the patches for the windows terminal to today's CVS snapshots for
>> both 4.5.0 and 4.4.0 and added the corresponding changelog entries. They work
>> under win xp and microsoft office.
> 
> thanks, I've committed all these patches.
> 
> I've tested them on Linux/Wine. There I've experienced crash when after
> 	test
> 	Ctrl-C in graph window (or copy to clipboard)
> However, 
> 	plot x
> 	Ctrl-C in graph window (or copy to clipboard)
> works fine (even when using title/ylabel with enhanced text strings).
> 
> Does this happen also on your set-up?

No I don't see this. both Ctrl+C and selecting the menu item work 
correctly after a "test".

> "Save as emf" also works correctly when I load that file into OpenOffice 
> 3.2. Testing this by means of "test" command, I can see these two 
> differences:
> - fill patterns are ignored
> - point type 7 looks like a very big circle (zoom it a bit). Under large
>   zoom, it looks like two misplaced circles, one full and one empty. Can you 
>   please have a look?

I don't have OpenOffice available right now, but I'll install it and check.

benjamin

Re: windows terminal patches [1/6]

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

	Hello,
> 
> I've updated the patches for the windows terminal to today's CVS snapshots for
> both 4.5.0 and 4.4.0 and added the corresponding changelog entries. They work
> under win xp and microsoft office.

thanks, I've committed all these patches.

I've tested them on Linux/Wine. There I've experienced crash when after
	test
	Ctrl-C in graph window (or copy to clipboard)
However, 
	plot x
	Ctrl-C in graph window (or copy to clipboard)
works fine (even when using title/ylabel with enhanced text strings).

Does this happen also on your set-up?

"Save as emf" also works correctly when I load that file into OpenOffice 
3.2. Testing this by means of "test" command, I can see these two 
differences:
- fill patterns are ignored
- point type 7 looks like a very big circle (zoom it a bit). Under large
  zoom, it looks like two misplaced circles, one full and one empty. Can you 
  please have a look?

Petr

windows terminal patches [6/6]

[Benjamin L. <lin...@gm...>]

Hello,

last patch in the series:

This patch adds the option "close" to the windows terminal driver.
I took the liberty of imitating the code of the wxt terminal and
adapt for the windows terminal.
I tested it for 4.5.0 and 4.4.0 on windows xp and it works OK.

benjamin

windows terminal patches [5/6]

[Benjamin L. <lin...@gm...>]

Hello,

the next patch in the series:

This one fixes the current behaviour of ignoring the explicit font name 
and size in "set label".

benjamin

windows terminal patches [1/6]

[Benjamin L. <lin...@gm...>]

Hello,

I've updated the patches for the windows terminal to today's CVS 
snapshots for both 4.5.0 and 4.4.0 and added the corresponding changelog 
entries. They work under win xp and microsoft office.

I've split it into several smaller patches as to easier check/maintain them.

Here's the first:
4.5.0_gp_emf-clipboard-copying.patch
4.4.0_gp_emf-clipboard-copying.patch

changes the copy-to-clipboard code to create an enhanced metafile and
cretaes a ctrl+c shortcut for it for the graph window only.

benjamin

windows terminal patches [4/6]

[Benjamin L. <lin...@gm...>]

Hello,

fourth patch in the series of windows term patches.
This one fixes a bug in a call to _getcwd in wmenu.c
The first parameter should be a char* but currently is of type char.
trivial fix attached.

benjamin

windows terminal patches [3/6]

[Benjamin L. <lin...@gm...>]

Hello,

And the next one in the windows term patch series:

This one implements the "size" and "position" options to the windows 
terminal driver.

benjamin

windows terminal patches [2/6]

[Benjamin L. <lin...@gm...>]

Hello,

here's the next patch for the windows terminal:

When developing the copy-to-clipboard code I realised that by virtually 
the same code one can save the EMF file to disk instead of copying it to 
the clipboard.
The attached patch implements a "Save As EMF..." feature for the windows
graph terminal, adds a menu entry and adds a Ctrl+S shortcut for the 
graph window.

benjamin

Re: htlatex?? in docs/Makefile.in in cvs source ( 2010-02-11)

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

shige 02/15 2010
----------------

Ethan Merritt wrote:
> For me latex2html no longer works. See for instance the recent bug
> report
> https://sourceforge.net/tracker/?func=detail&aid=2949058&group_id=2055&atid=102055

I think it is not a problem of latex2html, but by setting your 
latex2html. Please check the log of compiling of images.tex:
http://www.gnuplot.info/docs/images.log

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

Re: gnuplot-4.4.0-rc1 breaks gnuplot script

[Teo S B. <teo...@gm...>]

I gave an argument for allowing trailing definitions at bottom of
http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/9253


2010/2/14 Hans-Bernhard Bröker <HBB...@t-...>:
> Teo S Bernhard wrote:

<snipped>

>> - that it is gnuplot 4.4.0 rc1 that is at odds with the
>> documentation.
>
> I disagree with that claim.  It was the earlier versions that were at odds
> with the documentation, by allowing things that the documentation said they
> didn't.

I can agree that we have error if there is mismatch between program
behaviour and documentation.

It is, however, a matter of philosophy if it is the help text or the
implementation that is in error. In another reply I point to facts:
1) the BNF of the help text contradicts a certain help text example
showing leading definitions, and
2) the help text and the actual implementation (the code) is much more
liberal than the BNF-form in allowing definitions including trailing
ones

Here, I think the BNF is wrong. In the another reply I have suggested
a more correct BNF that is consistent with program behaviour and the
other help text.

Teo