matplotlib-devel Mailing List for matplotlib (Page 6)

On Sat, May 9, 2009 at 7:05 PM, Elan Pavlov <el...@mi...> wrote:
> As for committing it to the repository I'd be honored if Jae Joon agrees.
Sure,
-JJ

Hi John and Jae-Joon,
While it hardly solves *all* of the issues I've been having it does work 
for this problem:) Thanks a ton. As for committing it to the repository 
I'd be honored if Jae Joon agrees. Should I clean it up and remove the 
debugging prints?
Elan
----
"If stupidity got us into this mess, why can't it get us out?"
 	- Will Rogers
On Sat, 9 May 2009, John Hunter wrote:
> On Sat, May 9, 2009 at 12:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Here is a slightly modified version of your script which works for me.
>>
>> I don't think this is the bug in mpl. Note that the ax.bbox does
>> change if the canvas size change. In your original script, the
>> copy_from_bbox is called before frame.Show() and this seems to cause a
>> mismatching bbox.
>>
>> My modified example is also not perfect. A new background image needs
>> to be saved whenever ax.bbox changes (e.g. when resizing canvas).
>
> probably best way to do this is to connect to the draw_event, and
> update the background on the draw_event. I've updated the example and
> attached it -- do you mind if I commit it to the mpl examples dir (and
> does this solve all the issues you are having)?
>
> JDH
>

John Hunter wrote:
> On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <fr...@wi...> wrote:
>> Hi all,
>>
>> As some of you probably know I am working on the GSoC project to
>> externalise the Mathtex engine from Matplotlib. Today I have been
>> toying around with the renderer using various backends.
>>
>> One of the interesting things that I discovered was that the Cairo
>> backend was making use of subpixel rendering. (Or 'ClearType' as
>> Microsoft call it.) This is not surprising -- by default Cairo will
>> respect a users fontconfig settings when rendering text. Since I have
>> subpixel rendering enabled all text rendered by Cairo is subpixel
>> rendered.
>>
>> While this is fantastic for on screen text -- being significantly more
>> pleasing to look at that the text produced by the AGG backend -- it is
>> unsuitable for print. Now it is not too difficult to disable this,
>> Cairo has an API call: cairo_font_options_set_antialias to deal with
>> this.
>>
>> While I could write a quick patch to always disable subpixel rendering
>> it would be something off a loss to those who either view their graphs
>> onscreen or export them for the web -- where using subpixel rendering
>> is now surprisingly common.
>>
>> Is it worth looking into adding subpixel rendering as a configuration
>> option?
> 
> The matplotlib.lines.Line2D objects has an antialiased property -- we
> could add the same property to matplotlib.text.Text to turn on/off
> subpixel rendering (which could also be supported as an rc param)
I haven't poked around, so this may be a stupid question, but: for 
cairo, can subpixel rendering simply be left on for screen display and 
automatically turned off when writing to a file via savefig? If this 
can be done, it seems like a better solution than requiring to the user 
to turn the parameter on and off manually, depending on whether show() 
or savefig() is being called.
Eric
> 
> JDH

On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <fr...@wi...> wrote:
> Hi all,
>
> As some of you probably know I am working on the GSoC project to
> externalise the Mathtex engine from Matplotlib. Today I have been
> toying around with the renderer using various backends.
>
> One of the interesting things that I discovered was that the Cairo
> backend was making use of subpixel rendering. (Or 'ClearType' as
> Microsoft call it.) This is not surprising -- by default Cairo will
> respect a users fontconfig settings when rendering text. Since I have
> subpixel rendering enabled all text rendered by Cairo is subpixel
> rendered.
>
> While this is fantastic for on screen text -- being significantly more
> pleasing to look at that the text produced by the AGG backend -- it is
> unsuitable for print. Now it is not too difficult to disable this,
> Cairo has an API call: cairo_font_options_set_antialias to deal with
> this.
>
> While I could write a quick patch to always disable subpixel rendering
> it would be something off a loss to those who either view their graphs
> onscreen or export them for the web -- where using subpixel rendering
> is now surprisingly common.
>
> Is it worth looking into adding subpixel rendering as a configuration
> option?
The matplotlib.lines.Line2D objects has an antialiased property -- we
could add the same property to matplotlib.text.Text to turn on/off
subpixel rendering (which could also be supported as an rc param)
JDH

