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

Re: polygon issues

[Manfred S. <man...@gm...>]

Am Mittwoch, den 15.10.2008, 12:27 -0700 schrieb Ethan Merritt:
> On Wednesday 15 October 2008 08:05:26 Manfred Schwarb wrote:
> > Hi,
> > 
> > I'm experimenting with the new polygon object and encountered two stumbling blocks.
> > 
> > 1) I'm doing something like
> >      set object 1 polygon \
> >   from screen 0.820186699373,0.915943621944 \
> >      to screen 0.816522727098,0.922822961096 \
> >      to screen 0.824158694467,0.917927083652 \
> >      to screen 0.820186699373,0.915943621944 front fc ls 3 fs solid 1.0
> > 
> >   and I get "Polygon is not closed - adding extra vertex", although my polygon is 
> >   perfectly closed?
> 
> For what it's worth, I don't get that warning message when I cut-and-paste your
> above commands. Maybe it's due to rounding error when storing floating point numbers?
> But that warning should not harm anything.
> 

I didn't try it separately, but in a gnuplot script sketched as follows
  set term png truecolor
  set multiplot
  set pm3d interpolate 40,40 explicit map
  set object 1 polygon ...
  splot ... with pm3d
  ...
I got these warnings.

It's on a x86_64 box, this may be the difference (I vaguely remember
there is some excess precision on x68_32 [-mfpmath=387] or so).
For me it was just irritating, I checked the numbers at least twice and
could not find a typo ..

But in any case, I think for
  set object 1 polygon from x1,y1 to x2,y2
i.e. drawing a simple line, this message should be suppressed.

> > 2) clipping:
> >   At the plot borders, these objects seem to be clipped (cut off). As I use these objects as 
> >   somehow generic drawing objects in a mixture with "set arrow", things become 
> >   really messy, as arrows are not clipped.
> >   What I would need are objects that are not clipped, so I can use the whole screen.
> >   Up to now I found no way to deactivate this clipping feature. Is there a way to do so?
> 
> Heh.  You have no idea how much time I spent to get that clipping to work.
> 

Hmm :-) I guess doing this clipping is a reasonable default and what
most people probably expect.

> But yes, I can imagine there are cases when clipping is undesirable.
> The question is: is that a property of the object or a property of the whole plot?
> I'll have to think about it.
> 
> Which would be more obvious in your case?
>    set clip <something>
>    plot 'foo'
> or
>    set object 1 polygon noclip ....
>    plot 'foo'
> 

The meaning of "set clip" is already complicated enough, IMHO.
So I would be in favor of the noclip argument to "set object".

But either thing would be great.

Thanks!
Manfred

Re: polygon issues

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

On Wednesday 15 October 2008 08:05:26 Manfred Schwarb wrote:
> Hi,
> 
> I'm experimenting with the new polygon object and encountered two stumbling blocks.
> 
> 1) I'm doing something like
>      set object 1 polygon \
>   from screen 0.820186699373,0.915943621944 \
>      to screen 0.816522727098,0.922822961096 \
>      to screen 0.824158694467,0.917927083652 \
>      to screen 0.820186699373,0.915943621944 front fc ls 3 fs solid 1.0
> 
>   and I get "Polygon is not closed - adding extra vertex", although my polygon is 
>   perfectly closed?

For what it's worth, I don't get that warning message when I cut-and-paste your
above commands. Maybe it's due to rounding error when storing floating point numbers?
But that warning should not harm anything.

> 2) clipping:
>   At the plot borders, these objects seem to be clipped (cut off). As I use these objects as 
>   somehow generic drawing objects in a mixture with "set arrow", things become 
>   really messy, as arrows are not clipped.
>   What I would need are objects that are not clipped, so I can use the whole screen.
>   Up to now I found no way to deactivate this clipping feature. Is there a way to do so?

Heh.  You have no idea how much time I spent to get that clipping to work.

But yes, I can imagine there are cases when clipping is undesirable.
The question is: is that a property of the object or a property of the whole plot?
I'll have to think about it.

Which would be more obvious in your case?
   set clip <something>
   plot 'foo'
or
   set object 1 polygon noclip ....
   plot 'foo'

-- 
Ethan A Merritt

Re: extending pstricks terminal driver

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

