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?