On Sat, May 9, 2009 at 12:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Here is a slightly modified version of your script which works for me.
>
> I don't think this is the bug in mpl. Note that the ax.bbox does
> change if the canvas size change. In your original script, the
> copy_from_bbox is called before frame.Show() and this seems to cause a
> mismatching bbox.
>
> My modified example is also not perfect. A new background image needs
> to be saved whenever ax.bbox changes (e.g. when resizing canvas).
probably best way to do this is to connect to the draw_event, and
update the background on the draw_event. I've updated the example and
attached it -- do you mind if I commit it to the mpl examples dir (and
does this solve all the issues you are having)?
JDH

Here is a slightly modified version of your script which works for me.
I don't think this is the bug in mpl. Note that the ax.bbox does
change if the canvas size change. In your original script, the
copy_from_bbox is called before frame.Show() and this seems to cause a
mismatching bbox.
My modified example is also not perfect. A new background image needs
to be saved whenever ax.bbox changes (e.g. when resizing canvas).
-JJ
On Fri, May 8, 2009 at 5:02 PM, Elan Pavlov <ep...@gm...> wrote:
> Hi,
> Restore_region does not appear to work when embedding mpl into
> wxpython. Attached is a simple modification of the cookbook animation
> (http://www.scipy.org/Cookbook/Matplotlib/Animations) to illustrate
> this problem. I modified the example so it is updated on mouse
> movements (followed by idle time) so that the problem is more visual.
> There is also a flag to add one second timeouts between commands in
> the update method. When looking at the slowed animation it is clear
> that the background is never restored.
> Michiel Hoon thinks that the problem is due to the fact that
> restore_region is not implemented within the event loop and that the
> proper solution requires discussion:)
>
> Elan
> ---
> Of joys departed, not to return, how painful the remembrance.
> - Robert Blair
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi all,
As some of you probably know I am working on the GSoC project to 
externalise the Mathtex engine from Matplotlib. Today I have been 
toying around with the renderer using various backends.
One of the interesting things that I discovered was that the Cairo 
backend was making use of subpixel rendering. (Or 'ClearType' as 
Microsoft call it.) This is not surprising -- by default Cairo will 
respect a users fontconfig settings when rendering text. Since I have 
subpixel rendering enabled all text rendered by Cairo is subpixel 
rendered.
While this is fantastic for on screen text -- being significantly more 
pleasing to look at that the text produced by the AGG backend -- it is 
unsuitable for print. Now it is not too difficult to disable this, 
Cairo has an API call: cairo_font_options_set_antialias to deal with 
this.
While I could write a quick patch to always disable subpixel rendering 
it would be something off a loss to those who either view their graphs 
onscreen or export them for the web -- where using subpixel rendering 
is now surprisingly common.
Is it worth looking into adding subpixel rendering as a configuration 
option?
Regards, Freddie.

I'm running into the following error with the wx backend
> >>> import wx
> >>> import matplotlib.backends.backend_wxagg
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
> matplotlib/backends/backend_wxagg.py", line 23, in <module>
> import backend_wx # already uses wxversion.ensureMinimal('2.8')
> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
> matplotlib/backends/backend_wx.py", line 120, in <module>
> except wxversion.AlreadyImportedError:
> AttributeError: 'module' object has no attribute 
> 'AlreadyImportedError'
This problem seems to be related to additions made here:
http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
The problem is that my version of wxversion raises 'VersionError' 
instead of 'AlreadyImportedError'.
I'm running wxPython 2.8.4.0 while people in the above thread seem to 
be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?
Thanks,
-Tony

Hi,
Restore_region does not appear to work when embedding mpl into
wxpython. Attached is a simple modification of the cookbook animation
(http://www.scipy.org/Cookbook/Matplotlib/Animations) to illustrate
this problem. I modified the example so it is updated on mouse
movements (followed by idle time) so that the problem is more visual.
There is also a flag to add one second timeouts between commands in
the update method. When looking at the slowed animation it is clear
that the background is never restored.
Michiel Hoon thinks that the problem is due to the fact that
restore_region is not implemented within the event loop and that the
proper solution requires discussion:)
Elan
---
Of joys departed, not to return, how painful the remembrance.
- Robert Blair