On Wednesday 15 October 2008 03:36:53 Christoph Bersch wrote:
> Hi,
> 
> I am currently extending the pstricks terminal driver.
> 
> Besides some general improvements it should support all color commands 
> using the enhanced coloring capabilities of the xcolor package. As this 
> would not work with Tex but only with LaTeX, I will include it as an 
> option for the driver.

You correctly point out that the pstricks terminal driver has not been
kept fully up to date with new gnuplot features.  But gnuplot carries 
along many out-of-date drivers, so that by itself is not necessarily a
problem.

Probably it would be easy enough to add RGB color support using xcolor,
but adding support for the various "with image" modes would be a lot
more work.
 
I could offer more useful comments if I had a better understanding of
why people would choose to use pstricks rather than epslatex.
Is there some feature in pstricks that is missing from epslatex?

> Who is the maintainer of the pstricks driver? Is someone else currently 
> working on it and is it alright, if I extend it? (the last changelog in 
> the file is from Petr Mikulik from 2003).

We don't really have a list of official maintainers for individual
terminal drivers.  Feel free to submit patches via SourceForge.


 
> Christoph
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

polygon issues

[Manfred S. <man...@gm...>]

Hi,

I'm experimenting with the new polygon object and encountered two stumbling blocks.

1) I'm doing something like
     set object 1 polygon \
  from screen 0.820186699373,0.915943621944 \
     to screen 0.816522727098,0.922822961096 \
     to screen 0.824158694467,0.917927083652 \
     to screen 0.820186699373,0.915943621944 front fc ls 3 fs solid 1.0

  and I get "Polygon is not closed - adding extra vertex", although my polygon is 
  perfectly closed?

2) clipping:
  At the plot borders, these objects seem to be clipped (cut off). As I use these objects as 
  somehow generic drawing objects in a mixture with "set arrow", things become 
  really messy, as arrows are not clipped.
  What I would need are objects that are not clipped, so I can use the whole screen.
  Up to now I found no way to deactivate this clipping feature. Is there a way to do so?

Thanks,
Manfred


-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

special behavior of postscript terminal?

[Allin C. <cot...@wf...>]

With most terminal types, if you specify a color plot then it 
seems that by default solid lines are used, not dash patterns, for 
line graphs.  However, the postscript terminal behaves 
differently: it uses dash patterns by default even when color mode 
is selected.

I think it would be preferable if the post terminal behaved in the 
same way as the others.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

extending pstricks terminal driver

[Christoph B. <us...@be...>]

Hi,

I am currently extending the pstricks terminal driver.

Besides some general improvements it should support all color commands 
using the enhanced coloring capabilities of the xcolor package. As this 
would not work with Tex but only with LaTeX, I will include it as an 
option for the driver.

Who is the maintainer of the pstricks driver? Is someone else currently 
working on it and is it alright, if I extend it? (the last changelog in 
the file is from Petr Mikulik from 2003).

Christoph

Re: label docs

[James R. V. Z. <jr...@co...>]

Ethan A Merritt <merritt@u.washington.edu> wrote:

>   Unfortunately, the "title <columnno>" form is not quite interchangeable
>   with the usual title command. As the code is currently written, it must
>   come immediately after the 'using' clause.  This could be considered a
>   bug, but I don't know of an easy way to fix it.  Anyhow, as it stands,
>   that documentation change would be incorrect.  
>
>   e.g.
>      plot 'foo' using 1:2 title 2    linetype 5   # OK
>      plot 'foo' using 1:2 linetype 5 title "FOO"  # OK
>      plot 'foo' using 1:2 linetype 5 title 2      # fails

Ah - I thought I had run into a problem with option order, but
couldn't pin it down.  I'll add that to the "datastrings"
documentation.
 
           - Jim Van Zandt

Re: wgnuplot

[Nigel N. <nn...@gm...>]

Hi Petr,

> Gnuplot is not library with an API; instead, you use the gnuplot commands
> and pass them through a pipe - for this, a console app is needed.

A gnuplot session might boil down to this:

  while (!com_line) {
    readline();
    do_line();
  }

Our old wx translation drove gnuplot directly, using wx to handle user
strings and history. For realtime display of sim results, we assemble
gp_input_line programmatically.  So, with no pipe and no readline, a
plotting session becomes a sequence of calls to gnuplot's minimalist
API:

  do_line();

In this sense, we use gnuplot as a high-powered plotting library.
The issue of global variables may still be an... issue?

Nigel

Re: wxt by MingW - Re: Mac OS X and wxt

