matplotlib-users Mailing List for matplotlib

Hi. I found a bug in the macos backend.
I get this error when I turn on log plotting on the Y axes; it doesn't 
happen when I turn off log plotting. It also doesn't happen when I use 
agg.pdf driver.
Is this a well-known problem, or should I put together a little demo 
that demonstrates it?
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/figure.py", line 772, in draw
 for a in self.axes: a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axes.py", line 1601, in draw
 a.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axis.py", line 710, in draw
 tick.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/axis.py", line 193, in draw
 self.label1.draw(renderer)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/text.py", line 502, in draw
 ismath=ismath)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/backends/backend_macosx.py", line 
120, in draw_text
 self._draw_mathtext(gc, x, y, s, prop, angle)
 File "/Librrks/Python.framework/Versions/2.6/lib/python2.6/site- 
packages/matplotlib/backends/backend_macosx.py", line 112, in 
_draw_mathtext
 gc.draw_mathtext(x, y, angle, 255 - image.as_array())
TypeError: image has incorrect type (should be uint8)

Eric Firing wrote:
> Michael Droettboom wrote:
>> This is a very good test to have -- we should add it to 
>> backend_driver.py.
>>
>> FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
>> property to control when to bevel vs. miter when the mode is set to 
>> "miter". (Though the default threshold appears to be different.) I 
>> didn't look into Ps, but it may have a similar configuration.
>>
>> Agg also has a miter limit (which is not currently settable from 
>> Python), but it reverts to what it calls "smart" beveling, rather 
>> than regular beveling when below that limit. It does, however, have 
>> another miter mode called "miter_join_revert" which doesn't do smart 
>> beveling. (Try the "conv_stroke" example in the Agg source). In 
>> fact, it has this comment associated with it (agg_math_stroke.h:275):
>>
>> // For the compatibility with SVG, PDF, etc,
>> // we use a simple bevel join instead of
>> // "smart" bevel
>>
>> I think there is an argument to be made that we should use this mode 
>> instead in the Agg backend, to be consistent with PDF and SVG (see 
>> patch below).
>>
>> On a higher level, however, I am a bit concerned about this miter 
>> limit concept. It seems a bit dangerous for scientific plots: there 
>> is a large change in the look of the corner after only a small change 
>> in angle around the miter limit threshold. It may make the data 
>> appear to have large changes where in fact the changes are small. 
>> This seems like an argument of "bevel" or "round" as the default line 
>> join (it is currently "miter"). I also like the idea of "round" join 
>> keeping the corner close to the actual data point.
>>
>> Now, if the user wants miter joins, they can, but I would suggest 
>> that we set the miter-limit threshold in all backends high enough 
>> such that it "always miters" and "never bevels". I can't see why 
>> (for other than artistic purposes), one would want to sometimes miter 
>> or bevel depending on angle in a scientific plot. We can expose 
>> miter limit as a parameter somehow, but for a default, I think it 
>> should be "always miter". What do you think?
>
> Everything you said above sounds right to me, for plotting data--round 
> joins are likely to provide a good combination of aesthetics and 
> faithfulness to the data. Miters are needed for things like arrows 
> (e.g. in quiver), and pcolor patches.
>
Good "point" (pun intended). If we change the default from miter, we 
will need to ensure that arrows etc. are explicitly asking for miter joins.
Cheers,
Mike

