Discussion:
initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on win term
Tatsuro MATSUOKA
2009-07-09 04:17:40 UTC
Permalink
Hello

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'.

This bug is perhaps will be imported by the change in 2009-07-04.

I also tried it cygwin (1.5 and 1.7) x11, such behaviour did not occur.

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
Petr Mikulik
2009-07-09 05:18:16 UTC
Permalink
Post by Tatsuro MATSUOKA
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.
Post by Tatsuro MATSUOKA
This bug is perhaps will be imported by the change in 2009-07-04.
A binary from last year does not show this bug.

---
PM
Ethan Merritt
2009-07-09 05:51:20 UTC
Permalink
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
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'.
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.
Ah. That example makes the problem more obvious.
It must be due to the change in do_rectangle() to call term->fillbox() rather
than term->filled_polygon().
Ethan Merritt
2009-07-09 19:10:43 UTC
Permalink
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
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'.
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
Ethan Merritt
2009-07-09 05:31:16 UTC
Permalink
Post by Tatsuro MATSUOKA
Hello
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'.
This bug is perhaps will be imported by the change in 2009-07-04.
Do you mean this change?
2009-07-04 Ethan A 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?
Petr Mikulik
2009-07-09 07:09:28 UTC
Permalink
Post by Ethan Merritt
Do you mean this change?
* 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 <***@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
Tatsuro MATSUOKA
2009-07-09 08:23:03 UTC
Permalink
Hello
Post by Petr Mikulik
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.
Tatsuro MATSUOKA
2009-07-09 08:23:10 UTC
Permalink
Hello
Post by Petr Mikulik
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.
Hans-Bernhard Bröker
2009-07-09 20:19:40 UTC
Permalink
Post by Tatsuro MATSUOKA
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.
Tatsuro MATSUOKA
2009-07-09 14:54:59 UTC
Permalink
Hello
Post by Tatsuro MATSUOKA
Hello
Post by Petr Mikulik
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/
Tatsuro MATSUOKA
2009-07-10 00:23:15 UTC
Permalink
Date:Fri, 10 Jul 2009 09:20:51 +0900 (JST)
Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
win term
Hellp
Post by Hans-Bernhard Bröker
Post by Tatsuro MATSUOKA
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
-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/
Tatsuro MATSUOKA
2009-07-10 00:28:06 UTC
Permalink
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
Post by Tatsuro MATSUOKA
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
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
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
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
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
graph windows again, perhaps screen refresh occurred. Then I could see the the graph as
expected as
Post by Petr Mikulik
Post by Tatsuro MATSUOKA
shown in the file '0019 090709_2.png'.
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/
Tatsuro MATSUOKA
2009-07-10 04:46:09 UTC
Permalink
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/
Ethan Merritt
2009-07-10 06:37:55 UTC
Permalink
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?
Tatsuro MATSUOKA
2009-07-10 10:44:19 UTC
Permalink
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
Post by Ethan Merritt
+#if (0) /* Broken! */
GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
+#endif
at the moment.

Regards