[Timothée L. <tim...@lp...>]

Petr Mikulik a écrit :
>> Yes, wxt does work for Windows. "Official" windows binaries that are 
>> distributed on our SourceForge page are not built with it though. With 
>> those, you have to use the default "win" terminal. To use wxt on Windows, 
>> you can either build gnuplot by yourself with MinGW or MSVC (MinGW should 
>> work with the untouched code base).
>> Additionally, Michael Goffioul has built a Windows package for Octave, 
>> that also contains gnuplot with wxt !
>>     
>
> I tried to compile gnuplot with wxt on Windows by MingW, but it failed. How 
> can I do it? I did the following:
>
> I have downloaded the files below from 
> 	http://www.gtk.org/download-windows.html
> and unzipped them into the MingW32 directory:
>
> 	cairo-dev-1.6.4-2.zip
> 	cairo-1.6.4-2.zip
> 	glib-dev_2.18.0-1_win32.zip
> 	glib_2.18.0-1_win32.zip
> 	pango-dev-1.20.5.zip
> 	pango-1.20.5.zip
>
> >From the wx homepage I've got and unzipped into D:/wxMSW-2.8.8
> 	wxMSW-2.8.8.zip
> These are source code. Unfortunately I couldn't compile it, the make always 
> failed in some part of its makefile.gcc. I couldn't repair it. Any idea what 
> to do?
>
>   
Hi Petr,

I think the way that has more chances to succeed to build wxMSW is to 
use the autotools instead of the makefile. You'll need autoconf, 
automake, pkgconfig (as you mention below), of course cairo, glib and 
pango (available as win32 binaries and headers on ftp.gtk.org), and 
possibily a couple of other tools/libraries (I remember having to 
install zlib).

> Anyway, I proceeded further. In gnuplot's makefile.mgw, I had to change:
> ifdef WXT
>         CFLAGS += -DWXWIDGETS -ID:/wxMSW-2.8.8/include
>         CFLAGS += -ID:/Apps/MingW32/MingW344/include/cairo
>         CFLAGS += -ID:/Apps/MingW32/MingW344/include/glib-2.0
>         WX_OBJS = wxt_gui.o gp_cairo.o
> endif
>
> because there is nothing like "wx-config" and "pkg-config" on my PATH as 
> shell'ed from makefile.mgw.
>
>   
Once you have built wxMSW, you'll get wx-config. You should install 
pkg-config too to get cairo and pango flags.

> In gnuplot/src/wxterminal/wx_gui.cpp, I had to uncomment this code:
> #ifdef __WXMSW__
>                 /* the following is done in wxEntry() with wxMSW only */
>                 wxSetInstance(GetModuleHandle(NULL));
>                 wxApp::m_nCmdShow = SW_SHOW;
> #endif
> because wxSetInstance() was not known.
>   
Did you mean "comment" or "uncomment" ?
> Then the compilation
>     make -f makefile.mgw
> worked.
>
> But linking does not work, it complains about many undefined references. It 
> seems wgnuplot.exe wants to be linked against the wx library.
Of course !

> But it was not 
> available as I couldn't compile it. I though the library may not be needed 
> and some dll's could be used instead -- Michael's wgnuplot has dependencies 
> to many dll's.
>   
You not only need dlls but also .lib files that correspond to symbol 
lists or something like that.

> Could somebody describe a procedure how to compile wxt under MingW? How to 
> have it static or with dll's?
>
> Thanks.
>
> ---
> PM
>   

I'll try, if I find some time...

Timothée Lecomte

Re: wgnuplot

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

> We can replace the Win32 code with wx code.

What about speed? For 2D maps, the WX terminal is still slower on X11 then 
the x11 terminal.

> We already support wxWidgets on MSWin, so far as I know.

Not very well - I cannot compile it. Instructions are missing. I've 
described problems with compilation in mail "Subject: wxt by MingW" on 4 Sep 
2008.

> It looks like the wx version is attempting to drive a wx gui from a
> console app.  I may have misunderstood this design. As a stand alone
> solution, this may work, but a more natural approach may be to have a
> gui wx app driving the gnuplot library code.  This allows us to expose
> gnuplot as a library of plotting routines.  Our simulation environment
> can then drive gnuplot, as we do wtih Vtk.

Gnuplot is not library with an API; instead, you use the gnuplot commands 
and pass them through a pipe - for this, a console app is needed.

---
PM

