matplotlib-devel Mailing List for matplotlib

>
> On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw <str...@as...> wrote:
> 
>> > I had a patch waiting in the wings for that, but I wanted to see the dust
>> > settle before committing it. I think the dust is officially settled, so
>> > please commit yours or else I'll commit mine.
>> >
>> 
>
> Please go ahead.
> 
Will do.
>> By the way, I just encountered some zorder issue with the new patch.
>> The thing is, zorder=1 for Images seems to high.
>> For example, patches also have zorders=1. So, if I draw an image, and
>> add some patches (which I often do to indicate regions of interests),
>> the patches are drawn before images and become invisible. This happens
>> because images are appended to dsu list after all other artists.
>>
>> 
>
> The other thing I noticed by quickly going through axes.py is that
> when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5,
> which is lower than images. While the doc say
>
> *axisbelow* draw the grids and ticks below the other
> artists
>
> I don't think one wants to draw axis (grid+ticks) even below images.
>
> Well, there should be a few ways to fix this, but how others think
> about reducing the Image's zorder to 0?
I'm fine with the default Image's zorder at 0 -- I'm explicitly setting 
it for the cases I'm interested in anyway, and I think that would give 
better consistency with the old way. Also, I think this is better and 
more explicit than just inserting them at the beginning of the dsu list 
and relying on a stable sort to keep them drawn below various patches, 
which is how I interpreted your meaning for that approach.
I'll check in this change, too.
-Andrew

On Thu, Nov 12, 2009 at 3:45 PM, Jae-Joon Lee <lee...@gm...> wrote:
> By the way, I just encountered some zorder issue with the new patch.
> The thing is, zorder=1 for Images seems to high.
> For example, patches also have zorders=1. So, if I draw an image, and
> add some patches (which I often do to indicate regions of interests),
> the patches are drawn before images and become invisible. This happens
> because images are appended to dsu list after all other artists.
>
The other thing I noticed by quickly going through axes.py is that
when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5,
which is lower than images. While the doc say
 *axisbelow* draw the grids and ticks below the other
 artists
I don't think one wants to draw axis (grid+ticks) even below images.
Well, there should be a few ways to fix this, but how others think
about reducing the Image's zorder to 0?
Regards,
-JJ

Jouni K. Seppänen wrote:
> No, that's exactly what I was thinking about - some newly-found font
> might break matplotlib, or might change somebody's output because of the
> font matching algorithm. 
> Actually, the font matching system can
> sometimes break things:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/18255/focus=18260
> 
Sorry that fell by the wayside. On further investigation, there are two 
bugs here:
1) The "stretch" metric is not read from .afm files: it's always set to 
"normal", therefore, when specifying "Helvetica" which exists in a 
number of widths, it has an equal chance of choosing any of them 
depending on dictionary ordering. Note that now {'family': 'Helvetica', 
'stretch': 'narrow'} should and does return "Helvetica-Narrow". Both 
"Helvetica" and "Helvetica-Narrow" are of the same font family, so that 
in itself is not a bug (it's the same mechanism that makes {'family': 
'Helvetica', 'weight': 'bold'} give "Helvetica-Bold").
2) When pdf.use14corefonts is True, it will actually pull an afm font 
file from anywhere, not just from mpl-data/fonts/pdfcorefonts. There's 
actually some logic in the FontManager to collect files from only that 
directory when "pdf.use14corefonts" is True, but that's only triggered 
at cache-build time. That's how bug 1) resulted in adding a font that 
isn't a PDF core font to a PDF file. But it would be just as easy to 
specify some other random "afm" font on the system and break things in 
the same way.
Lastly, to support all this, the cache needs to be thrown away, so I 
added support for versioning of the cache file -- if it doesn't match 
what the currently-installed matplotlib expects, it's thrown away and 
regenerated.
Mike
> Did that ever get fixed?
>
> Jouni
>
> Michael Droettboom <md...@st...> writes:
>
> 
>> Sorry about that bug. Obviously it wasn't tested properly.
>>
>> It seems like the only side effect of this change is that matplotlib 
>> will pull in fonts from non-standard locations defined in their 
>> fontconfig configuration. (It's already pulling them from standard 
>> locations that are hardcoded in font_manager.py). There's a chance that 
>> some of these fonts will cause matplotlib to explode -- but no more so 
>> than if there were in a standard location.
>>
>> I think it seems like a pretty benign change -- unless there's something 
>> in particular you're thinking of that I'm not...
>>
>> Mike
>>
>> Jouni K. Seppänen wrote:
>> 
>>> Because of the problem described here:
>>>
>>> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>>>
>>> I modified font_manager.py to use subprocess.Popen instead of
>>> commands.getstatusoutput, since subprocess seems to deal with EINTR
>>> while the commands module does not. While looking at it, I changed the
>>> command being run from
>>>
>>> fc-list file
>>>
>>> to
>>>
>>> fc-list '' file
>>>
>>> because the former doesn't return any fonts on any system I have access
>>> to (maybe it would if I had a font whose name includes the word "file"),
>>> but the latter looks more like it is the intended command. Since the
>>> get_fontconfig_fonts function has not returned anything useful for some
>>> time (though presumably it has at some point in the past), this change
>>> might have big effects somewhere else.
>>>
>>> Would this change be appropriate for the bugfix branch?
>>>
>>> 
>>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw <str...@as...> wrote:
> I had a patch waiting in the wings for that, but I wanted to see the dust
> settle before committing it. I think the dust is officially settled, so
> please commit yours or else I'll commit mine.
>
Please go ahead.
By the way, I just encountered some zorder issue with the new patch.
The thing is, zorder=1 for Images seems to high.
For example, patches also have zorders=1. So, if I draw an image, and
add some patches (which I often do to indicate regions of interests),
the patches are drawn before images and become invisible. This happens
because images are appended to dsu list after all other artists.
Reducing the zorder of images would be a one option. Or we may add
images to the dsu list before all other artists, which seems sensible
to me.
Regards,
-JJ

