On 2017-10-01 01:11+0100 Phil Rosenberg wrote:
On 30 September 2017 at 19:35, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
[...] By the way, other command-line options such as
examples/c/x27c -dev wxwidgets -geometry 300x200
do work fine for -dev wxwidgets so the issue with the -eofill option
with -dev wxwidgets is likely not a general command-line option issue
with -dev wxwidgets but something specific about how the -eofill
option is handled for the -dev wxwidgets case.
Does geometry set the size of the canvas?
Yes.
This is specifically transmitted to
the viewer as it is not recorded in the buffer anywhere. But is you
check plbuf_bop you can see the state parameters that are recorded at
the beginning of each page. I have now added the dev_eofill variable
to that list. I have also set the function opt_eofill to call
plP_State so that if a change occurs later in the execution it will
get picked up. Should you feel the need to write a plsfillrule()
function then all the stuff is there so that if you just duplicated
opt_eofill then all the code is there so that the buffer would catch
it.
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 look
Hi 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.
With regard to your remark concerning writing a plsfillrule() function
and systematically using it throughout src/plargs.c, I wouldn't want
to do that myself, but if you or Jim want to make such a change and it
passes comprehensive testing, I certainly would not object.
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
__________________________
------------------------------------------------------------------------------
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