Re: wgnuplot

[Nigel N. <nn...@gm...>]

[My reply only went to Ethan.  Reposting to list.]

On Sun, Oct 12, 2008 at 7:00 PM, I replied...

Hello Ethan!

On Sun, Oct 12, 2008 at 5:20 PM, Ethan A Merritt
<merritt@u.washington.edu> wrote:
> On Saturday 11 October 2008, Nigel Nunn wrote:
>> Hi wgnuplotters,
>>
>> The old wgnuplot code maps very easily onto wxWidgets.
>
> I'm lost.  What do you mean "maps onto"?


We can replace the Win32 code with wx code.  One of the original
intentions for wx was to replace a cruddy MFC. This means upgrading
Win32 gui code is easy.

> We already support wxWidgets on MSWin, so far as I know.

It looks like the wx version is attempting to drive a wx gui from a
console app.  I may have misunderstood this design. As a stand alone
solution, this may work, but a more natural approach may be to have a
gui wx app driving the gnuplot library code.  This allows us to expose
gnuplot as a library of plotting routines.  Our simulation environment
can then drive gnuplot, as we do wtih Vtk.


>> After October 25 I will start reworking the current wgnuplot to handle
>> plotting duties inside our wxVtk simulation environment.  If anyone
>> has comments or suggestions (to help make this useful to a wider
>> group) please send them in.
>
> You should probably look at the work Michael Goffioul is doing.
> I don't understand this MSWin stuff, but I gather he's re-working the
> communication paths for wgnuplot to do away with any need for a
> separate pipe-handling program (pgnuplot).
>
>        Ethan

thanks for the suggestion!
Nigel

Re: wgnuplot

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

Hello

--- Nigel Nunn <nn...@gm...> wrote:

> Hi wgnuplotters,
> 
> The old wgnuplot code maps very easily onto wxWidgets.
> 
> After October 25 I will start reworking the current wgnuplot to handle
> plotting duties inside our wxVtk simulation environment.  If anyone
> has comments or suggestions (to help make this useful to a wider
> group) please send them in.
> 
> Nigel

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Saturday 11 October 2008, Nigel Nunn wrote:
> You should probably look at the work Michael Goffioul is doing.
> I don't understand this MSWin stuff, but I gather he's re-working the
> communication paths for wgnuplot to do away with any need for a 
> separate pipe-handling program (pgnuplot).
> 

Now Benjamin Linder also have worked on console mode gnuplot 4.3 (cvs) for windows on mingw platform.
To see Michael Goffioul's and Benjamin Linder's works, please go to

Michael Goffioul 
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Windows/msvc/libs/

Benjamin Linder
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Windows/mingw32/tools/gnuplot/

Regards

Tatsuro  

--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: wgnuplot

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

On Saturday 11 October 2008, Nigel Nunn wrote:
> Hi wgnuplotters,
> 
> The old wgnuplot code maps very easily onto wxWidgets.

I'm lost.  What do you mean "maps onto"?
We already support wxWidgets on MSWin, so far as I know.

> After October 25 I will start reworking the current wgnuplot to handle
> plotting duties inside our wxVtk simulation environment.  If anyone
> has comments or suggestions (to help make this useful to a wider
> group) please send them in.

You should probably look at the work Michael Goffioul is doing.
I don't understand this MSWin stuff, but I gather he's re-working the
communication paths for wgnuplot to do away with any need for a 
separate pipe-handling program (pgnuplot).

	Ethan

 
> Nigel
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt

wgnuplot

[Nigel N. <nn...@gm...>]

Hi wgnuplotters,

The old wgnuplot code maps very easily onto wxWidgets.

After October 25 I will start reworking the current wgnuplot to handle
plotting duties inside our wxVtk simulation environment.  If anyone
has comments or suggestions (to help make this useful to a wider
group) please send them in.

Nigel

Re: label docs

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

On Saturday 11 October 2008, James R. Van Zandt wrote:
> 
> In the process, I discovered that the title in the key could come from
> a column heading in the data file.  That wasn't mentioned under "help
> plot title", so I added a cross reference for that, too.  I thought
> about changing the syntax example from
> 
>        title "<title>" | notitle ["<ignored title>"]
> to
>        title "<title>" | title <columnnumber> | notitle ["<ignored title>"]
> 
> Should I?