No, that's exactly what I was thinking about - some newly-found font
might break matplotlib, or might change somebody's output because of the
font matching algorithm. Actually, the font matching system can
sometimes break things:
http://thread.gmane.org/gmane.comp.python.matplotlib.general/18255/focus=18260
Did that ever get fixed?
Jouni
Michael Droettboom <md...@st...> writes:
> Sorry about that bug. Obviously it wasn't tested properly.
>
> It seems like the only side effect of this change is that matplotlib 
> will pull in fonts from non-standard locations defined in their 
> fontconfig configuration. (It's already pulling them from standard 
> locations that are hardcoded in font_manager.py). There's a chance that 
> some of these fonts will cause matplotlib to explode -- but no more so 
> than if there were in a standard location.
>
> I think it seems like a pretty benign change -- unless there's something 
> in particular you're thinking of that I'm not...
>
> Mike
>
> Jouni K. Seppänen wrote:
>> Because of the problem described here:
>>
>> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>>
>> I modified font_manager.py to use subprocess.Popen instead of
>> commands.getstatusoutput, since subprocess seems to deal with EINTR
>> while the commands module does not. While looking at it, I changed the
>> command being run from
>>
>> fc-list file
>>
>> to
>>
>> fc-list '' file
>>
>> because the former doesn't return any fonts on any system I have access
>> to (maybe it would if I had a font whose name includes the word "file"),
>> but the latter looks more like it is the intended command. Since the
>> get_fontconfig_fonts function has not returned anything useful for some
>> time (though presumably it has at some point in the past), this change
>> might have big effects somewhere else.
>>
>> Would this change be appropriate for the bugfix branch?
>>
>> 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Sorry about that bug. Obviously it wasn't tested properly.
It seems like the only side effect of this change is that matplotlib 
will pull in fonts from non-standard locations defined in their 
fontconfig configuration. (It's already pulling them from standard 
locations that are hardcoded in font_manager.py). There's a chance that 
some of these fonts will cause matplotlib to explode -- but no more so 
than if there were in a standard location.
I think it seems like a pretty benign change -- unless there's something 
in particular you're thinking of that I'm not...
Mike
Jouni K. Seppänen wrote:
> Because of the problem described here:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>
> I modified font_manager.py to use subprocess.Popen instead of
> commands.getstatusoutput, since subprocess seems to deal with EINTR
> while the commands module does not. While looking at it, I changed the
> command being run from
>
> fc-list file
>
> to
>
> fc-list '' file
>
> because the former doesn't return any fonts on any system I have access
> to (maybe it would if I had a font whose name includes the word "file"),
> but the latter looks more like it is the intended command. Since the
> get_fontconfig_fonts function has not returned anything useful for some
> time (though presumably it has at some point in the past), this change
> might have big effects somewhere else.
>
> Would this change be appropriate for the bugfix branch?
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Because of the problem described here:
http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
I modified font_manager.py to use subprocess.Popen instead of
commands.getstatusoutput, since subprocess seems to deal with EINTR
while the commands module does not. While looking at it, I changed the
command being run from
fc-list file
to
fc-list '' file
because the former doesn't return any fonts on any system I have access
to (maybe it would if I had a font whose name includes the word "file"),
but the latter looks more like it is the intended command. Since the
get_fontconfig_fonts function has not returned anything useful for some
time (though presumably it has at some point in the past), this change
might have big effects somewhere else.
Would this change be appropriate for the bugfix branch?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks. This is applied in r7952 and r7954.
Mike
Urs Fleisch wrote:
> A function to get the font properties angle is missing in the EMF backend of matplotlib 0.99.1. This patch has to be applied in addition to patch https://sourceforge.net/tracker/index.php?func=detail&aid=2853659&group_id=80706&atid=560722 (is already applied to svn HEAD r7706) to fix the problem.
>
> You can find the patch at
>
> https://sourceforge.net/tracker/?func=detail&aid=2896459&group_id=80706&atid=560722
>
> 
>> JDH: None of the core mpl developers are
>> win32 users, so we will defer to you as to what is best for this backend.
>> 
>
> No problem, but you can test the EMF backend also without win32, OpenOffice supports EMF pictures.
>
> Regards,
> Urs
>
>
>
> 
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

A function to get the font properties angle is missing in the EMF backend of matplotlib 0.99.1. This patch has to be applied in addition to patch https://sourceforge.net/tracker/index.php?func=detail&aid=2853659&group_id=80706&atid=560722 (is already applied to svn HEAD r7706) to fix the problem.
You can find the patch at
https://sourceforge.net/tracker/?func=detail&aid=2896459&group_id=80706&atid=560722
> JDH: None of the core mpl developers are
> win32 users, so we will defer to you as to what is best for this backend.
No problem, but you can test the EMF backend also without win32, OpenOffice supports EMF pictures.
Regards,
Urs
 

Jae-Joon Lee wrote:
> I also committed a small patch that makes zorders respected among
> images (not with other artists) for noncomposit backends.
> 
That looks fine to me. Thanks.
> Anyhow, can we get rid of the second items in the "dsu" list? My guess
> is that this is to make the sort stable, but python sort is already
> stable, isn't it?
> 
I had a patch waiting in the wings for that, but I wanted to see the 
dust settle before committing it. I think the dust is officially 
settled, so please commit yours or else I'll commit mine.
-Andrew

I also committed a small patch that makes zorders respected among
images (not with other artists) for noncomposit backends.
Anyhow, can we get rid of the second items in the "dsu" list? My guess
is that this is to make the sort stable, but python sort is already
stable, isn't it?
-JJ
On Tue, Nov 10, 2009 at 4:06 PM, Andrew Straw <str...@as...> wrote:
> Andrew Straw wrote:
>> John Hunter wrote:
>>
>>> On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw <str...@as...> wrote:
>>>
>>>
>>>> Hi All,
>>>>
>>>> I have addressed what I think is a long-standing wart: zorder is mostly
>>>> ignored for imshow(). (See e.g.
>>>> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>>>> ) The question is whether I should apply the attached patch.
>>>>
> I went ahead and committed this patch to the trunk in r7950.
>
> Here's the CHANGELOG entry:
>
> 2009年11月10日 Single images, and all images in renderers with
>      option_image_nocomposite (i.e. agg, macosx and the svg
>      backend when rcParams['svg.image_noscale'] is True), are
>      now drawn respecting the zorder relative to other
>      artists. (Note that there may now be inconsistencies across
>      backends when more than one image is drawn at varying
>      zorders, but this change introduces correct behavior for
>      the backends in which it's easy to do so.)
>
> Jae Joon raised a couple of concerns:
>
> 1) the patch would introduces inconsistent behavior between backends --
> namely that PS and other backends, when given more than one image, would
> "composite" (or rasterize) all images and stick them underneath
> everything else. Agg would have proper zordering between images and
> other artists.
>
> 2) there is doubt about the utility of such functionality. Jae-Joon says
> "I think it is often sufficient if we draw images at the bottom but
> respect zorders among images".
>
> As for #1, it seems to me this is simply a bug/limitation with the
> compositing functionality (e.g. the PS backend). The SVG backend has the
> possibility to turn compositing on or off based on the svg.image_noscale
> rcParam, and perhaps other backends could grow something similar. I
> can't see why this patch -- that specifically solves the bug/limitation
> in the backends where its easily possible -- should be held back due to
> this.
>
> As for #2, perhaps my use case will be convincing -- I'm trying to draw
> reconstructions of various experimental setups, and the easiest way to
> do this is to create texture-mapped rectangles in which I can control
> the zorder -- a single texture may need to be over some artists but
> under others. Perhaps there's an easier way to achieve this, but I'm not
> aware of it.
>
> Jae Joon has also stated that he's OK with the patch, so I went ahead
> and committed it. In light of all this, please let me know if you still
> have concerns, and hopefully they can be addressed. In the worst case,
> we can back this patch out.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>