Evan Mason wrote:
> Hi, would it be possible to add a keyword to clabel to optionally switch 
> off the angle fix in contour.py lines 384+?
Evan,
Done in r7097. I called the kwarg "rightside_up", defaulting to True.
You have come up with a novel use for clabel. Longer-term, we should be 
able to support streamline plotting more directly by using the contour 
line data to place arrowhead markers at roughly uniform intervals.
Eric
> 
> # Fix angle so text is never upside-down
> if rotation > 90:
> rotation = rotation - 180.0
> if rotation < -90:
> rotation = 180.0 + rotation
> 
> Something like "clabel(CS, upsidedown=True)" with the default as False 
> would do it.
> 
> I am using clabel to put directional arrows on a streamline contour 
> plot, and this rotation causes some of the arrows to point the wrong 
> way. I'm willing to try to do it myself if somebody could tell me which 
> files I would need to edit in addition to contour.py?
> 
> Many thanks,
> 
> Evan
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Neat to see mpl getting into the linux kernel-dev crowd:
http://lwn.net/Articles/329458/
(see the two screenshots). I wasn't thrilled with the charts being
described as 'rudimentary', but what can you do :)
Congrats to the team! World domination is assured...
Cheers,
f

Hi, would it be possible to add a keyword to clabel to optionally switch off
the angle fix in contour.py lines 384+?
# Fix angle so text is never upside-down
 if rotation > 90:
 rotation = rotation - 180.0
 if rotation < -90:
 rotation = 180.0 + rotation
Something like "clabel(CS, upsidedown=True)" with the default as False would
do it.
I am using clabel to put directional arrows on a streamline contour plot,
and this rotation causes some of the arrows to point the wrong way. I'm
willing to try to do it myself if somebody could tell me which files I would
need to edit in addition to contour.py?
Many thanks,
Evan

John Hunter <jd...@gm...> writes:
> I was just trying to build the docs in svn HEAD< and got an exception
> that through me into the debugger. This is something I haven't seen
> before -- does anyone know where the debugger is being turned on
In make.py, sphinx-build is called with -P:
 if os.system('sphinx-build %s -P -b html -d build/doctrees . build/html' % options):
 raise SystemExit("Building HTML failed.")
And that means:
 -P -- run Pdb on exception
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I was just trying to build the docs in svn HEAD< and got an exception
that through me into the debugger. This is something I haven't seen
before -- does anyone know where the debugger is being turned on
And thanks JJ for the excellent legend tutorial!
JDH

The patches are now committed to the trunk (r7089, 7090, 7091).
Regards,
-JJ
On Tue, May 5, 2009 at 5:16 PM, Eric Bruning <eri...@gm...> wrote:
> Thanks for your work on this patch JJ, glad to see it ready to go!
>

Aleksandar Veselinovic wrote:
> Correcting function spelling (poyfit->polyfit) error in depreciation
> warning.
Fixed in 7088. Thank you.
Eric
> 
> 
> Index: trunk/matplotlib/lib/matplotlib/mlab.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/mlab.py (revision 7087)
> +++ trunk/matplotlib/lib/matplotlib/mlab.py (working copy)
> @@ -617,7 +617,7 @@
> :func:`polyval`
> polyval function
> """
> - warnings.warn("use numpy.poyfit", DeprecationWarning)
> + warnings.warn("use numpy.polyfit", DeprecationWarning)
> return np.polyfit(*args, **kwargs)
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Correcting function spelling (poyfit->polyfit) error in depreciation
warning.
Index: trunk/matplotlib/lib/matplotlib/mlab.py
===================================================================
--- trunk/matplotlib/lib/matplotlib/mlab.py   (revision 7087)
+++ trunk/matplotlib/lib/matplotlib/mlab.py   (working copy)
@@ -617,7 +617,7 @@
     :func:`polyval`
      polyval function
   """
