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/