matplotlib-devel Mailing List for matplotlib (Page 3)

I was gone for the weekend (sorry, but that 'life' thing gets in the way of
getting things done sometimes). I don't have a way to build stuff at the
moment. Can I just check out the axes.py and replace my current one, or are
there too many changes?
Mark
On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <ef...@ha...> 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?
>>
>> 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)
>>
>
> Mark,
>
> I made some more changes so that the above works by changing the adjustable
> to 'datalim'. Have I broken anything? Does this work for your
> applications?
>
> Eric
>
>
>> 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
>>
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

Just put the Debian bugreport on the list here. I will look at this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
mm

Neal Becker wrote:
> matplotlib-0.91
> 
> I got a nice semilog plot on the screen. Trying to save it to pdf fails,
> saying 'cannot take log of nonpositive value'.
> 
Ah, seems to be fixed in 0.98.3 (but fedora f9 ships 0.91.2)

matplotlib-0.91
I got a nice semilog plot on the screen. Trying to save it to pdf fails, saying 'cannot take log of nonpositive value'.

There are some screenshot-figures (png output) in the docs that need
minor updates:
- histogram: ylabel is cropped because the yticklabels are too wide
- table demo: the table is croped on the bottom of the image
- scatter demo: x and y labels are unreadable (the _i); ylabel is cropped
- financial charts: xlabels are cropped
- basemap demo: yticks on the right are cropped due to the colorbar;
colorbar ticks are cropped, too
- polar plots: title is cropped
mm

Thanks Eric,
 It works perfectly for me now!
Actually, autoscale of shared axes simplify a lot
my own code so I'm really really pleased to see this functionality
is now directly integrated in matplotlib.
I'll do me best to test the svn version regularly.
Thanks again,
David
Eric Firing a écrit :
> David Trem wrote:
>> Thank you very much Eric !
>>
>> It basically works for me but I think there is still a small bug
>> related to sharing y axes. I attach a small script that reproduce the
>> problem.
>> The end of the related error message is the following:
>>
>> File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
>> __init__
>> if sharex._adjustable == 'box':
>> AttributeError: 'NoneType' object has no attribute '_adjustable'
>>
>> Hope it could help.
> 
> It certainly does, thank you. In a cut'n'paste operation, I had
> neglected to change a couple of 'x's to 'y's. Fixed in svn.
> 
> Thanks again, and keep testing!
> 
> Eric

David Trem wrote:
> Thank you very much Eric !
> 
> It basically works for me but I think there is still a small bug
> related to sharing y axes. I attach a small script that reproduce the
> problem.
> The end of the related error message is the following:
> 
> File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
> __init__
> if sharex._adjustable == 'box':
> AttributeError: 'NoneType' object has no attribute '_adjustable'
> 
> Hope it could help.
It certainly does, thank you. In a cut'n'paste operation, I had 
neglected to change a couple of 'x's to 'y's. Fixed in svn.
Thanks again, and keep testing!
Eric

This is now fixed in SVN r6318. I also added some of the PNG test suite 
images to out regression tests so we're sure that it works with all of 
the basic PNG types.
Mike
Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
> 
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> 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

I'm looking into this. It seems that matplotlib is not making the right 
calls to libpng to convert < 8-bit images for us.
Mike
Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> 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

Thank you very much Eric !
 It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:
 File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
 if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'
Hope it could help.
David
Eric Firing a écrit :
> David Trem wrote:
>> Hi,
>>
>> Eric, I will be happy to test your possible fix too. I have similar
>> problem with autoscaling shared axes like you Mark.
>>
>> David
> 
> I have committed to svn some changes to support autoscaling with shared
> axes, so please test. I have done only very simple and cursory
> checking. You might try reversed axes, log axes, etc.
> 
> I have not yet addressed the aspect ratio part of Mark's original post,
> below, but I think my changes have fixed the first of the two problems,
> in addition to adding autoscaling support, which I don't think we ever
> had before.
> 
> At present, autoscaling does not work with shared axes if an aspect
> ratio is specified.
> 
> Eric
> 
>>
>> Mark Bakker a écrit :
>>> 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 <ef...@ha...
>>> <mailto:ef...@ha...>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> -------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

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?
> 
> 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)
Mark,
I made some more changes so that the above works by changing the 
adjustable to 'datalim'. Have I broken anything? Does this work for 
your applications?
Eric
> 
> 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
> 
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

David Trem wrote:
> Hi,
> 
> Eric, I will be happy to test your possible fix too. I have similar
> problem with autoscaling shared axes like you Mark.
> 
> David
I have committed to svn some changes to support autoscaling with shared 
axes, so please test. I have done only very simple and cursory 
checking. You might try reversed axes, log axes, etc.
I have not yet addressed the aspect ratio part of Mark's original post, 
below, but I think my changes have fixed the first of the two problems, 
in addition to adding autoscaling support, which I don't think we ever 
had before.
At present, autoscaling does not work with shared axes if an aspect 
ratio is specified.
Eric
> 
> Mark Bakker a écrit :
>> 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 <ef...@ha...
>> <mailto:ef...@ha...>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello all,
Earlier today I looked into a problem someone on the users list was
having with imread working on a binary png file of his (attached). The
array returned does not correspond to the picture, as verified by
imshow'ing the imread'd file, which results in a distorted image with
rainbow colouring at parts. After working through how imread would
handle his file, it seems the problem has to be somewhere in
matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
the source tree. Interestingly enough, using the function pil_to_array
from matplotlib.image on the output of Image.open(fname) works
correctly on the file. I plan on poking around in the cpp file more
myself later tonight, but I was wondering if anyone more familiar with
matplotlib's png-handling could see something immediately obvious that
would break imread's capabilities on binary PNGs.
Josh

On Wed, Oct 22, 2008 at 12:03 PM, Adeodato Simó <da...@ne...> wrote:
> In http://matplotlib.sourceforge.net/users/pyplot_tutorial.html it says:
>
> | You may be wondering why the x-axis ranges from 0-3 and the y-axis
> | from 1-4.
>
> The axis in the image ranges from 0 to 2 (X) and from 1 to 3 (Y).
Thanks, fixed in svn 6309 (but not yet pushed out to the site)

Hi,
 Eric, I will be happy to test your possible fix too. I have similar
problem with autoscaling shared axes like you Mark.
David
Mark Bakker a écrit :
> 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 <ef...@ha...
> <mailto:ef...@ha...>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

> 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

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

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
> 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

In http://matplotlib.sourceforge.net/users/pyplot_tutorial.html it says:
 | You may be wondering why the x-axis ranges from 0-3 and the y-axis
 | from 1-4.
The axis in the image ranges from 0 to 2 (X) and from 1 to 3 (Y).
HTH,
-- 
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
 
- Are you sure we're good?
- Always.
 -- Rory and Lorelai

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.
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.

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:md...@st...] 
>> Sent: Wednesday, October 22, 2008 10:11
>> To: Stan West
>> Cc: mat...@li...
>> 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
>>> 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
>> 
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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:md...@st...] 
> Sent: Wednesday, October 22, 2008 10:11
> To: Stan West
> Cc: mat...@li...
> 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
> > 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

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
> 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

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.