From: Rafael L. <rla...@us...> - 2005-01-02 19:40:59
|
This is just to confirm that the last change done by Andrew works here in my Debian system with Freefont. When I enter any of the following in plmtex: #(2266), #[8711], or #[0x2207], I get a nice Nabla operator in the plot. Thanks for this great improvement, Andrew! -- Rafael |
From: Andrew R. <aro...@ya...> - 2005-01-03 03:07:27
|
At 08:40 PM 2/01/2005 +0100, you wrote: >This is just to confirm that the last change done by Andrew works here in my >Debian system with Freefont. When I enter any of the following in plmtex: >#(2266), #[8711], or #[0x2207], I get a nice Nabla operator in the plot. Being a humble volcanologist, I had to look up what a Nabla operator was :-P -Andrew |
From: Arjen M. <arj...@wl...> - 2005-01-12 09:08:51
|
Hello all, I have found a bug in the filling algorithm that is exposed by the following program: --- begin --- #include "plcdemos.h" /*--------------------------------------------------------------------------*\ * main * * Try and demonstrate that filling polygons that partly fall outside * the viewport fails. \*--------------------------------------------------------------------------*/ int main(int argc, char *argv[]) { int i; char string[20]; PLFLT x0[10]; PLFLT y0[10]; /* Parse and process command line arguments */ (void) plParseOpts(&argc, argv, PL_PARSE_FULL); /* Initialize plplot */ plinit(); pladv(0); plvsta(); #if 1 plwind(0.0, 100.0, 0.0, 100.0); #else plwind(-500.0, 500.0, -500.0, 500.0); #endif plbox("bc", 1.0, 0, "bcnv", 10.0, 0); plcol0(2); x0[0] = 20 ; y0[0] = -20; x0[1] = 30 ; y0[1] = 30; x0[2] = 110 ; y0[2] = 1120; /* x0[3] = 150 ; y0[3] = 70; */ x0[3] = 250 ; y0[3] = -270; x0[4] = 20 ; y0[4] = -20; plcol0(1); plpsty(1); plfill(5, x0, y0); plcol0(2); pllsty(1); plline(5, x0, y0); /* Don't forget to call plend() to finish off! */ plend(); exit(0); } --- end --- The problem occurs when the polygon is not completey inside the window: the wrong area is filled. Two variations: - change "#if 1" to "#if 0" to change the scaling and see the polygon (almost) in full - change the coordinates for vertex 3 to 150, 70: then the polygon is filled correctly. I have seen this occur on Windows, but I do not think this is driver-specific. Regards, Arjen |
From: Andrew R. <and...@us...> - 2005-01-17 15:06:04
|
Arjen, Are you sure this is not a driver specific issue? I've tried your example with #if 0 and #if 1 but I can't see anything wrong. This is under Linux. I've checked xwin, ps and png drivers. Does the ps driver work for you? Andrew On Wed, Jan 12, 2005 at 10:07:47AM +0100, Arjen Markus wrote: > Hello all, > > I have found a bug in the filling algorithm that is exposed by the > following > program: > > --- begin --- > #include "plcdemos.h" > > /*--------------------------------------------------------------------------*\ > * main > * > * Try and demonstrate that filling polygons that partly fall outside > * the viewport fails. > \*--------------------------------------------------------------------------*/ > > int > main(int argc, char *argv[]) > { > int i; > char string[20]; > PLFLT x0[10]; > PLFLT y0[10]; > > /* Parse and process command line arguments */ > > (void) plParseOpts(&argc, argv, PL_PARSE_FULL); > > /* Initialize plplot */ > > plinit(); > > pladv(0); > plvsta(); > #if 1 > plwind(0.0, 100.0, 0.0, 100.0); > #else > plwind(-500.0, 500.0, -500.0, 500.0); > #endif > plbox("bc", 1.0, 0, "bcnv", 10.0, 0); > plcol0(2); > > x0[0] = 20 ; y0[0] = -20; > x0[1] = 30 ; y0[1] = 30; > x0[2] = 110 ; y0[2] = 1120; > /* x0[3] = 150 ; y0[3] = 70; */ > x0[3] = 250 ; y0[3] = -270; > x0[4] = 20 ; y0[4] = -20; > > plcol0(1); > plpsty(1); > plfill(5, x0, y0); > plcol0(2); > pllsty(1); > plline(5, x0, y0); > > /* Don't forget to call plend() to finish off! */ > > plend(); > exit(0); > } > > --- end --- > > The problem occurs when the polygon is not completey inside the window: > the wrong area is filled. > > Two variations: > - change "#if 1" to "#if 0" to change the scaling and see the polygon > (almost) in full > - change the coordinates for vertex 3 to 150, 70: then the polygon is > filled > correctly. > > I have seen this occur on Windows, but I do not think this is > driver-specific. > > Regards, > > Arjen > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@wl...> - 2005-01-17 15:18:23
|
Andrew Ross wrote: > > Arjen, > > Are you sure this is not a driver specific issue? I've tried your > example with #if 0 and #if 1 but I can't see anything wrong. This is > under Linux. I've checked xwin, ps and png drivers. Does the ps driver > work for you? > Hm, I will have to check again then! I currently have a rather mixed environment, so I may have been too soon about it :(. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-01-19 07:36:10
|
Arjen Markus wrote: > > Andrew Ross wrote: > > > > > Arjen, > > > > Are you sure this is not a driver specific issue? I've tried your > > example with #if 0 and #if 1 but I can't see anything wrong. This is > > under Linux. I've checked xwin, ps and png drivers. Does the ps driver > > work for you? > > > > Hm, I will have to check again then! I currently have a rather > mixed environment, so I may have been too soon about it :(. > I found the bug: it definitely is in the platform-independent code. However, it concerns an integer overflow in the circulation() function in plline(). It could be that this results in a wrong fill on Windows (the polygon is detected to be counter-clockwise, whereas it is clockwise) and not on Linux. Anyway, I have changed the algorithm and now it works fine. I will commit it later today. Regards, Arjen |