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

Re: TERM_MONOCHROME

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

On Sun, Jul 12, 2009 at 19:11, Ethan Merritt wrote:
> On Sunday 12 July 2009, Mojca Miklavec wrote:
>> Hello,
>>
>> What exactly does "TERM_MONOCHROME" flag do (what consequences should it have)?
>
> As explained in the ChangeLog for this recent addition, it indicates that the
> terminal is currently in monochrome mode (usually because of the command
> 'set term ... monochrome'.  The core code does not use the flag yet.
> It was added in preparation for a series of patches that allows the user to
> redefine the default sequence of line properties.
>  #2004590       mechanism to redefine base linetypes

Thanks a lot. Reading this entry in tracker explained it, I think.

This means that
    set term something monochrome
    set linetype 1 lw 2 lc rgb "blue" pointtype 6
will send
    "set_color(black)"
to terminal instead of rgb value for blue?

> The idea is that even if the terminal is capable of RGB colors, and the
> user redefines linetype N to be purple, if the terminal is currently showing
> the TERM_MONOCHROME flag then the core code should interpret "lt 3" as
> black and perhaps dashed rather than as purple.

Thanks,
    Mojca

Re: TERM_MONOCHROME

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

On Sunday 12 July 2009, Mojca Miklavec wrote:
> Hello,
> 
> What exactly does "TERM_MONOCHROME" flag do (what consequences should it have)?

As explained in the ChangeLog for this recent addition, it indicates that the
terminal is currently in monochrome mode (usually because of the command
'set term ... monochrome'.  The core code does not use the flag yet.
It was added in preparation for a series of patches that allows the user to
redefine the default sequence of line properties.
  #2004590  	 mechanism to redefine base linetypes
The idea is that even if the terminal is capable of RGB colors, and the 
user redefines linetype N to be purple, if the terminal is currently showing
the TERM_MONOCHROME flag then the core code should interpret "lt 3" as
black and perhaps dashed rather than as purple.

TERM_MONOCHROME

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

Hello,

What exactly does "TERM_MONOCHROME" flag do (what consequences should it have)?

Thanks,
   Mojca

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello
***********
Ugh. I am about ready to give up on this one. 
Could you please add a line to Petr's test script: 

> set title 'HELLO' tc rgb "blue" 
> set style rectangle fs solid 1.0 noborder 
> set object 1 rect from 0,0 to 5,5 fc rgb "blue" 
> set object 2 rect from -6,-6 to -1,-1 fc lt 3 
> plot x 
************

I test it the result is the same as the petr reported first 
=> title is blue, but both rectangles are black. 
no boarder colors appear with 
set style rectangle fs solid 1.0 noborder 
 

***************************
And just to confirm that the right configuration is being tested... 
My recent patch is against the current cvs source. 
That is, you must undo the original temporary test patch I sent 
that commented out a line in win.trm.  Please confirm that the 
old patch below was removed before your test of the new patch. 

>--- gnuplot/term/win.trm        2009-06-07 21:37:29.000000000 -0700 
>+++ gnuplot-cvs/term/win.trm    2009-07-09 23:33:55.000000000 -0700 
>@@ -621,7 +621,9 @@ WIN_boxfill( 
> { 
>     /* split into two commands to squeeze through all the necessary info 
> */ /* Notice HBB 20010208: --> WIN_move() */ 
>+#if (0) /* Broken! */ 
>     GraphOp(&graphwin, W_fillstyle, style, 0, NULL); 
>+#endif 
>     GraphOp(&graphwin, W_move, xleft, ybottom, NULL); 
>     GraphOp(&graphwin, W_boxfill, width, height, NULL); 
> }
«  [hide part of quote]
******************
I have erased makefile.mgw, re-checkout and and patched confirming the above.
The results are the same as 

I test it the result is the same as the petr reported first 
=> title is blue, but both rectangles are black. 
no boarder colors appear with 
set style rectangle fs solid 1.0 noborder 
  
***********
I could wish that we had a more active set of Windows coders among the 
current group of gnuplot developers. 

        Thanks for your patience, 
*************

Thank you for your all efforts of this matter.

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Saturday 11 July 2009, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried your patch
> 
> set title 'HELLO' tc rgb "blue"
> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> plot x
> 
> => title is blue, but both rectangles are black and their boarders are red
> (red is color of the line of plot x)
> 
> After I copy the graph to clip board and paste it to a software
> 
> => title is blue, but the rectangle 1 is blue and its boarder is red, 
> and the rectangle 2 is black and its boarder is red 

Ugh. I am about ready to give up on this one. 
Could you please add a line to Petr's test script:

> set title 'HELLO' tc rgb "blue"
> set style rectangle fs solid 1.0 noborder
> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> plot x


And just to confirm that the right configuration is being tested...
My recent patch is against the current cvs source.
That is, you must undo the original temporary test patch I sent
that commented out a line in win.trm.  Please confirm that the
old patch below was removed before your test of the new patch.

>--- gnuplot/term/win.trm        2009-06-07 21:37:29.000000000 -0700
>+++ gnuplot-cvs/term/win.trm    2009-07-09 23:33:55.000000000 -0700
>@@ -621,7 +621,9 @@ WIN_boxfill(
> {
>     /* split into two commands to squeeze through all the necessary info
> */ /* Notice HBB 20010208: --> WIN_move() */
>+#if (0) /* Broken! */
>     GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
>+#endif
>     GraphOp(&graphwin, W_move, xleft, ybottom, NULL);
>     GraphOp(&graphwin, W_boxfill, width, height, NULL);
> }

I could wish that we had a more active set of Windows coders among the 
current group of gnuplot developers.

	Thanks for your patience,

		Ethan


> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt wrote:
> 
> > 
> >   Sorry, it should be curptr->y
> >   
> >   Also I found that the windows terminal is affected by the same bug
> >   reported last week for the postscript terminal.
> > 
> >   Revised patch attached.
> >   
> > > diff -urp gnuplot/term/win.trm gnuplot-cvs/term/win.trm
> > --- gnuplot/term/win.trm	2009-06-07 21:37:29.000000000 -0700
> > +++ gnuplot-cvs/term/win.trm	2009-07-11 10:14:53.000000000 -0700
> > @@ -595,8 +595,7 @@ WIN_set_color(t_colorspec *colorspec)
> >  	    GraphOp(&graphwin, W_pm3d_setcolor, (colorspec->lt) & 0xffff, 0xff00 | ((colorspec->lt >>
> > 16) & 0x00ff), NULL);
> >  	    break;
> >  	case TC_LT:
> > -	    /* set color only when second parameter to W_line_type equals 1 */
> > -	    GraphOp(&graphwin, W_line_type, colorspec->lt, 1, NULL);
> > +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
> >  	    break;
> >      }
> >      WIN_last_linetype = LT_NODRAW;
> > diff -rup gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> > --- gnuplot/src/win/wgraph.c	2009-03-23 16:12:50.000000000 -0700
> > +++ gnuplot-cvs/src/win/wgraph.c	2009-07-11 10:14:56.000000000 -0700
> > @@ -1023,10 +1023,14 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
> >  			idx = 0;
> >  		    SelectObject(hdc, pattern_brush[idx]);
> >  		    break;
> > +		case FS_DEFAULT:
> > +		    /* Leave the current color in place */
> > +		    break;
> >  		case FS_EMPTY:
> >  		default:
> > -		    /* style == 0 or unknown --> fill with background color */
> > +		    /* fill with background color */
> >  		    SelectObject(hdc, halftone_brush[0]);
> > +		    break;
> >  	    }
> >  	    /* needs to be fixed for monochrome devices */
> >  	    /* FIXME: probably should keep track of text color */
> > @@ -1104,12 +1108,16 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
> >  		LOGBRUSH lb;
> >  
> >  		/* distinguish gray values and RGB colors */
> > -		if (curptr->y == 0) {
> > +		if (curptr->y == 0) {			/* TC_FRAC */
> >  		    rgb255_color rgb255;
> >  		    rgb255maxcolors_from_gray(curptr->x / (double)WIN_PAL_COLORS, &rgb255);
> >  		    c = RGB(rgb255.r, rgb255.g, rgb255.b);
> >  		}
> > -		else {
> > +		else if (curptr->y == (TC_LT << 8)) {	/* TC_LT */
> > +		    short pen = (curptr->x < (WORD)(-2)) ? (curptr->x % WGNUMPENS) + 2 : curptr->x + 2;
> > +		    c = lpgw->colorbrush[pen];
> > +		}
> > +		else {					/* TC_RGB */
> >  		    c = RGB(curptr->y & 0xff, (curptr->x >> 8) & 0xff, curptr->x & 0xff);
> >  		}
> >  
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

I have tried your patch

set title 'HELLO' tc rgb "blue"
set object 1 rect from 0,0 to 5,5 fc rgb "blue"
set object 2 rect from -6,-6 to -1,-1 fc lt 3
plot x

=> title is blue, but both rectangles are black and their boarders are red
(red is color of the line of plot x)

After I copy the graph to clip board and paste it to a software

=> title is blue, but the rectangle 1 is blue and its boarder is red, 
and the rectangle 2 is black and its boarder is red 

Regards

Tatsuro

--- Ethan Merritt wrote:

> 
>   Sorry, it should be curptr->y
>   
>   Also I found that the windows terminal is affected by the same bug
>   reported last week for the postscript terminal.
> 
>   Revised patch attached.
>   
> > diff -urp gnuplot/term/win.trm gnuplot-cvs/term/win.trm
> --- gnuplot/term/win.trm	2009-06-07 21:37:29.000000000 -0700
> +++ gnuplot-cvs/term/win.trm	2009-07-11 10:14:53.000000000 -0700
> @@ -595,8 +595,7 @@ WIN_set_color(t_colorspec *colorspec)
>  	    GraphOp(&graphwin, W_pm3d_setcolor, (colorspec->lt) & 0xffff, 0xff00 | ((colorspec->lt >>
> 16) & 0x00ff), NULL);
>  	    break;
>  	case TC_LT:
> -	    /* set color only when second parameter to W_line_type equals 1 */
> -	    GraphOp(&graphwin, W_line_type, colorspec->lt, 1, NULL);
> +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
>  	    break;
>      }
>      WIN_last_linetype = LT_NODRAW;
> diff -rup gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> --- gnuplot/src/win/wgraph.c	2009-03-23 16:12:50.000000000 -0700
> +++ gnuplot-cvs/src/win/wgraph.c	2009-07-11 10:14:56.000000000 -0700
> @@ -1023,10 +1023,14 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
>  			idx = 0;
>  		    SelectObject(hdc, pattern_brush[idx]);
>  		    break;
> +		case FS_DEFAULT:
> +		    /* Leave the current color in place */
> +		    break;
>  		case FS_EMPTY:
>  		default:
> -		    /* style == 0 or unknown --> fill with background color */
> +		    /* fill with background color */
>  		    SelectObject(hdc, halftone_brush[0]);
> +		    break;
>  	    }
>  	    /* needs to be fixed for monochrome devices */
>  	    /* FIXME: probably should keep track of text color */
> @@ -1104,12 +1108,16 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
>  		LOGBRUSH lb;
>  
>  		/* distinguish gray values and RGB colors */
> -		if (curptr->y == 0) {
> +		if (curptr->y == 0) {			/* TC_FRAC */
>  		    rgb255_color rgb255;
>  		    rgb255maxcolors_from_gray(curptr->x / (double)WIN_PAL_COLORS, &rgb255);
>  		    c = RGB(rgb255.r, rgb255.g, rgb255.b);
>  		}
> -		else {
> +		else if (curptr->y == (TC_LT << 8)) {	/* TC_LT */
> +		    short pen = (curptr->x < (WORD)(-2)) ? (curptr->x % WGNUMPENS) + 2 : curptr->x + 2;
> +		    c = lpgw->colorbrush[pen];
> +		}
> +		else {					/* TC_RGB */
>  		    c = RGB(curptr->y & 0xff, (curptr->x >> 8) & 0xff, curptr->x & 0xff);
>  		}
>  
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Saturday 11 July 2009, Ethan Merritt wrote:
> On Saturday 11 July 2009, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > 
> > The patch did not go well.
> > 
> > The petr's test gave the same results as those indicated by Petr.
> > 
> > I have two question
> > 
> > One is mere mistype
> > 
> > > +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
> > else if (curptr-> 
> > is to be
> > else if (curptr->x
> > ?
> 
> Yes, it should be curptr->x

  Sorry, it should be curptr->y
  
  Also I found that the windows terminal is affected by the same bug
  reported last week for the postscript terminal.

  Revised patch attached.
  

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Saturday 11 July 2009, Tatsuro MATSUOKA wrote:
> Hello
> 
> 
> The patch did not go well.
> 
> The petr's test gave the same results as those indicated by Petr.
> 
> I have two question
> 
> One is mere mistype
> 
> > +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
> else if (curptr-> 
> is to be
> else if (curptr->x
> ?

Yes, it should be curptr->x
 
> 
> The other is questionable
> 
> > +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
> 
> Why is the second argument W_pm3d_setcolor ?
> Before modification  the second argument was W_line_type.

Exactly. That is is heart of the problem.  A call to set_color() is only supposed
to change the color.  But the windows implementation was instaed using W_line_type,
which changes _all_ the line properties, not just color.


> If I wrote the second argument as W_line_type, this give rectangles are black but borders of the
> rectangles are blue.
> 
> Perhaps the second argument should be set right but I could not find what was correct.
> 
> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt <merritt@u.washington.edu> wrote:
> 
> > On Friday 10 July 2009 14:19:23 Ethan Merritt wrote:
> > 
> > > Please try this more complete patch instead of the above quick test.
> > > [beware:  untested!]
> > 
> > So sorry.  I attached the wrong patch.
> > Please try this one instead.
> > 
> > 
> > -- 
> > Ethan A Merritt
> > > diff -urp gnuplot/term/win.trm gnuplot-cvs/term/win.trm
> > --- gnuplot/term/win.trm	2009-06-08 09:09:47.000000000 -0700
> > +++ gnuplot-cvs/term/win.trm	2009-07-10 14:03:46.000000000 -0700
> > @@ -595,8 +595,7 @@ WIN_set_color(t_colorspec *colorspec)
> >  	    GraphOp(&graphwin, W_pm3d_setcolor, (colorspec->lt) & 0xffff, 0xff00 | ((colorspec->lt >>
> > 16) & 0x00ff), NULL);
> >  	    break;
> >  	case TC_LT:
> > -	    /* set color only when second parameter to W_line_type equals 1 */
> > -	    GraphOp(&graphwin, W_line_type, colorspec->lt, 1, NULL);
> > +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
> >  	    break;
> >      }
> >      WIN_last_linetype = LT_NODRAW;
> > diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> > --- gnuplot/src/win/wgraph.c	2009-03-24 09:27:40.000000000 -0700
> > +++ gnuplot-cvs/src/win/wgraph.c	2009-07-10 14:09:41.000000000 -0700
> > @@ -1104,12 +1104,16 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
> >  		LOGBRUSH lb;
> >  
> >  		/* distinguish gray values and RGB colors */
> > -		if (curptr->y == 0) {
> > +		if (curptr->y == 0) {			/* TC_FRAC */
> >  		    rgb255_color rgb255;
> >  		    rgb255maxcolors_from_gray(curptr->x / (double)WIN_PAL_COLORS, &rgb255);
> >  		    c = RGB(rgb255.r, rgb255.g, rgb255.b);
> >  		}
> > -		else {
> > +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
> > +		    short pen = (curptr->x < (WORD)(-2)) ? (curptr->x % WGNUMPENS) + 2 : curptr->x + 2;
> > +		    c = lpgw->colorbrush[pen];
> > +		}
> > +		else {					/* TC_RGB */
> >  		    c = RGB(curptr->y & 0xff, (curptr->x >> 8) & 0xff, curptr->x & 0xff);
> >  		}
> >  
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello


The patch did not go well.

The petr's test gave the same results as those indicated by Petr.

I have two question

One is mere mistype

> +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
else if (curptr-> 
is to be
else if (curptr->x
?


The other is questionable

> +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);

Why is the second argument W_pm3d_setcolor ?
Before modification  the second argument was W_line_type.
If I wrote the second argument as W_line_type, this give rectangles are black but borders of the
rectangles are blue.

Perhaps the second argument should be set right but I could not find what was correct.

Regards

Tatsuro

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

> On Friday 10 July 2009 14:19:23 Ethan Merritt wrote:
> 
> > Please try this more complete patch instead of the above quick test.
> > [beware:  untested!]
> 
> So sorry.  I attached the wrong patch.
> Please try this one instead.
> 
> 
> -- 
> Ethan A Merritt
> > diff -urp gnuplot/term/win.trm gnuplot-cvs/term/win.trm
> --- gnuplot/term/win.trm	2009-06-08 09:09:47.000000000 -0700
> +++ gnuplot-cvs/term/win.trm	2009-07-10 14:03:46.000000000 -0700
> @@ -595,8 +595,7 @@ WIN_set_color(t_colorspec *colorspec)
>  	    GraphOp(&graphwin, W_pm3d_setcolor, (colorspec->lt) & 0xffff, 0xff00 | ((colorspec->lt >>
> 16) & 0x00ff), NULL);
>  	    break;
>  	case TC_LT:
> -	    /* set color only when second parameter to W_line_type equals 1 */
> -	    GraphOp(&graphwin, W_line_type, colorspec->lt, 1, NULL);
> +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
>  	    break;
>      }
>      WIN_last_linetype = LT_NODRAW;
> diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> --- gnuplot/src/win/wgraph.c	2009-03-24 09:27:40.000000000 -0700
> +++ gnuplot-cvs/src/win/wgraph.c	2009-07-10 14:09:41.000000000 -0700
> @@ -1104,12 +1104,16 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
>  		LOGBRUSH lb;
>  
>  		/* distinguish gray values and RGB colors */
> -		if (curptr->y == 0) {
> +		if (curptr->y == 0) {			/* TC_FRAC */
>  		    rgb255_color rgb255;
>  		    rgb255maxcolors_from_gray(curptr->x / (double)WIN_PAL_COLORS, &rgb255);
>  		    c = RGB(rgb255.r, rgb255.g, rgb255.b);
>  		}
> -		else {
> +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
> +		    short pen = (curptr->x < (WORD)(-2)) ? (curptr->x % WGNUMPENS) + 2 : curptr->x + 2;
> +		    c = lpgw->colorbrush[pen];
> +		}
> +		else {					/* TC_RGB */
>  		    c = RGB(curptr->y & 0xff, (curptr->x >> 8) & 0xff, curptr->x & 0xff);
>  		}
>  
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

I will leave my home today.  So the reply will be delayed but will be done at least within Sunday.

I strongly appreciate for your efforts for this matter.

Regards

Tatsuro 

--- Ethan Merritt wrote:

> On Friday 10 July 2009 14:19:23 Ethan Merritt wrote:
> 
> > Please try this more complete patch instead of the above quick test.
> > [beware:  untested!]
> 
> So sorry.  I attached the wrong patch.
> Please try this one instead.
> 
> 
> -- 
> Ethan A Merritt
> > diff -urp gnuplot/term/win.trm gnuplot-cvs/term/win.trm
> --- gnuplot/term/win.trm	2009-06-08 09:09:47.000000000 -0700
> +++ gnuplot-cvs/term/win.trm	2009-07-10 14:03:46.000000000 -0700
> @@ -595,8 +595,7 @@ WIN_set_color(t_colorspec *colorspec)
>  	    GraphOp(&graphwin, W_pm3d_setcolor, (colorspec->lt) & 0xffff, 0xff00 | ((colorspec->lt >>
> 16) & 0x00ff), NULL);
>  	    break;
>  	case TC_LT:
> -	    /* set color only when second parameter to W_line_type equals 1 */
> -	    GraphOp(&graphwin, W_line_type, colorspec->lt, 1, NULL);
> +	    GraphOp(&graphwin, W_pm3d_setcolor, colorspec->lt, TC_LT << 8, NULL);
>  	    break;
>      }
>      WIN_last_linetype = LT_NODRAW;
> diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> --- gnuplot/src/win/wgraph.c	2009-03-24 09:27:40.000000000 -0700
> +++ gnuplot-cvs/src/win/wgraph.c	2009-07-10 14:09:41.000000000 -0700
> @@ -1104,12 +1104,16 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
>  		LOGBRUSH lb;
>  
>  		/* distinguish gray values and RGB colors */
> -		if (curptr->y == 0) {
> +		if (curptr->y == 0) {			/* TC_FRAC */
>  		    rgb255_color rgb255;
>  		    rgb255maxcolors_from_gray(curptr->x / (double)WIN_PAL_COLORS, &rgb255);
>  		    c = RGB(rgb255.r, rgb255.g, rgb255.b);
>  		}
> -		else {
> +		else if (curptr-> == (TC_LT << 8)) {	/* TC_LT */
> +		    short pen = (curptr->x < (WORD)(-2)) ? (curptr->x % WGNUMPENS) + 2 : curptr->x + 2;
> +		    c = lpgw->colorbrush[pen];
> +		}
> +		else {					/* TC_RGB */
>  		    c = RGB(curptr->y & 0xff, (curptr->x >> 8) & 0xff, curptr->x & 0xff);
>  		}
>  
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Friday 10 July 2009 14:19:23 Ethan Merritt wrote:

> Please try this more complete patch instead of the above quick test.
> [beware:  untested!]

So sorry.  I attached the wrong patch.
Please try this one instead.


-- 
Ethan A Merritt

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Friday 10 July 2009 04:01:36 Tatsuro MATSUOKA wrote:
> Hello
> 
> > The patch for graphic.c is needed for other terms so that win.trm can be modified with 
> > > +#if (0) /* Broken! */
> > >      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> > > +#endif
> > at the moment.
> > 
> HMMMM!
> I withdraw the above. The patch for win.trm gives rectangles always not filled.

That's OK.  At least it confirms the diagnosis of where the problem lies.
Please try this more complete patch instead of the above quick test.
[beware:  untested!]

I believe this corrects a general color selection error in win.trm,
and if we're lucky it may fix both the current problem and part of bug #1952287.


-- 
Ethan A Merritt

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

> The patch for graphic.c is needed for other terms so that win.trm can be modified with 
> > +#if (0) /* Broken! */
> >      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> > +#endif
> at the moment.
> 
HMMMM!
I withdraw the above. The patch for win.trm gives rectangles always not filled.

Regards

Tatsuro  

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> I have attached your patch and tried
> Hello 
> 
> This time 
> gnuplot> set title 'HELLO' tc rgb "blue"
> gnuplot> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> gnuplot> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> gnuplot> plot x
> 
> gives white or transparent two rectanangles.
> For transparent_solids.dem the figure was drawn white or transparent black ground.
> 
> This issue seems to be solved easily.
> 
> However if figure is copied to clipboard and paste it to other applications, the further plots
> go
> well.   
> 
> The patch for graphic.c is needed for other terms so that win.trm can be modified with 
> > +#if (0) /* Broken! */
> >      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> > +#endif
> at the moment.
> 
> Regards
> 
> Tatsuro
>  
> --- Ethan Merritt  wrote:
> 
> > Here is my current theory of what is happening.
> > 
> > The 2009-07-04 patch changed the core code to always call term->fillbox()
> > to draw a rectangle rather than calling term->filled_polygon().  This was
> > to fix a problem that some terminals drew rectangles of the wrong size if
> > called via term->filled_polygon().
> > 
> > The windows terminal driver has for a long time (maybe forever?) been 
> > unable to draw transparent fill or pattern fill correctly.  See for example
> >   Bug 1952287	Windows driver lacks correct color shading or transparency
> > 
> > The windows terminal also has a second bug that WIN_filled_polygon ignores 
> > the fillstyle.  It always draws solid fill in the current color. 
> > 
> > In the case of drawing filled rectangles, the second bug was hiding the 
> > first bug.  When you asked for a filled rectangle, the core called
> > WIN_filled_polygon() which then ignored the fillstyle and always drew
> > solid fill in the current color.  The 2009-07-04 patch changed this so
> > that instead the core code calls WIN_boxfill() which _does_ try to
> > apply the current fillstyle, but this triggers Bug #1952287 and the fill
> > comes out wrong.
> > 
> > So I am guessing that the following patch will return the windows
> > behaviour to the previous state, by causing WIN_boxfill() to ignore
> > the fill style just as WIN_filled_polygon() has always ignored the
> > fill style.
> > 
> > --- gnuplot/term/win.trm        2009-06-07 21:37:29.000000000 -0700
> > +++ gnuplot-cvs/term/win.trm    2009-07-09 23:33:55.000000000 -0700
> > @@ -621,7 +621,9 @@ WIN_boxfill(
> >  {
> >      /* split into two commands to squeeze through all the necessary info */
> >      /* Notice HBB 20010208: --> WIN_move() */
> > +#if (0) /* Broken! */
> >      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> > +#endif
> >      GraphOp(&graphwin, W_move, xleft, ybottom, NULL);
> >      GraphOp(&graphwin, W_boxfill, width, height, NULL);
> >  }
> > 
> > Can you test whether this guess is correct?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

I have attached your patch and tried
Hello 

This time 
gnuplot> set title 'HELLO' tc rgb "blue"
gnuplot> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
gnuplot> set object 2 rect from -6,-6 to -1,-1 fc lt 3
gnuplot> plot x

gives white or transparent two rectanangles.
For transparent_solids.dem the figure was drawn white or transparent black ground.

This issue seems to be solved easily.

However if figure is copied to clipboard and paste it to other applications, the further plots go
well.   

The patch for graphic.c is needed for other terms so that win.trm can be modified with 
> +#if (0) /* Broken! */
>      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> +#endif
at the moment.

Regards

Tatsuro
 
--- Ethan Merritt  wrote:

> Here is my current theory of what is happening.
> 
> The 2009-07-04 patch changed the core code to always call term->fillbox()
> to draw a rectangle rather than calling term->filled_polygon().  This was
> to fix a problem that some terminals drew rectangles of the wrong size if
> called via term->filled_polygon().
> 
> The windows terminal driver has for a long time (maybe forever?) been 
> unable to draw transparent fill or pattern fill correctly.  See for example
>   Bug 1952287	Windows driver lacks correct color shading or transparency
> 
> The windows terminal also has a second bug that WIN_filled_polygon ignores 
> the fillstyle.  It always draws solid fill in the current color. 
> 
> In the case of drawing filled rectangles, the second bug was hiding the 
> first bug.  When you asked for a filled rectangle, the core called
> WIN_filled_polygon() which then ignored the fillstyle and always drew
> solid fill in the current color.  The 2009-07-04 patch changed this so
> that instead the core code calls WIN_boxfill() which _does_ try to
> apply the current fillstyle, but this triggers Bug #1952287 and the fill
> comes out wrong.
> 
> So I am guessing that the following patch will return the windows
> behaviour to the previous state, by causing WIN_boxfill() to ignore
> the fill style just as WIN_filled_polygon() has always ignored the
> fill style.
> 
> --- gnuplot/term/win.trm        2009-06-07 21:37:29.000000000 -0700
> +++ gnuplot-cvs/term/win.trm    2009-07-09 23:33:55.000000000 -0700
> @@ -621,7 +621,9 @@ WIN_boxfill(
>  {
>      /* split into two commands to squeeze through all the necessary info */
>      /* Notice HBB 20010208: --> WIN_move() */
> +#if (0) /* Broken! */
>      GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
> +#endif
>      GraphOp(&graphwin, W_move, xleft, ybottom, NULL);
>      GraphOp(&graphwin, W_boxfill, width, height, NULL);
>  }
> 
> Can you test whether this guess is correct?
> 
> 
> 
> 
> 
> 
> 
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Here is my current theory of what is happening.

The 2009-07-04 patch changed the core code to always call term->fillbox()
to draw a rectangle rather than calling term->filled_polygon().  This was
to fix a problem that some terminals drew rectangles of the wrong size if
called via term->filled_polygon().

The windows terminal driver has for a long time (maybe forever?) been 
unable to draw transparent fill or pattern fill correctly.  See for example
  Bug 1952287	Windows driver lacks correct color shading or transparency

The windows terminal also has a second bug that WIN_filled_polygon ignores 
the fillstyle.  It always draws solid fill in the current color. 

In the case of drawing filled rectangles, the second bug was hiding the 
first bug.  When you asked for a filled rectangle, the core called
WIN_filled_polygon() which then ignored the fillstyle and always drew
solid fill in the current color.  The 2009-07-04 patch changed this so
that instead the core code calls WIN_boxfill() which _does_ try to
apply the current fillstyle, but this triggers Bug #1952287 and the fill
comes out wrong.

So I am guessing that the following patch will return the windows
behaviour to the previous state, by causing WIN_boxfill() to ignore
the fill style just as WIN_filled_polygon() has always ignored the
fill style.

--- gnuplot/term/win.trm        2009-06-07 21:37:29.000000000 -0700
+++ gnuplot-cvs/term/win.trm    2009-07-09 23:33:55.000000000 -0700
@@ -621,7 +621,9 @@ WIN_boxfill(
 {
     /* split into two commands to squeeze through all the necessary info */
     /* Notice HBB 20010208: --> WIN_move() */
+#if (0) /* Broken! */
     GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
+#endif
     GraphOp(&graphwin, W_move, xleft, ybottom, NULL);
     GraphOp(&graphwin, W_boxfill, width, height, NULL);
 }

Can you test whether this guess is correct?

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

I have tested using the previous graphic.c (Revision 1.305 - Fri Jun 26 06:41:34 2009) with cvs trees
dated at 2009-07-09.  

In this case the Petr's test

set title 'HELLO' tc rgb "blue"
set object 1 rect from 0,0 to 5,5 fc rgb "blue"
set object 2 rect from -6,-6 to -1,-1 fc lt 3
plot x
 
=> title and both rectangles are blue.

This shows that chage of graphic.c between Revision 1.305 (1.306) and 1.307 gives strange behaviors
object fill color for windows terminal. 

(Differeces in revsion 1.305 and 1.306 are only those in comments. )

Difference between graphic of revision 1.306 and that of 1.307 is shown as a refrence 

Perhaps code simplification gives strange behavior dor windows term.


$ diff -ur graphics.1.306.c graphics.1.307.c
--- graphics.1.306.c    2009-07-10 13:41:03 +0900
+++ graphics.1.307.c    2009-07-10 13:31:53 +0900
@@ -1,5 +1,5 @@
 #ifndef lint
-static char *RCSid() { return RCSid("$Id: graphics.c,v 1.306 2009/07/05 00:09:32 sfeam Exp $"); }
+static char *RCSid() { return RCSid("$Id: graphics.c,v 1.307 2009/07/05 07:11:50 sfeam Exp $"); }
 #endif

 /* GNUPLOT - graphics.c */
@@ -126,7 +126,6 @@
 static void fill_missing_corners __PROTO((gpiPoint *corners, int *points, int exit, int reentry, int
updown, int leftri
ght));
 static void fill_between __PROTO((double, double, double, double, double, double, double, double,
struct curve_points *
));
 static TBOOLEAN bound_intersect __PROTO((struct coordinate GPHUGE * points, int i, double *ex, double
*ey, filledcurves
_opts *filledcurves_options));
-static gpiPoint *fill_corners __PROTO((int, unsigned int, unsigned int, unsigned int, unsigned int));
 static void plot_vectors __PROTO((struct curve_points * plot));
 static void plot_f_bars __PROTO((struct curve_points * plot));
 static void plot_c_bars __PROTO((struct curve_points * plot));
@@ -3665,11 +3664,7 @@
                    }

                    style = style_from_fill(&plot->fill_properties);
-
-                   if (plot->lp_properties.use_palette && t->filled_polygon) {
-                       (*t->filled_polygon)(4, fill_corners(style,x,y,w,h));
-                   } else
-                       (*t->fillbox) (style, x, y, w, h);
+                   (*t->fillbox) (style, x, y, w, h);

                    if (!need_fill_border(&plot->fill_properties))
                        break;
@@ -4107,11 +4102,7 @@

                if (style == FS_EMPTY)
                    style = FS_OPAQUE;
-
-               if (plot->lp_properties.use_palette && t->filled_polygon)
-                   (*t->filled_polygon)(4, fill_corners(style,x,y,w,h));
-               else
-                   (*t->fillbox)(style, x, y, w, h);
+               (*t->fillbox)(style, x, y, w, h);

                if (style_from_fill(&plot->fill_properties) != FS_EMPTY)
                    need_fill_border(&plot->fill_properties);
@@ -5352,12 +5343,8 @@
        } else
 #endif
        if (w > 0) {    /* All other plot types with fill */
-           if (style != FS_EMPTY) {
-               if (this_plot->lp_properties.use_palette && t->filled_polygon)
-                   (*t->filled_polygon)(4, fill_corners(style,x,y,w,h));
-               else
-                   (*t->fillbox)(style,x,y,w,h);
-           }
+           if (style != FS_EMPTY)
+               (*t->fillbox)(style,x,y,w,h);

            /* need_fill_border will set the border linetype, but candlesticks don't want it */
            if ((this_plot->plot_style == CANDLESTICKS && fs->border_color.type == TC_LT
@@ -5416,29 +5403,6 @@
     clip_area = clip_save;
 }

-
-/*
- * The equivalent of t->fillbox() except that it uses PM3D colors instead
- * of plain line types
- */
-static gpiPoint *
-fill_corners(int style, unsigned int x, unsigned int y, unsigned int w, unsigned int h)
-{
-    static gpiPoint corner[4];
-
-    corner[0].style = style;
-    corner[0].x = x;
-    corner[0].y = y;
-    corner[1].x = x;
-    corner[1].y = y+h;
-    corner[2].x = x+w;
-    corner[2].y = y+h;
-    corner[3].x = x+w;
-    corner[3].y = y;
-
-    return corner;
-}
-
 #ifdef EAM_OBJECTS
 void
 do_rectangle( int dimensions, t_object *this_object, int style )
@@ -5540,12 +5504,8 @@
        term_apply_lp_properties(&lpstyle);
        style = style_from_fill(fillstyle);

-       if (style != FS_EMPTY) {
-           if (lpstyle.use_palette && term->filled_polygon) {
-               (*term->filled_polygon)(4, fill_corners(style,x,y,w,h));
-           } else if (term->fillbox)
+       if (style != FS_EMPTY && term->fillbox)
                (*term->fillbox) (style, x, y, w, h);
-       }

        if (need_fill_border(fillstyle)) {
            (*term->move)   (x, y);


Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

Unfortunately resuts are the same as those my first report. 

Petr's test also gives 

=>title is blue, but both rectangles are black.

Regards

Tatsuro

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

> On Wednesday 08 July 2009 22:18:16 Petr Mikulik wrote:
> > > http://www.geocities.jp/tmgpltwin/Files/Files.html
> > > 0018 090709_1.png, 31,991 bytes, 2009-07-09
> > > 0019 090709_2.png, 32,846 bytes, 2009-07-09
> > > 
> > > The transparent_solids.dem using gnuplot 4.3 ChangeLog 2009-07-04 results in those indicated
> in  the
> > > file '0018 090709_1.png'.  The background col or became black.
> > > 
> > > However, I once copied the graph to clip board by using mouse click in window bar and
> clicked the
> > > graph windows again, perhaps screen refresh occurred.  Then I could see the the graph as
> expected as
> > > shown in the file '0019 090709_2.png'.
> > 
> > The bug can be reproduced by this code:
> > 
> > set title 'HELLO' tc rgb "blue"
> > set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> > set object 2 rect from -6,-6 to -1,-1 fc lt 3
> > plot x
> > 
> > => title is blue, but both rectangles are black.
> 
> I have found and repaired an initialization bug in the default properties
> for rectangles.  This fix is in today's CVS version of gadgets.h
> 
> This fixes a change in behaviour of the svg and canvas terminals (maybe others?)
> triggered by the 2009-07-04 patch.  However, the symptom shown by these terminals
> was that the border of the rectangles was drawn with width 0.  It is not clear
> to me whether the problem shown by the windows terminal is due to the same
> initialization failure, or to something else.  Please test and report.
> 
> 	Ethan
> 
> -- 
> Ethan A Merritt
> 



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Fwd: Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Sorry I have forgotten to send the cc. reply to gnu...@li...

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Date:Fri, 10 Jul 2009 09:20:51 +0900 (JST)
> From:Tatsuro MATSUOKA <tma...@ya...>
> Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
> win term
> To:Hans-Bernhard Br将モker <HBB...@t-...>
> 
> Hellp
> 
> --- Hans-Bernhard Br将モker  wrote:
> 
> > Tatsuro MATSUOKA wrote:
> > 
> > > Perhaps so. Unfortunately the all cvs trees in unviersity computer refreshed.
> > 
> > You shouldn't let that stop you.  CVS is a revision control system, 
> > after all, not just a means to distribute the latest code to others. 
> > You can retrieve (or go back to) any past state of the CVS tree or parts 
> > of it, by specifying the "-D date" option in a cvs checkout or update 
> > command.
> 
> 
>   
> $ cvs -z3 -D 2009-07-02 checkout gnuplot_tmp
> cvs: invalid option -- D
> Usage: cvs [cvs-options] command [command-options-and-arguments]
>   where cvs-options are -q, -n, etc.
>     (specify --help-options for a list of options)
>   where command is add, admin, etc.
>     (specify --help-commands for a list of commands
>      or --help-synonyms for a list of command synonyms)
>   where command-options-and-arguments depend on the specific command
>     (specify -H followed by a command name for command-specific help)
>   Specify --help to receive this message
> 
> The Concurrent Versions System (CVS) is a tool for version control.
> For CVS updates and additional information, see
>     the CVS home page at http://www.nongnu.org/cvs/ or
>     the CVSNT home page at http://www.cvsnt.org/
> 
> Is my use of cvs command bad ?
> 
>  cvs --help-options
> CVS global options (specified before the command name) are:
>     -H           Displays usage information for command.
>     -Q           Cause CVS to be really quiet.
>     -q           Cause CVS to be somewhat quiet.
>     -r           Make checked-out files read-only.
>     -w           Make checked-out files read-write (default).
>     -n           Do not execute anything that will change the disk.
>     -t           Show trace of program execution (repeat for more
>                  verbosity) -- try with -n.
>     -R           Assume repository is read-only, such as CDROM
>     -v           CVS version and copyright.
>     -T tmpdir    Use 'tmpdir' for temporary files.
>     -e editor    Use 'editor' for editing log information.
>     -d CVS_root  Overrides $CVSROOT as the root of the CVS tree.
>     -f           Do not use the ~/.cvsrc file.
>     -z #         Request compression level '#' for net traffic.
>     -a           Authenticate all net traffic.
>     -s VAR=VAL   Set CVS user variable.
> (Specify the --help option for a list of other help options)
> 
> I have tried both
> Concurrent Versions System (CVS) 1.12.13 (client/server) on cygwin
> Concurrent Versions System (CVS) 1.11.22 (client/server) on Msys
> 
> The results are the same.
> 
> Anyway I'll search cvs repository by web repositry by a web browser.
> 
> Thanks!
> 
> Tatsuro
> 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Tatsuro MATSUOKA wrote:

> Perhaps so. Unfortunately the all cvs trees in unviersity computer refreshed.

You shouldn't let that stop you.  CVS is a revision control system, 
after all, not just a means to distribute the latest code to others. 
You can retrieve (or go back to) any past state of the CVS tree or parts 
of it, by specifying the "-D date" option in a cvs checkout or update 
command.

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

On Wednesday 08 July 2009 22:18:16 Petr Mikulik wrote:
> > http://www.geocities.jp/tmgpltwin/Files/Files.html
> > 0018 090709_1.png, 31,991 bytes, 2009-07-09
> > 0019 090709_2.png, 32,846 bytes, 2009-07-09
> > 
> > The transparent_solids.dem using gnuplot 4.3 ChangeLog 2009-07-04 results in those indicated in  the
> > file '0018 090709_1.png'.  The background col or became black.
> > 
> > However, I once copied the graph to clip board by using mouse click in window bar and clicked the
> > graph windows again, perhaps screen refresh occurred.  Then I could see the the graph as expected as
> > shown in the file '0019 090709_2.png'.
> 
> The bug can be reproduced by this code:
> 
> set title 'HELLO' tc rgb "blue"
> set object 1 rect from 0,0 to 5,5 fc rgb "blue"
> set object 2 rect from -6,-6 to -1,-1 fc lt 3
> plot x
> 
> => title is blue, but both rectangles are black.

I have found and repaired an initialization bug in the default properties
for rectangles.  This fix is in today's CVS version of gadgets.h

This fixes a change in behaviour of the svg and canvas terminals (maybe others?)
triggered by the 2009-07-04 patch.  However, the symptom shown by these terminals
was that the border of the rectangles was drawn with width 0.  It is not clear
to me whether the problem shown by the windows terminal is due to the same
initialization failure, or to something else.  Please test and report.

	Ethan

-- 
Ethan A Merritt

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> 
> > I think he means the third change in that day:
> > 
> > 2009-07-04  Ethan A Merritt  <merritt@u.washington.edu>
> > 
> >       * src/graphics.c (plot_boxes plot_c_bars do_rectangle do_key_sample):
> >       Remove the fill_corners() routine and instead call term->fillbox()
> >       directly rather than dummying up a call to term->filled_polygon().
> >       Bug #2804784
> 
> Perhaps so. Unfortunately the all cvs trees in unviersity computer refreshed.
> Perhaps I have kept cvs trees before than 2009-07-04 in the computer in my home.
> After I will return home I will check the demo and the Petr's test and report results here.  
> 
 I have just confirmed that the binaries built by cvs trees at 2009-07-02 show no bug in
transparent_solids.dem and in also in the test by Petr


set title 'HELLO' tc rgb "blue"
set object 1 rect from 0,0 to 5,5 fc rgb "blue"
set object 2 rect from -6,-6 to -1,-1 fc lt 3
plot x

=> title is blue, and  both rectangles are blue.

Therefore this bug probably is imported in the change at 2009-07-04 indicated by Petr: correction  for
src/graphics.c at July 4. 

Regards

Tatsuro 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

eaten character in X11 - Re: et origin

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

Here is a more improved bug report compared to that I've sent to Ben and 
bu...@oc...:


In Octave 3.2.0, I've noticed a missing ("eaten") character when pasting 
several commands by mouse into Octave or when plotting many plots from a 
script file (under Linux and X11 gnuplot terminal). For example, the 
following is reproducible on my computer -- paste the following by middle 
mouse button:

clf
subplot(1,2,1); title("fig 1")
subplot(2,2,2); title("fig 2")
subplot(2,2,4); title("fig 3")

which leads to:

tmp|16:57:30|11> clf
tmp|16:57:30|12> subplot(1,2,1); title("fig 1")
tmp|16:57:31|13> subplot(2,2,2); title("fig 2")
tmp|16:57:31|14> subplot(2,2,4); title("fig 3")

multiplot> et origin 0, 0
           ^
           line 30: invalid command


It happens in this sequence of commands sent to gnuplot:

	fputs (plot_stream, "set multiplot;\n");
	fputs (plot_stream, "set origin 0, 0\n");

in octave/3.2.0/m/plot/__go_draw_figure__.m

The problem vanishes if I add \n into the first command, e.g.
        fputs (plot_stream, "set multiplot;\n\n");
Note that adding ";" or fflush() does not help.

I have tested older gnuplot releases, and it seems that gnuplot earlier than 
the patch below works correctly:

2008-11-06  Ethan Merritt  <merritt@u.washington.edu>
* term/x11.trm (X11_set_font ENHX11_put_text): Initialize enhanced text 
  processing to use most recently requested font rather than the default 
  font.

Ethan, can you please check it?

---
PM

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello


> I think he means the third change in that day:
> 
> 2009-07-04  Ethan A Merritt  <merritt@u.washington.edu>
> 
>       * src/graphics.c (plot_boxes plot_c_bars do_rectangle do_key_sample):
>       Remove the fill_corners() routine and instead call term->fillbox()
>       directly rather than dummying up a call to term->filled_polygon().
>       Bug #2804784

Perhaps so. Unfortunately the all cvs trees in unviersity computer refreshed.
Perhaps I have kept cvs trees before than 2009-07-04 in the computer in my home.
After I will return home I will check the demo and the Petr's test and report results here.  

>From now on I will keep at least one the previous trees to check whether newly imported change will
give another bug or not.

Regards

Tatsuro  

--- Petr Mikulik <mi...@ph...> wrote:
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

Hello


> I think he means the third change in that day:
> 
> 2009-07-04  Ethan A Merritt  <merritt@u.washington.edu>
> 
>       * src/graphics.c (plot_boxes plot_c_bars do_rectangle do_key_sample):
>       Remove the fill_corners() routine and instead call term->fillbox()
>       directly rather than dummying up a call to term->filled_polygon().
>       Bug #2804784

Perhaps so. Unfortunately the all cvs trees in unviersity computer refreshed.
Perhaps I have kept cvs trees before than 2009-07-04 in the computer in my home.
After I will return home I will check the demo and the Petr's test and report results here.  

>From now on I will keep at least one the previous trees to check whether newly imported change will
give another bug or not.

Regards

Tatsuro  

--- Petr Mikulik <mi...@ph...> wrote:
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term

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

> Do you mean this change?
>         2009-07-04  Ethan A Merritt  <merritt@u.washington.edu>
>         * src/term.c: The code was disabling all mousing and mouse events
>         during multiplot.  
> 
> It only affects multiplot. The transparent_solids demo does not use multiplot.
> So I do not understand how this change could affect the demo.
> 
> Perhaps it is a failure to explicitly initialize some variable, and after rebuilding 
> that variable happens to get a different starting value? 

I think he means the third change in that day:

2009-07-04  Ethan A Merritt  <merritt@u.washington.edu>

      * src/graphics.c (plot_boxes plot_c_bars do_rectangle do_key_sample):
      Remove the fill_corners() routine and instead call term->fillbox()
      directly rather than dummying up a call to term->filled_polygon().
      Bug #2804784


---
PM