Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2009-07-09 04:44:28
|
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/ |
|
From: Petr M. <mi...@ph...> - 2009-07-09 05:38:00
|
> 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. > 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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-09 05:51:33
|
On Wednesday 08 July 2009, 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. 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(). |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-09 19:44:09
|
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 |
|
From: Tatsuro M. <tma...@ya...> - 2009-07-10 00:28:13
|
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/ |
|
From: Tatsuro M. <tma...@ya...> - 2009-07-10 04:46:22
|
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/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-10 06:38:08
|
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?
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-10 10:44:33
|
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/
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-10 11:01:50
|
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/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-10 21:19:33
Attachments:
wxt_set_color.patch
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-10 21:31:59
Attachments:
win_fillbox_try1.patch
|
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 |
|
From: Tatsuro M. <tma...@ya...> - 2009-07-10 21:42:09
|
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/
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-11 15:26:50
|
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/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-11 15:47:25
|
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/
>
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-11 17:22:05
Attachments:
win_fillbox_try2.patch
|
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.
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-11 20:12:21
|
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/
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-11 21:41:07
|
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/
>
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-11 22:32:29
|
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/
|
|
From: Petr M. <mi...@ph...> - 2009-07-13 07:13:57
|
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 |
|
From: Petr M. <mi...@ph...> - 2009-07-13 09:41:01
|
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 |
|
From: Tatsuro M. <tma...@ya...> - 2009-07-13 10:04:55
|
Hello --- Petr Mikulik <mi...@ph...> wrote: > 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. The above works well for my build with 'win_fillbox_try3.patch' > *** > > 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. Hmmm! I got the same results > 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/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-13 15:48:48
|
On Monday 13 July 2009, Petr Mikulik wrote:
>
> => all rectangles have correct colour.
Aha. Progress!
> 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.
>
> 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.
> 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.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2009-07-13 20:46:07
Attachments:
win_fillbox_try4.patch
|
On Monday 13 July 2009 08:48:34 Ethan Merritt wrote:
>
> 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
|
|
From: Tatsuro M. <tma...@ya...> - 2009-07-14 00:22:59
|
Hello
--- Ethan Merritt wrote:
> On Monday 13 July 2009 08:48:34 Ethan Merritt wrote:
> >
> > 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/
|
|
From: Petr M. <mi...@ph...> - 2009-07-14 03:01:34
|
> > 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
|