Michael Droettboom wrote:
> This is a very good test to have -- we should add it to backend_driver.py.
> 
> FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
> property to control when to bevel vs. miter when the mode is set to 
> "miter". (Though the default threshold appears to be different.) I 
> didn't look into Ps, but it may have a similar configuration.
> 
> Agg also has a miter limit (which is not currently settable from 
> Python), but it reverts to what it calls "smart" beveling, rather than 
> regular beveling when below that limit. It does, however, have another 
> miter mode called "miter_join_revert" which doesn't do smart beveling. 
> (Try the "conv_stroke" example in the Agg source). In fact, it has this 
> comment associated with it (agg_math_stroke.h:275):
> 
> // For the compatibility with SVG, PDF, etc,
> // we use a simple bevel join instead of
> // "smart" bevel
> 
> I think there is an argument to be made that we should use this mode 
> instead in the Agg backend, to be consistent with PDF and SVG (see patch 
> below).
> 
> On a higher level, however, I am a bit concerned about this miter limit 
> concept. It seems a bit dangerous for scientific plots: there is a 
> large change in the look of the corner after only a small change in 
> angle around the miter limit threshold. It may make the data appear to 
> have large changes where in fact the changes are small. This seems like 
> an argument of "bevel" or "round" as the default line join (it is 
> currently "miter"). I also like the idea of "round" join keeping the 
> corner close to the actual data point.
> 
> Now, if the user wants miter joins, they can, but I would suggest that 
> we set the miter-limit threshold in all backends high enough such that 
> it "always miters" and "never bevels". I can't see why (for other than 
> artistic purposes), one would want to sometimes miter or bevel depending 
> on angle in a scientific plot. We can expose miter limit as a parameter 
> somehow, but for a default, I think it should be "always miter". What 
> do you think?
Mike,
Everything you said above sounds right to me, for plotting data--round 
joins are likely to provide a good combination of aesthetics and 
faithfulness to the data. Miters are needed for things like arrows 
(e.g. in quiver), and pcolor patches.
Eric
> 
> Cheers,
> Mike
> 
> Index: _backend_agg.cpp
> ===================================================================
> --- _backend_agg.cpp (revision 6731)
> +++ _backend_agg.cpp (working copy)
> @@ -209,7 +209,7 @@
> std::string joinstyle = Py::String( gc.getAttr("_joinstyle") );
> 
> if (joinstyle=="miter")
> - join = agg::miter_join;
> + join = agg::miter_join_revert;
> else if (joinstyle=="round")
> join = agg::round_join;
> else if(joinstyle=="bevel")
> 
> Jouni K. Seppänen wrote:
>> Michael Droettboom <md...@st...>
>> writes:
>>
>> 
>>> Passing solid_joinstyle='bevel' does resolve the problem on both 0.91.x 
>>> and 0.98.x. Additionally, path simplification (which is a new feature 
>>> on 0.98.x) also resolves this problem (set rcParam path.simplify to True).
>>> 
>> It seems that agg and pdf have different ways to render small angles
>> when the join style is 'miter'. Pdf has a limit (settable in the pdf
>> file) beyond which it reverts to bevel-style angles, agg seems to always
>> do the miter join but cuts it off at some distance.
>>
>> Here's a test script, and screenshots of (a part of) the agg and pdf
>> outputs when the join style is 'miter'.
>>
>> 
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

This is a very good test to have -- we should add it to backend_driver.py.
FWIW, SVG appears to behave similarly to PDF, and has a "miter-limit" 
property to control when to bevel vs. miter when the mode is set to 
"miter". (Though the default threshold appears to be different.) I 
didn't look into Ps, but it may have a similar configuration.
Agg also has a miter limit (which is not currently settable from 
Python), but it reverts to what it calls "smart" beveling, rather than 
regular beveling when below that limit. It does, however, have another 
miter mode called "miter_join_revert" which doesn't do smart beveling. 
(Try the "conv_stroke" example in the Agg source). In fact, it has this 
comment associated with it (agg_math_stroke.h:275):
 // For the compatibility with SVG, PDF, etc,
 // we use a simple bevel join instead of
 // "smart" bevel
I think there is an argument to be made that we should use this mode 
instead in the Agg backend, to be consistent with PDF and SVG (see patch 
below).
On a higher level, however, I am a bit concerned about this miter limit 
concept. It seems a bit dangerous for scientific plots: there is a 
large change in the look of the corner after only a small change in 
angle around the miter limit threshold. It may make the data appear to 
have large changes where in fact the changes are small. This seems like 
an argument of "bevel" or "round" as the default line join (it is 
currently "miter"). I also like the idea of "round" join keeping the 
corner close to the actual data point.
Now, if the user wants miter joins, they can, but I would suggest that 
we set the miter-limit threshold in all backends high enough such that 
it "always miters" and "never bevels". I can't see why (for other than 
artistic purposes), one would want to sometimes miter or bevel depending 
on angle in a scientific plot. We can expose miter limit as a parameter 
somehow, but for a default, I think it should be "always miter". What 
do you think?
Cheers,
Mike
Index: _backend_agg.cpp
===================================================================
--- _backend_agg.cpp (revision 6731)
+++ _backend_agg.cpp (working copy)
@@ -209,7 +209,7 @@
 std::string joinstyle = Py::String( gc.getAttr("_joinstyle") );
 
 if (joinstyle=="miter")
- join = agg::miter_join;
+ join = agg::miter_join_revert;
 else if (joinstyle=="round")
 join = agg::round_join;
 else if(joinstyle=="bevel")
Jouni K. Seppänen wrote:
> Michael Droettboom <md...@st...>
> writes:
>
> 
>> Passing solid_joinstyle='bevel' does resolve the problem on both 0.91.x 
>> and 0.98.x. Additionally, path simplification (which is a new feature 
>> on 0.98.x) also resolves this problem (set rcParam path.simplify to True).
>> 
>
> It seems that agg and pdf have different ways to render small angles
> when the join style is 'miter'. Pdf has a limit (settable in the pdf
> file) beyond which it reverts to bevel-style angles, agg seems to always
> do the miter join but cuts it off at some distance.
>
> Here's a test script, and screenshots of (a part of) the agg and pdf
> outputs when the join style is 'miter'.
>
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users