matplotlib-devel Mailing List for matplotlib

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.

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

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

Here's an updated patch:
I decided to go with 'c' and 'v' for Back and Forward since these keys
are in the same place on most localized keyboard layouts (sorry, dvorak
users) (as JDH pointed out, I could not use 'z' and 'x' because 'x' is
used as a modifier in Pan/Zoom mode)
I've added a ReST table detailing all of the key bindings as per JDH's
suggestion.
I included 'g' and 'l' for toggling grid and y scale under the heading
of "In axes only" though there's probably a better way of saying that.
Not sure if those belong there, but they seem to have not been
documented elsewhere ( same with 'f' for fullscreen)
navigation_toolbar.rst compiled and looked fine with rst2html.py and
rst2newlatex.py. The bullets ('- ') created extra vertical whitespace in
the table when I ran latex on the rst2latex.py output. If that's a
problem, those can be replaced with '-- '
looking forward to your feedback,
Paul Ivanov
John Hunter, on 2008年10月17日 04:02, wrote:
> On Thu, Oct 16, 2008 at 9:18 PM, Paul Ivanov <piv...@gm...> wrote:
>> Hi,
>>
>> I'm a big fan of keyboard shortcuts, so I decided to add these guys to
>> lib/matplotlib/backend_bases.py
>>
>> I'm not sure if this is too much, and maybe these should be configurable
>> down the line, but here's my first stab at it, what do you all think?
>>
>> in the same order as they appear in the toolbar:
>> 'h' or 'r' for Home/Reset
>> left arrow or 'z' or backspace for Back
>> right arrow and 'x' for Forward
>> 'p' for pan axes with right, zoom with left mode toggle
>> 'o' for z*o*om to rectangle mode toggle
>> 's' for save
> 
>> 'z' and 'x' I borrowed from the Opera browser, very handy to for
>> righties who can have their left hand on the keyboard while using the mouse.
> 
> Hi Paul,
> 
> I'm amenable to additional keys, but check out
> http://matplotlib.sourceforge.net/users/navigation_toolbar.html which
> details which keys are already in play. Also, with your patch, please
> submit a patch against the navigation toolbar doc
> doc/users/navigation_toolbar.rst . Maybe a ReST table that details all
> of the key bindings?
> 
> Thanks,
> JDH

On Tue, Oct 21, 2008 at 8:57 PM, Paul Ivanov <piv...@gm...> wrote:
> Here's an updated patch:
>
> I decided to go with 'c' and 'v' for Back and Forward since these keys
> are in the same place on most localized keyboard layouts (sorry, dvorak
> users) (as JDH pointed out, I could not use 'z' and 'x' because 'x' is
> used as a modifier in Pan/Zoom mode)
>
> I've added a ReST table detailing all of the key bindings as per JDH's
> suggestion.
Thanks Paul, for the enhancements, and especially for doing the extra
work to document the functionality and test the docs. Applied to svn
6291. If you are inclined, we probably need an rc param or something
like that to determine which keys mpl responds to since, as we have
more of these, we increase the risk that we get in the way of
application developers embedding mpl.
Eg, in matplotlibrc, one could do
 toolbar.keys : x, y, c, v, g, f, p, z, control, left, right # with
docs describing what key does what
So the user could turn off any or all of these. Then in
backend_bases, before we issue an event based on a key stroke, we
could check this default list to make sure the user wants mpl handling
these events.
JDH