Unfortunately, the "title <columnno>" form is not quite interchangeable
with the usual title command. As the code is currently written, it must
come immediately after the 'using' clause.  This could be considered a
bug, but I don't know of an easy way to fix it.  Anyhow, as it stands,
that documentation change would be incorrect.  

e.g.
   plot 'foo' using 1:2 title 2    linetype 5   # OK
   plot 'foo' using 1:2 linetype 5 title "FOO"  # OK
   plot 'foo' using 1:2 linetype 5 title 2      # fails

-- 
Ethan A Merritt

label docs

[James R. V. Z. <jr...@co...>]

I remember seeing there was now a way label each data point with a
string read from the data file, but I couldn't find the command in the
help file.  Eventually I resorted to running demo scripts until I
found an example.  I just added some cross-references in gnuplot.doc.

In the process, I discovered that the title in the key could come from
a column heading in the data file.  That wasn't mentioned under "help
plot title", so I added a cross reference for that, too.  I thought
about changing the syntax example from

       title "<title>" | notitle ["<ignored title>"]
to
       title "<title>" | title <columnnumber> | notitle ["<ignored title>"]

Should I?

        - Jim Van Zandt

Re: line color lacking on clipboard (wgnuplot)

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

shige 10/11 2008
----------------

Ethan Merritt <merritt@u.washington.edu> wrote:
| Does this mean that the clipboard still has a problem with 
| colored lines with linewidth > 1 ?

Yes, it seems to remain. 

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

Re: line color lacking on clipboard (wgnuplot)

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

On Friday 10 October 2008 03:32:22 Shigeharu TAKENO wrote:
> shige 10/10 2008
> ----------------
> 
> Ethan Merritt <merritt@u.washington.edu> wrote:
> | A bit of Googling suggests that the problem may be because we switched from
> | using CreatePenIndirect() to using ExtCreatePen().  Apparently some versions
> | of Windows have trouble with ExtCreatePen and the clipboard.
> 
> Thank you for your information.
> 
> The following patch forces wgnuplot to use CreatePenIndirect() if
> line_width==1. Certainly, the graph by "plot sin(x)" (made by 
> CreatePenIndirect()) can be copied through the clipboard with no 
> problem and the copying of the graph by "plot sin(x) lw 5"
> (made by ExtCreatePen()) loses the color, at least on my PC 
> (MS-Windows XP).

OK. Applied to CVS for both 4.2 and 4.3

Does this mean that the clipboard still has a problem with 
colored lines with linewidth > 1 ?


> 
> ----- From here -----
> --- src/win/wgraph.c.ORG	Thu Oct  9 08:23:00 2008
> +++ src/win/wgraph.c	Fri Oct 10 19:12:10 2008
> @@ -939,13 +939,23 @@
>  		if (line_width != 1)
>  		    cur_penstruct.lopnWidth.x *= line_width;
>  	
> -		/* use ExtCreatePeninstead of CreatePen/CreatePenIndirect to support
> +		/* use ExtCreatePen instead of CreatePen/CreatePenIndirect to support
>  		 * dashed lines if line_width > 1 */
>  		lb.lbStyle = BS_SOLID;
>  		lb.lbColor = cur_penstruct.lopnColor;
> +/* shige */
> +#if 0
>  		lpgw->hapen = ExtCreatePen(
>  		        (line_width==1 ? PS_COSMETIC : PS_GEOMETRIC) | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL, 
>  			cur_penstruct.lopnWidth.x, &lb, 0, 0);
> +#else
> +		if (line_width==1)
> +		  lpgw->hapen = CreatePenIndirect((LOGPEN FAR *) &cur_penstruct);
> +		else
> +		  lpgw->hapen = ExtCreatePen(
> +		        PS_GEOMETRIC | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL, 
> +			cur_penstruct.lopnWidth.x, &lb, 0, 0);
> +#endif
>  		DeleteObject(SelectObject(hdc, lpgw->hapen));
>  
>  		SelectObject(hdc, lpgw->colorbrush[cur_pen]);
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 



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

Re: line color lacking on clipboard (wgnuplot)

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

shige 10/10 2008
----------------

Ethan Merritt <merritt@u.washington.edu> wrote:
| A bit of Googling suggests that the problem may be because we switched from
| using CreatePenIndirect() to using ExtCreatePen().  Apparently some versions
| of Windows have trouble with ExtCreatePen and the clipboard.

Thank you for your information.

