On 2017-10-01 09:49+0100 Phil Rosenberg wrote:
Note that I have tested this up to the point of checking in the debugger that the correct fill rule is recognised by the viewer and the correct parameter is passed in to the wxWidgets fill function. This definitely works correctly both with and without -eofill specified for example 27. However I didn't spot a difference in the output. Maybe you can check it if you know how it should lookHi Phil: I suspect you didn't go far enough into the pages of the example to encounter the fill results for the more complex figures. If you do that, e.g., page 19 of the example (see <http://www.plplot.org/examples-data/demo27/x27.19.png> which was generated with -dev pngcairo and the -eofill option), the result should have many holes in the fill region relative to the same page generated without the -eofill option. If you don't see that difference on Windows, I feel that is likely due to a wxWidgets library bug on Windows since that difference does show up in the Linux case. Anyhow, thanks very much for this fix, and I have changed the status of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.I get output just like that image without the -eofill parameter. I suspect that as you said this is a bug in wxWidgets on Windows. I'm not exactly sure how the differences are supposed to manifest. If you could send me a relatively simple polygon that should give different output depending upon which rule is used and a description of what should be different then I will generate a test case and submit a bug report.
I think the best test case is a considerably simplified version of C standard example 27 with the lowest-order figure that shows the difference. I therefore as requested have attached source code for such a test case, and associated screenshots for -dev wxwidgets in the two fill-rule cases (snapshot1.png for the default case without -eofill and snapshot2.png for the case with -eofill). If you compare those screenshots with the figure in <https://en.wikipedia.org/wiki/Nonzero-rule> you will see (as expected) that snapshot1.png follows the non-zero fill rule and snapshot2.png follows the even-odd fill rule. These results were produced on a Linux platform, but from what you say on a Windows platform you would always get for this simplified test case the equivalent of the -eofill result. So once you confirm that, it would be pretty good evidence of a wxWidgets library bug in the Windows case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________
x27c.c.gz
Description: Simplified source code to illustrate the bug
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