-  warnings.warn("use numpy.poyfit", DeprecationWarning)
+  warnings.warn("use numpy.polyfit", DeprecationWarning)
   return np.polyfit(*args, **kwargs)

Hello list,
After having installed matplotlib 0.98.5.2 on a windows XP system using the
installer from the website, it didn't run since msvcp71.dll was missing. I
certainly know where to get it from, so I was able to solve the problem, but
generally, Microsoft changed their policy such that MSVCP71.dll should be
distributed with any software that needs it. So, it should be shipped with
matplotlib.
Per request on the matplotlib website, I both filed a bug at sourceforge
(ID: 2787740) as well as writing to this list.
Greetings
Martin Teichmann

Thanks for your work on this patch JJ, glad to see it ready to go!

On Tue, May 5, 2009 at 2:54 PM, John Hunter <jd...@gm...> wrote:
> On Tue, May 5, 2009 at 2:52 PM, John Hunter <jd...@gm...> wrote:
>> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> I'm attaching the revised patch (I may split the patch for commit).
>>
>> Still encountering troubles ....
>
> Oops, ignore me. Looks like I just reapplied the *old* patch that was
> laying around. Give me a few minutes to test....
OK thanks for the fixes. Looks good from my end.
JDH

On Tue, May 5, 2009 at 2:52 PM, John Hunter <jd...@gm...> wrote:
> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> I'm attaching the revised patch (I may split the patch for commit).
>
> Still encountering troubles ....
Oops, ignore me. Looks like I just reapplied the *old* patch that was
laying around. Give me a few minutes to test....

On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I'm attaching the revised patch (I may split the patch for commit).
Still encountering troubles ....
johnh@flag:misc> python rasterization_demo.py
Traceback (most recent call last):
 File "rasterization_demo.py", line 41, in ?
 ax4.set_rasterization_zorder(-10)
AttributeError: 'AxesSubplot' object has no attribute 'set_rasterization_zorder'

I'm attaching the revised patch (I may split the patch for commit).
Regards,
-JJ
On Tue, May 5, 2009 at 3:22 PM, Eric Bruning <eri...@gm...> wrote:
> To avoid confusion, how about renaming draw_wrapper._rasterized to
> draw_wrapper._supports_rasterization ?
>
> This helps to distinguish from artist._rasterized, which has a
> different purpose.
>
> The lack of consistency in decoration language for different artists
> is my fault. It reflects the different ways the base artist module is
> imported for the subclasses of artist.
>
> Thanks,
> Eric
>

To avoid confusion, how about renaming draw_wrapper._rasterized to
draw_wrapper._supports_rasterization ?
This helps to distinguish from artist._rasterized, which has a
different purpose.
The lack of consistency in decoration language for different artists
is my fault. It reflects the different ways the base artist module is
imported for the subclasses of artist.
Thanks,
Eric

Thanks John,
Sorry for the buggy patch. The error occurs when usetex=False and
ps.useafm=False, which was not my setup.
Here is a patch to fix it.
--- lib/matplotlib/backends/backend_ps.py.orig 2009年05月05日
14:44:31.000000000 -0400
+++ lib/matplotlib/backends/backend_ps.py 2009年05月05日
14:44:36.000000000 -0400
@@ -993,7 +993,7 @@
 Ndict = len(psDefs)
 print >>fh, "%%BeginProlog"
 if not rcParams['ps.useafm']:
- Ndict += len(renderer.used_characters)
+ Ndict += len(ps_renderer.used_characters)
 print >>fh, "/mpldict %d dict def"%Ndict
 print >>fh, "mpldict begin"
 for d in psDefs:
@@ -1001,7 +1001,7 @@
 for l in d.split('\n'):
 print >>fh, l.strip()
 if not rcParams['ps.useafm']:
- for font_filename, chars in renderer.used_characters.values():
+ for font_filename, chars in ps_renderer.used_characters.values():
 if len(chars):
 font = FT2Font(font_filename)
 cmap = font.get_charmap()
> If we take the time upfront to be consistent, any search replace
> things we need to do later will be easier.
>
I'll post a revised patch shortly.
Thanks,
-JJ
> Thanks,
> JDH
>