The following patch forces wgnuplot to use CreatePenIndirect() if
line_width==1. Certainly, the graph by "plot sin(x)" (made by 
CreatePenIndirect()) can be copied through the clipboard with no 
problem and the copying of the graph by "plot sin(x) lw 5"
(made by ExtCreatePen()) loses the color, at least on my PC 
(MS-Windows XP).

----- From here -----
--- src/win/wgraph.c.ORG	Thu Oct  9 08:23:00 2008
+++ src/win/wgraph.c	Fri Oct 10 19:12:10 2008
@@ -939,13 +939,23 @@
 		if (line_width != 1)
 		    cur_penstruct.lopnWidth.x *= line_width;
 	
-		/* use ExtCreatePeninstead of CreatePen/CreatePenIndirect to support
+		/* use ExtCreatePen instead of CreatePen/CreatePenIndirect to support
 		 * dashed lines if line_width > 1 */
 		lb.lbStyle = BS_SOLID;
 		lb.lbColor = cur_penstruct.lopnColor;
+/* shige */
+#if 0
 		lpgw->hapen = ExtCreatePen(
 		        (line_width==1 ? PS_COSMETIC : PS_GEOMETRIC) | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL, 
 			cur_penstruct.lopnWidth.x, &lb, 0, 0);
+#else
+		if (line_width==1)
+		  lpgw->hapen = CreatePenIndirect((LOGPEN FAR *) &cur_penstruct);
+		else
+		  lpgw->hapen = ExtCreatePen(
+		        PS_GEOMETRIC | cur_penstruct.lopnStyle | PS_ENDCAP_FLAT | PS_JOIN_BEVEL, 
+			cur_penstruct.lopnWidth.x, &lb, 0, 0);
+#endif
 		DeleteObject(SelectObject(hdc, lpgw->hapen));
 
 		SelectObject(hdc, lpgw->colorbrush[cur_pen]);
----- To here -----

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

Re: line color lacking on clipboard (wgnuplot)

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

On Thursday 09 October 2008 10:58, Bastian Maerkisch wrote:
> Treatment of line colors within the windows terminal is known to be buggy.

If I understand the report correctly, the problem is not with gnuplot's
display of colors. It is instead reporting a problem with the Windows
clipboard operation.

A bit of Googling suggests that the problem may be because we switched from
using CreatePenIndirect() to using ExtCreatePen().  Apparently some versions
of Windows have trouble with ExtCreatePen and the clipboard.
But I did not find a definitive statement or a recommended alternative.

> Currently, nobody is working actively on the windows terminal. I really 
> would want to help, but due to my work load, I just cannot find enough time.