Tatsuro
Post by Ethan Merritt
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/
Tatsuro MATSUOKA
2009-07-10 11:01:36 UTC
Permalink
Hello
Post by Tatsuro MATSUOKA
The patch for graphic.c is needed for other terms so that win.trm can be modified with
Post by Ethan Merritt
+#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
Post by Tatsuro MATSUOKA
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
Post by Ethan Merritt
+#if (0) /* Broken! */
GraphOp(&graphwin, W_fillstyle, style, 0, NULL);
+#endif
at the moment.
Regards
Tatsuro
Post by Ethan Merritt
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
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
Ethan Merritt
2009-07-10 21:19:23 UTC
Permalink
Post by Tatsuro MATSUOKA
Hello
Post by Tatsuro MATSUOKA
The patch for graphic.c is needed for other terms so that win.trm can be modified with
Post by Ethan Merritt
+#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
Ethan Merritt
2009-07-10 21:31:40 UTC
Permalink
Post by Ethan Merritt
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
Tatsuro MATSUOKA
2009-07-10 21:42:00 UTC
Permalink
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
Post by Ethan Merritt
Post by Ethan Merritt
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
Post by Ethan 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;
- /* 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/
Tatsuro MATSUOKA
2009-07-11 15:26:42 UTC
Permalink
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
Post by Ethan Merritt
+ else if (curptr-> == (TC_LT << 8)) { /* TC_LT */
else if (curptr->
is to be
else if (curptr->x
?


The other is questionable
Post by Ethan Merritt
+ 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
Post by Ethan Merritt
Post by Ethan Merritt
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
Post by Ethan 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;
- /* 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/
Ethan Merritt
2009-07-11 15:47:16 UTC
Permalink
Post by Tatsuro MATSUOKA
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
Post by Ethan Merritt
+ else if (curptr-> == (TC_LT << 8)) { /* TC_LT */
else if (curptr->
is to be
else if (curptr->x
?
Yes, it should be curptr->x
Post by Tatsuro MATSUOKA
The other is questionable
Post by Ethan Merritt
+ 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.
Post by Tatsuro MATSUOKA
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
Post by Ethan Merritt
Post by Ethan Merritt
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
Post by Ethan 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;
- /* 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/
Ethan Merritt
2009-07-11 17:21:54 UTC
Permalink
Post by Ethan Merritt
Post by Tatsuro MATSUOKA
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
Post by Ethan Merritt
+ 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.
Tatsuro MATSUOKA
2009-07-11 20:12:11 UTC
Permalink
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
Post by Ethan Merritt
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.
Post by Ethan Merritt
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;
- /* 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;
+ /* Leave the current color in place */
+ break;
- /* 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/
Ethan Merritt
2009-07-11 20:47:32 UTC
Permalink
Post by Tatsuro MATSUOKA
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.
Post by Tatsuro MATSUOKA
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.
Post by Tatsuro MATSUOKA
--- 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
Post by Tatsuro MATSUOKA
Regards
Tatsuro
Post by Ethan Merritt
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.
Post by Ethan Merritt
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;
- /* 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;
+ /* Leave the current color in place */
+ break;
- /* 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/
Tatsuro MATSUOKA
2009-07-11 22:32:19 UTC
Permalink
Hello
***********
Ugh. I am about ready to give up on this one.
Post by Petr Mikulik
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.
Post by Petr Mikulik
--- 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);
}
&#171; [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/
Petr Mikulik
2009-07-13 07:13:47 UTC
Permalink
I have also tested Ethan's patch win_fillbox_try2.patch
with

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 there are still two black boxes instead of blue boxes.

I think we should make a Bug report on SF site for a future windows
developer.

---
PM
Petr Mikulik
2009-07-13 09:40:48 UTC
Permalink
I've missed Ethan's patch win_fillbox_try3.patch ... I've tried it now,
and it works!

I.e., this is correct:

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"

=> all rectangles have correct colour.

***

On the other hand, there is a bug in Windows terminal that color selection
with "lt <n>" does not work -- it produces either black or red colours.

I think this bug is associated:
plot x, -x, sin(x), cos(x)
=> and now resize the window by mouse => the colour of legend (key) labels
"x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during
window resizing.

The same happens for the colour of title
set title "HELLO"
Further,
set title "HELLO" tc lt 3
is red (for whichever number of lt).

Ethan, can you deduce something from these cases?

---
PM
Ethan Merritt
2009-07-13 15:48:34 UTC
Permalink
Post by Petr Mikulik
=> all rectangles have correct colour.
Aha. Progress!
Post by Petr Mikulik
On the other hand, there is a bug in Windows terminal that color selection
with "lt <n>" does not work -- it produces either black or red colours.
I get brown here, rather than black or red,
using Matsuoka-san's executable.
Post by Petr Mikulik
plot x, -x, sin(x), cos(x)
=> and now resize the window by mouse => the colour of legend (key) labels
"x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during
window resizing.
Ethan, can you deduce something from these cases?
Yes, but it make be a couple of days before I have time to work on it.

It turns out that the fill color is in some circumstances taken from the
text color rather than the line color (strange, but that's what the Windows
documentation says). The -try3 patch forces the text color to the same
as the line color during a fill. That made the RGB color fill start working,
but it must be that the text color needs to be reset somewhere else before
the next text operation.

The other problem ("lc lt N" not working) is less easy to understand.
Perhaps I have made a stupid typo somewhere.
Ethan Merritt
2009-07-13 20:45:53 UTC
Permalink
Post by Ethan Merritt
The other problem ("lc lt N" not working) is less easy to understand.
Perhaps I have made a stupid typo somewhere.
I think I have found the error.
Here is try #4. I hope that "lc lt N" will now work.

One thing I am not sure about, however, is the effect of linewidth.
I copied a block of code from the W_line_type case that is marked
"work-around for Windows clipboard bug" and treats (line_width == 1)
as a special case. It is possible that the color setting will work
only if the line_width is, or is not, equal to 1. Please check both.
--
Ethan A Merritt
Petr Mikulik
2009-07-14 03:01:22 UTC
Permalink
Post by Ethan Merritt
Post by Ethan Merritt
The other problem ("lc lt N" not working) is less easy to understand.
Perhaps I have made a stupid typo somewhere.
I think I have found the error.
Here is try #4. I hope that "lc lt N" will now work.
One thing I am not sure about, however, is the effect of linewidth.
I confirm all works OK! Wonderful!

Petr

Tatsuro MATSUOKA
2009-07-13 01:17:37 UTC
Permalink
Date:Mon, 13 Jul 2009 10:16:30 +0900 (JST)
Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
win term
Hello
Another try. This one touches a different part of the code,
and contains some debugging statements.
Could you send me a copy of the windows executable containing the patch?
Or put it on a web site for download?
I'd like to do further debugging by experimenting with different settings,
fill styles, and color assignments.
thanks,
Ethan
Thank you very much for your mail
I have built with your patch and tested
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 rectangle 1 is blue with blue boader and rectangle 2 is blue with black
boader
(red is color of the line of plot x)
I have also the executables on
http://www.geocities.jp/tmgpltwin/Files/Files.html
0020 Gnuplot4.3.zip, 3,946,720 bytes, 2009-07-17
I have built binaries with DEBUG is true (complied with -g).
Regards
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/
Tatsuro MATSUOKA
2009-07-13 01:42:07 UTC
Permalink
Date:Mon, 13 Jul 2009 10:16:30 +0900 (JST)
Subject:Re: initailization issue? transparent_solids.dem on gnuplot 4.3 ChangeLog 2009-07-04 on
win term
Hello
Another try. This one touches a different part of the code,
and contains some debugging statements.
Could you send me a copy of the windows executable containing the patch?
Or put it on a web site for download?
I'd like to do further debugging by experimenting with different settings,
fill styles, and color assignments.
thanks,
Ethan
Thank you very much for your mail
I have built with your patch and tested
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 rectangle 1 is blue with blue boader and rectangle 2 is blue with black
boader
(red is color of the line of plot x)
I have also the executables on
http://www.geocities.jp/tmgpltwin/Files/Files.html
0020 Gnuplot4.3.zip, 3,946,720 bytes, 2009-07-17
I have built binaries with DEBUG is true (complied with -g).
Regards
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/
Tatsuro MATSUOKA
2009-07-13 10:04:48 UTC
Permalink
Hello
Post by Petr Mikulik
I've missed Ethan's patch win_fillbox_try3.patch ... I've tried it now,
and it works!
set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
=> all rectangles have correct colour.
The above works well for my build with 'win_fillbox_try3.patch'
Post by Petr Mikulik
***
On the other hand, there is a bug in Windows terminal that color selection
with "lt <n>" does not work -- it produces either black or red colours.
plot x, -x, sin(x), cos(x)
=> and now resize the window by mouse => the colour of legend (key) labels
"x", "-x", "sin(x)", "cos(x)" changes after each mouse movement during
window resizing.
Hmmm! I got the same results
Post by Petr Mikulik
The same happens for the colour of title
set title "HELLO"
Further,
set title "HELLO" tc lt 3
is red (for whichever number of lt).
After plot x, -x, sin(x), cos(x) test,
set title "HELLO"
set title "HELLO" tc lt 3
is red (for whichever number of lt).

However, I exit gnuplot and reexecute gnuplot.
set title "HELLO"
set title "HELLO" tc lt 3
is black (for whichever number of lt).

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
Tatsuro MATSUOKA
2009-07-14 00:22:50 UTC
Permalink
Hello
Post by Ethan Merritt
Post by Ethan Merritt
The other problem ("lc lt N" not working) is less easy to understand.
Perhaps I have made a stupid typo somewhere.
I think I have found the error.
Here is try #4. I hope that "lc lt N" will now work.
One thing I am not sure about, however, is the effect of linewidth.
I copied a block of code from the W_line_type case that is marked
"work-around for Windows clipboard bug" and treats (line_width == 1)
as a special case. It is possible that the color setting will work
only if the line_width is, or is not, equal to 1. Please check both.
I have applied your new patch and tested.

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
plot x lw 1

set title "HELLO" tc rgb "blue"
set xlabel "xxxxx"
set ylabel "yyyyy"
set style rectangle fs solid 1.0 noborder
set object 1 rect from 0,0 to 7,7 fc rgb "blue"
set object 2 rect from -6,-6 to -2,-2 fc rgb "magenta"
set object 3 rect from -9,-9 to -4,+2 fc rgb "yellow"
plot x lw 2

Both worked correctly!!!.

The second point by Petr
set title "HELLO"Further,
set title "HELLO" tc lt 3
also worked fine!!!.

Of cource, 'transparent_solids.dem' worked correctly!!!

I strongly appreciated for your all efforts about this matter.

Regards

Tatsuro

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