Mike,
Is there any reason why the Path.unit_* methods shouldn't include the codes, so that they can all have CLOSEPOLY? Or shouldn't they at least have a kwarg to allow that as an option? In working on patch drawing via bar(), I noticed that the rectangle outline is not closing properly, with the same rounded join as at the other 3 corners. It isn't apparent unless you set a large linewidth.
Or is there a better way to ensure that polygons close correctly?
Eric
I don't think there's a better way. The renderer can't assume CLOSEPOLY at the end, obviously, because it may in fact by a line and not a filled shape.
I think this was left out just as shorthand (not having a codes array makes things a little faster, too), but I think for correctness the unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll go ahead and fix this.
Mike
···
On 08/14/2010 07:22 PM, Eric Firing wrote:
Mike,
Is there any reason why the Path.unit_* methods shouldn't include the codes, so that they can all have CLOSEPOLY? Or shouldn't they at least have a kwarg to allow that as an option? In working on patch drawing via bar(), I noticed that the rectangle outline is not closing properly, with the same rounded join as at the other 3 corners. It isn't apparent unless you set a large linewidth.
Or is there a better way to ensure that polygons close correctly?
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
Michael Droettboom wrote:
Mike,
Is there any reason why the Path.unit_* methods shouldn't include the
codes, so that they can all have CLOSEPOLY? Or shouldn't they at
least have a kwarg to allow that as an option? In working on patch
drawing via bar(), I noticed that the rectangle outline is not closing
properly, with the same rounded join as at the other 3 corners. It
isn't apparent unless you set a large linewidth.
Or is there a better way to ensure that polygons close correctly?
I don't think there's a better way. The renderer can't assume CLOSEPOLY
at the end, obviously, because it may in fact by a line and not a filled
shape.
I think this was left out just as shorthand (not having a codes array
makes things a little faster, too), but I think for correctness the
unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll
go ahead and fix this.
Mike
Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?
(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)
-Andrew
···
On 08/14/2010 07:22 PM, Eric Firing wrote:
Sorry about that. I believe it is fixed now.
Mike
···
On 08/16/2010 05:54 PM, Andrew Straw wrote:
Michael Droettboom wrote:
On 08/14/2010 07:22 PM, Eric Firing wrote:
Mike,
Is there any reason why the Path.unit_* methods shouldn't include the
codes, so that they can all have CLOSEPOLY? Or shouldn't they at
least have a kwarg to allow that as an option? In working on patch
drawing via bar(), I noticed that the rectangle outline is not closing
properly, with the same rounded join as at the other 3 corners. It
isn't apparent unless you set a large linewidth.
Or is there a better way to ensure that polygons close correctly?
I don't think there's a better way. The renderer can't assume CLOSEPOLY
at the end, obviously, because it may in fact by a line and not a filled
shape.
I think this was left out just as shorthand (not having a codes array
makes things a little faster, too), but I think for correctness the
unit_* methods should have explicit codes arrays with CLOSEPOLYs. I'll
go ahead and fix this.
Mike
Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?
(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)
-Andrew
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA