Re: [matplotlib-devel] Patch to fix EMF backend 0.99.1
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 > Matplotlib-devel@lists.sourceforge.net > 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] get_fontconfig_fonts
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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] get_fontconfig_fonts
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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] get_fontconfig_fonts
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 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] get_fontconfig_fonts
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 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Thu, Nov 12, 2009 at 3:45 PM, Jae-Joon Lee 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
> > On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mysterious test_axes/fill_units failure; buildbot images back online
Hi All, I just spent an hour or two tracking down some problems with the buildbot test images that crept in unnoticed with the pdf backend testing. I think I now fixed all the issues with the buildbot testing, which required a few changes to the MPL source and a few on the buildbot server to build the image overview pages correctly. Anyhow, the image failure overview page is back to displaying useful information at http://mpl.code.astraw.com/overview.html All this was prompted by a buildbot failure that occurred starting at r7958 or r7959, although these changes seem unlikely to be the cause of the issue. So, I'm a little mystified as to the actual cause, but it again looks like some freetype problem. Mike, do you think it could somehow be related to your recent font work? -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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