Understood.  But it would be useful to know if you can replicate
the problem on your Windows machine, and whether switching that
one call back to CreatePenIndirect() fixes it.  (I realize that would
re-introduce other problems, but at least we'd confirm what the issue is).

	Ethan

> 
> Bastian
> 
> 
> Shigeharu TAKENO schrieb:
> > shige 10/09 2008
> > ----------------
> > 
> > On Japanese gnuplot BBS, the following problem was reported:
> > 
> >  Line colors of wgnuplot's graph (ex. `test` command) may lack on
> >  another application which recieve it through the clipboard. This
> >  problem arises in wgnuplot-4.2.4 but not 4.2.3.
> > 
> > It seems to be arise from src/win/wgraph.c rev.1.58. In fact, 
> > wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
> > not know which code has the problem and how to fix it.
> > 
> > +========================================================+
> >  Shigeharu TAKENO     NIigata Institute of Technology
> >                        kashiwazaki,Niigata 945-1195 JAPAN
> >  sh...@ie...   TEL(&FAX): +81-257-22-8161
> > +========================================================+
> > 
-- 
Ethan A Merritt

Re: line color lacking on clipboard (wgnuplot)

[Bastian M. <bma...@we...>]

Treatment of line colors within the windows terminal is known to be buggy.
Currently, nobody is working actively on the windows terminal. I really 
would want to help, but due to my work load, I just cannot find enough time.

Bastian


Shigeharu TAKENO schrieb:
> shige 10/09 2008
> ----------------
> 
> On Japanese gnuplot BBS, the following problem was reported:
> 
>  Line colors of wgnuplot's graph (ex. `test` command) may lack on
>  another application which recieve it through the clipboard. This
>  problem arises in wgnuplot-4.2.4 but not 4.2.3.
> 
> It seems to be arise from src/win/wgraph.c rev.1.58. In fact, 
> wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
> not know which code has the problem and how to fix it.
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Bastian Märkisch
Physikalisches Institut, Universität Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549239
Fax: +49-6221-549343

line color lacking on clipboard (wgnuplot)

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

shige 10/09 2008
----------------

On Japanese gnuplot BBS, the following problem was reported:

 Line colors of wgnuplot's graph (ex. `test` command) may lack on
 another application which recieve it through the clipboard. This
 problem arises in wgnuplot-4.2.4 but not 4.2.3.

It seems to be arise from src/win/wgraph.c rev.1.58. In fact, 
wgnuplot with wgraph.c of rev.1.57 has no such problem. But I do
not know which code has the problem and how to fix it.

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

Re: Death of usenet

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

Philipp K. Janert wrote:

> And should the gnuplot newsgroup be shuttered down?

It's not up to us to decide about the fate of the newsgroup.  We 
couldn't shut it down even if we wanted to.

Re: Death of usenet

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

On Monday 29 September 2008 18:21:57 Philipp K. Janert wrote:
> 
> All of this brings me back to my original question:
> 
> 	Should there be only a single user-discussion
> 	forum (in addition to the devel list), and should
> 	this forum be the sourceforge mailiing list
> 	gnu...@li...? And should
> 	the gnuplot newsgroup be shuttered down?
> 
> It strikes me as a good idea. Having two forums is
> confusing and unnecessary. And a mailing list seems
> to be more accepted these days than usenet.

My observation is that the newsgroup continues to be more active
than all of the mailing lists taken together.



> 
> On Monday 29 September 2008 12:47, you wrote:
> > Philipp K. Janert wrote:
> > > I learned recently that one can subscribe to usenet groups
> > > via Google Groups, so that one gets usenet postings via
> > > email. I have used Google's web interface to post.
> >
> > So have a lot of others.  Which only contributes to Google's "success"
> > as the single biggest source of USENET's problems these days.
> >
> > Google groups sucks badly as a posting interface.  It's the only system
> > that ever managed to create even more broken postings than Outlook.
> >
> > Gmail accounts have become today's source #1 for USENET spam.
> >
> > Reaping Google's adword payouts on Google's own blogspot pages has
> > become a major motive for USENET spam.
> >
> > And last but not least, groups.google.com has so completely clouded the
> > distinction between actual USENET and their own, Google-only discussion
> > groups that many people no longer know the difference.
> >
> > > That being said, I find it confusing to have a gnuplot
> > > users mailing list (gnu...@li...)
> > > AND a users newsgroup (comp.graphics.apps.gnuplot).
> >
> > They used to be bidirectionally gatewayed to each other.  This died
> > years ago, when we lost support by Dartmouth.edu.  Sourceforge.net
> > doesn't offer a USENET gateway.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: Death of usenet

[Philipp K. J. <ja...@ie...>]

All of this brings me back to my original question:

	Should there be only a single user-discussion
	forum (in addition to the devel list), and should
	this forum be the sourceforge mailiing list
	gnu...@li...? And should
	the gnuplot newsgroup be shuttered down?

It strikes me as a good idea. Having two forums is
confusing and unnecessary. And a mailing list seems
to be more accepted these days than usenet.

Best,

		Ph.



On Monday 29 September 2008 12:47, you wrote:
> Philipp K. Janert wrote:
> > I learned recently that one can subscribe to usenet groups
> > via Google Groups, so that one gets usenet postings via
> > email. I have used Google's web interface to post.
>
> So have a lot of others.  Which only contributes to Google's "success"
> as the single biggest source of USENET's problems these days.
>
> Google groups sucks badly as a posting interface.  It's the only system
> that ever managed to create even more broken postings than Outlook.
>
> Gmail accounts have become today's source #1 for USENET spam.
>
> Reaping Google's adword payouts on Google's own blogspot pages has
> become a major motive for USENET spam.
>
> And last but not least, groups.google.com has so completely clouded the
> distinction between actual USENET and their own, Google-only discussion
> groups that many people no longer know the difference.
>
> > That being said, I find it confusing to have a gnuplot
> > users mailing list (gnu...@li...)
> > AND a users newsgroup (comp.graphics.apps.gnuplot).
>
> They used to be bidirectionally gatewayed to each other.  This died
> years ago, when we lost support by Dartmouth.edu.  Sourceforge.net
> doesn't offer a USENET gateway.