Re: [matplotlib-devel] problems with shared axis
Mark Bakker wrote: > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the axis > has an aspect ratio that is set 'equal'. It has been discussed on the > list before (mostly with Erik Firing), but it hasn't been fixed yet. > What I want to do is have two plots. The top plot has an aspect ratio > that is 'equal'. The idea is to have a contour plot in the top figure, > while the bottom figure gives a cross-sectional picture of what I am > plotting. This used to work well (quite some time ago), including > zooming and such. But now I cannot plot it at all, let alone zoom. > > My first problem is when I add a subplot with a shared x-axis, it > changes the limits on the original x-axis. That seems to be a bug: > ax1 = subplot(211) > plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. > subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. > > After all, the new subplot shares the axis with the existing subplot, so > why doesn't it copy the axis limits from that subplot? I may have the fix for this, but I need more time to check and refine it--and try to make sure that I don't break anything else in the process. > > But the bigger problem occurs when I want the aspect ratio of one of the > first axis to be 'equal'. > > ax1 = subplot(211,aspect='equal') > plot([1,2,3]) > subplot(212,sharex=ax1) > > The second subplot is added, but the length of the graph is not the same > as for the first subplot. It also resets the xlimits to go from 0 to 1, > as before, which means the first subplot becomes unreadable (it still > enforces 'equal' in the first subplot by changing the limits of the > y-axis). When I now change the limits on the x-axis, the aspect ratio is > not equal anymore > I will see what I can do. There are definitely some bugs that need to be squashed. Eric > ax1.set_xlim(0,2) > draw() > > Thanks for your help. I am willing to help in testing any changes. > > Best regards, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
Thanks Eric. You know that this has been on my wish list for a long time. Let me know if I can test anything or help in any other way, Mark On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > Mark Bakker wrote: > >> Hello list (especially Erik, who can fix this I hope) - >> >> I have had problems with shared axes, especially when one of the axis has >> an aspect ratio that is set 'equal'. It has been discussed on the list >> before (mostly with Erik Firing), but it hasn't been fixed yet. What I want >> to do is have two plots. The top plot has an aspect ratio that is 'equal'. >> The idea is to have a contour plot in the top figure, while the bottom >> figure gives a cross-sectional picture of what I am plotting. This used to >> work well (quite some time ago), including zooming and such. But now I >> cannot plot it at all, let alone zoom. >> >> My first problem is when I add a subplot with a shared x-axis, it changes >> the limits on the original x-axis. That seems to be a bug: >> ax1 = subplot(211) >> plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. >> subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. >> >> After all, the new subplot shares the axis with the existing subplot, so >> why doesn't it copy the axis limits from that subplot? >> > > I may have the fix for this, but I need more time to check and refine > it--and try to make sure that I don't break anything else in the process. > > >> But the bigger problem occurs when I want the aspect ratio of one of the >> first axis to be 'equal'. >> >> ax1 = subplot(211,aspect='equal') >> plot([1,2,3]) subplot(212,sharex=ax1) >> >> The second subplot is added, but the length of the graph is not the same >> as for the first subplot. It also resets the xlimits to go from 0 to 1, as >> before, which means the first subplot becomes unreadable (it still enforces >> 'equal' in the first subplot by changing the limits of the y-axis). When I >> now change the limits on the x-axis, the aspect ratio is not equal anymore >> >> > I will see what I can do. There are definitely some bugs that need to be > squashed. > > Eric > > > ax1.set_xlim(0,2) >> draw() >> >> Thanks for your help. I am willing to help in testing any changes. >> >> Best regards, Mark >> > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] findfont not matching close weights
Greetings. It seems that a "not" operator got dropped in rev. 6143 to
font_manager.py. I've attached a patch.
The missing "not" tripped up findfont when trying to match font weights: the
code
fm = matplotlib.font_manager.FontManager()
fm.findfont('New Century Schoolbook', fontext='afm')
was yielding '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead of
the expected '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', because
fm.afmdict['New Century Schoolbook']['normal']['normal'] had only the
weights 500 and 700, not the 400 called for by the implicit normal weight in
the findfont call.
findfont.patch
Description: Binary data
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] findfont not matching close weights
This is a longstanding known issue -- the font finding algorithm is way
too precise, and should instead do a nearest-neighbor search similar to
fontconfig. It's a non-trivial bit of code that no one has yet found
time for.
If you're running matplotlib 0.98.x and are on a non-Windows platform,
you can try the experimental fontconfig support by changing the
"USE_FONTCONFIG" variable to "True" in font_manager.py. (You'll need to
install fontconfig on OS-X -- most recent Linux distributions should
already have it.)
Cheers,
Mike
Stan West wrote:
> Greetings. It seems that a "not" operator got dropped in rev. 6143 to
> font_manager.py. I've attached a patch.
>
> The missing "not" tripped up findfont when trying to match font weights: the
> code
>
> fm = matplotlib.font_manager.FontManager()
> fm.findfont('New Century Schoolbook', fontext='afm')
>
> was yielding '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead of
> the expected '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', because
> fm.afmdict['New Century Schoolbook']['normal']['normal'] had only the
> weights 500 and 700, not the 400 called for by the implicit normal weight in
> the findfont call.
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ___
> 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
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] findfont not matching close weights
Thank you, Mike, for your reply. My understanding of the intent of the code
is that if the weight is not found in the font dict, setWeights is called to
supplement the dict with the missing weights, and the weight is sought again
in the supplemented dict. That would seem to effect the desired approximate
matching, albeit by precisely matching to an enlarged font dict. However,
Rev. 6143 replaced
if not font.has_key(weight):
setWeights(font)
with
if weight in font:
setWeights(font)
dropping the "not" and thereby supplementing the dict when the sought weight
is already present. Restoring the "not" would restore the approximate
matching, no?
Thanks also for the fontconfig suggestion; I would be happy to try it,
except that my platform is Windows.
Stan
> -Original Message-
> From: Michael Droettboom [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 22, 2008 10:11
> To: Stan West
> Cc: matplotlib-devel@lists.sourceforge.net
> Subject: Re: [matplotlib-devel] findfont not matching close weights
>
> This is a longstanding known issue -- the font finding
> algorithm is way too precise, and should instead do a
> nearest-neighbor search similar to fontconfig. It's a
> non-trivial bit of code that no one has yet found time for.
>
> If you're running matplotlib 0.98.x and are on a non-Windows
> platform, you can try the experimental fontconfig support by
> changing the "USE_FONTCONFIG" variable to "True" in
> font_manager.py. (You'll need to install fontconfig on OS-X
> -- most recent Linux distributions should already have it.)
>
> Cheers,
> Mike
>
> Stan West wrote:
> > Greetings. It seems that a "not" operator got dropped in
> rev. 6143 to
> > font_manager.py. I've attached a patch.
> >
> > The missing "not" tripped up findfont when trying to match font
> > weights: the code
> >
> > fm = matplotlib.font_manager.FontManager()
> > fm.findfont('New Century Schoolbook', fontext='afm')
> >
> > was yielding
> '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead
> > of the expected
> '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm',
> > because fm.afmdict['New Century
> Schoolbook']['normal']['normal'] had
> > only the weights 500 and 700, not the 400 called for by the
> implicit
> > normal weight in the findfont call.
> >
> >
> --
> > --
> >
> >
> --
> > --- This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> > challenge Build the coolest Linux based applications with
> Moblin SDK &
> > win great prizes Grand prize is a trip for two to an Open
> Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >
> --
> > --
> >
> > ___
> > 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
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] findfont not matching close weights
Stan West wrote:
> Thank you, Mike, for your reply. My understanding of the intent of the code
> is that if the weight is not found in the font dict, setWeights is called to
> supplement the dict with the missing weights, and the weight is sought again
> in the supplemented dict. That would seem to effect the desired approximate
> matching, albeit by precisely matching to an enlarged font dict. However,
> Rev. 6143 replaced
>
> if not font.has_key(weight):
> setWeights(font)
>
> with
>
> if weight in font:
> setWeights(font)
>
> dropping the "not" and thereby supplementing the dict when the sought weight
> is already present. Restoring the "not" would restore the approximate
> matching, no?
>
You're right That looks like a typo. This is now fixed in SVN r6294.
> Thanks also for the fontconfig suggestion; I would be happy to try it,
> except that my platform is Windows.
>
That's, unfortunately, why we can't just switch to using it. fontconfig
solves this problem in a much more robust way, and more importantly is
maintained by others who know the pitfalls of fonts really well. It is
ported to Windows, but it is generally not there, so we would have to
require or ship it.
Cheers,
Mike
> Stan
>
>
>> -Original Message-
>> From: Michael Droettboom [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, October 22, 2008 10:11
>> To: Stan West
>> Cc: matplotlib-devel@lists.sourceforge.net
>> Subject: Re: [matplotlib-devel] findfont not matching close weights
>>
>> This is a longstanding known issue -- the font finding
>> algorithm is way too precise, and should instead do a
>> nearest-neighbor search similar to fontconfig. It's a
>> non-trivial bit of code that no one has yet found time for.
>>
>> If you're running matplotlib 0.98.x and are on a non-Windows
>> platform, you can try the experimental fontconfig support by
>> changing the "USE_FONTCONFIG" variable to "True" in
>> font_manager.py. (You'll need to install fontconfig on OS-X
>> -- most recent Linux distributions should already have it.)
>>
>> Cheers,
>> Mike
>>
>> Stan West wrote:
>>
>>> Greetings. It seems that a "not" operator got dropped in
>>>
>> rev. 6143 to
>>
>>> font_manager.py. I've attached a patch.
>>>
>>> The missing "not" tripped up findfont when trying to match font
>>> weights: the code
>>>
>>> fm = matplotlib.font_manager.FontManager()
>>> fm.findfont('New Century Schoolbook', fontext='afm')
>>>
>>> was yielding
>>>
>> '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead
>>
>>> of the expected
>>>
>> '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm',
>>
>>> because fm.afmdict['New Century
>>>
>> Schoolbook']['normal']['normal'] had
>>
>>> only the weights 500 and 700, not the 400 called for by the
>>>
>> implicit
>>
>>> normal weight in the findfont call.
>>>
>>>
>>>
>> --
>>
>>> --
>>>
>>>
>>>
>> --
>>
>>> --- This SF.Net email is sponsored by the Moblin Your Move
>>>
>> Developer's
>>
>>> challenge Build the coolest Linux based applications with
>>>
>> Moblin SDK &
>>
>>> win great prizes Grand prize is a trip for two to an Open
>>>
>> Source event
>>
>>> anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>
>> --
>>
>>> --
>>>
>>> ___
>>> 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
>>
>
>
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text
Stan West wrote: > While labeling axes with both standard and Unicode strings, I noticed some > alignment problems in EPS output, as in the attached examples. I traced it > to differences between RendererPS.draw_text and RendererPS.draw_unicode; the > latter was not accounting for any descenders in the glyphs. I've attached a > suggested patch which I believe brings the draw_unicode behavior into line > with the draw_text behavior for both AFM and TrueType fonts. The patch also > removes extraneous indents in multi-line PostScript strings that were > appearing in the EPS files. > Thanks for the patch. I'm sure that was just overlooked when Unicode support was added to the Ps backend. This has been committed to SVN r6295. > I also noticed a related issue in backend_pdf: For both standard and Unicode > strings, the descender correction is computed, but the text is shifted > vertically in the canvas coordinate system rather than in the glyph > coordinate system. Therefore, y axis labels are bumped up rather than left > on the canvas. I'm not able to work on a patch at this time. I'll have a look at this. Thanks for pointing it out. Cheers, Mike > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ___ > 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text
Michael Droettboom wrote: > Stan West wrote: > >> While labeling axes with both standard and Unicode strings, I noticed some >> alignment problems in EPS output, as in the attached examples. I traced it >> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the >> latter was not accounting for any descenders in the glyphs. I've attached a >> suggested patch which I believe brings the draw_unicode behavior into line >> with the draw_text behavior for both AFM and TrueType fonts. The patch also >> removes extraneous indents in multi-line PostScript strings that were >> appearing in the EPS files. >> >> > Thanks for the patch. I'm sure that was just overlooked when Unicode > support was added to the Ps backend. > > This has been committed to SVN r6295. > >> I also noticed a related issue in backend_pdf: For both standard and Unicode >> strings, the descender correction is computed, but the text is shifted >> vertically in the canvas coordinate system rather than in the glyph >> coordinate system. Therefore, y axis labels are bumped up rather than left >> on the canvas. I'm not able to work on a patch at this time. >> > I'll have a look at this. Thanks for pointing it out. > > Fixed in SVN r6296. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text
> Stan West wrote: > > While labeling axes with both standard and Unicode strings, I noticed some > > alignment problems in EPS output, as in the attached examples. I traced it > > to differences between RendererPS.draw_text and RendererPS.draw_unicode; the > > latter was not accounting for any descenders in the glyphs. I've attached a > > suggested patch which I believe brings the draw_unicode behavior into line > > with the draw_text behavior for both AFM and TrueType fonts. The patch also > > removes extraneous indents in multi-line PostScript strings that were > > appearing in the EPS files. > > > Thanks for the patch. I'm sure that was just overlooked when Unicode > support was added to the Ps backend. > > This has been committed to SVN r6295. You're welcome. For my edification, are there stylistic or other reasons to leave the spaces in the PostScript at lines 580, 636, and 704? > > I also noticed a related issue in backend_pdf: For both standard and Unicode > > strings, the descender correction is computed, but the text is shifted > > vertically in the canvas coordinate system rather than in the glyph > > coordinate system. Therefore, y axis labels are bumped up rather than left > > on the canvas. I'm not able to work on a patch at this time. > I'll have a look at this. Thanks for pointing it out. > > Cheers, > Mike - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text
Stan West wrote: >> Stan West wrote: >> >>> While labeling axes with both standard and Unicode strings, I noticed some >>> alignment problems in EPS output, as in the attached examples. I traced it >>> to differences between RendererPS.draw_text and RendererPS.draw_unicode; the >>> latter was not accounting for any descenders in the glyphs. I've attached a >>> suggested patch which I believe brings the draw_unicode behavior into line >>> with the draw_text behavior for both AFM and TrueType fonts. The patch also >>> removes extraneous indents in multi-line PostScript strings that were >>> appearing in the EPS files. >>> >>> >> Thanks for the patch. I'm sure that was just overlooked when Unicode >> support was added to the Ps backend. >> >> This has been committed to SVN r6295. >> > > You're welcome. For my edification, are there stylistic or other reasons to > leave the spaces in the PostScript at lines 580, 636, and 704? > No. Just used to ignoring whitespace in diffs, since editors often do that kind of thing behind one's back. Certainly saves a few bytes in output to remove them. I'll do that. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
