Re: [matplotlib-devel] errors building docs
On Mon, Dec 15, 2008 at 17:02, Darren Dale wrote: > (John suggested in a private email to try upgrading to sphinx-0.5.) > > You're right, the error does not occur with sphinx-0.5. It looks like the > API for registering nodes has changed as of 0.5. The development branch of > sphinx was throwing errors when it got to latex, so I had a look and came up > with some changes that work with both version 0.5 and the development > branch. The changes are not compatible with sphinx-0.4.2, but it looks like > we are requiring version 0.5 or later now anyway. If this is the case, I'll > go ahead and commit the changes. Here is the diff, please let me know if I > should commit or if I should hold off: So, should the doc be build using sphinx 0.5? Would it be the standard version of sphinx used by mpl now on? Just to know what dependency to throw in once building mpl for Debian :) -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5 - Doc building question on matplotlibrc
On Tue, Dec 16, 2008 at 4:20 AM, Sandro Tosi wrote:
> -shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
> +shutil.copy('../lib/matplotlib/mpl-data/matplotlibrc',
> '_static/matplotlibrc')
>
This has already been committed to the 98.5 branch.
JDH
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Tue, Dec 16, 2008 at 8:42 AM, John Hunter wrote: >> Yep, 0.5 it is > > Let me correct that -- I will test Darren's patch and if we can make > it work with an earlier sphinx I'm happy to try. Stay tuned. Darren, > can I assume you have tested this with 0.4.2 and the docs are building > for you with your patch. I will test on my tree. OK, after hearing the correction from Darren, the answer is that the docs depend on sphinx 0.5 or later Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Automated test harness discussion...
Continued from: requesting permission to remove traits and configobj... Gael, There might be ways to handle these problems. A lot of depends on what we're trying to test. I agree that if we take the example scripts, run them, and save the plots, we'll never get an automated test harness to figure things out because of machine differences. However, if we set the goal of the testing to be that we make sure that MPL runs, that it accepts the correct options, and produces a plot, then we can be more creative with the testing harness. We can do significant amounts of testing with a fixed back end (Agg probably) that generates an image for comparison. We've tried a number of things in our own testing work which could help. The first step is to identify why plots on different machines are different: numeric differences in input data, agg output, font differences, colors, etc, etc. Some ideas that might (or might not) help: - Use wide lines that are grey in color for everything. The plot looks crazy but then if you get one pixel shifts, it isn't a case of the pixels going "white, black, white" on one machine and "white, white, black" on another - you end up with most of the line overlapping which makes image comparisons easier. - Never generate the input data on the machine you're on. For example, never do this: t = arange(0.0,3.01,0.01) s = sin(2*pi*t) Because you can get differences between machines. A better way is to run this on the machine that will generate the "correct" image and then save the numbers using pickle or by embedding them in the script. - Embed a font with the tests to eliminate font server differences (no experience with this so I'm not sure how hard this would be). We could even create a dummy font that just has black squares for each character - it still tests that everything is drawn in the correct place and runs properly and eliminates subtle character differences. - Create a testing backend that records the drawing commands as a set of meta-data like (draw red line from point 1 to point 2). The test case then checks that the proper commands were issued by the test script. This eliminates drawing completely. A nice comparison suite would allow loose comparisons like "make sure a vertical line was drawn from (10,20) to (30,40) with a pixel slop of 2 pixels. - Smarter image comparison algorithms. We currently use something that processes the image with PIL and looks at an averaged pixel difference (it's not perfect by any means). I'll try to talk to some of the people here who work in image processing to see if there are any fuzzy image comparison algorithms they can recommend. Ted > -Original Message- > From: Gael Varoquaux [mailto:[email protected]] > Sent: Thursday, December 11, 2008 10:06 PM > To: Andrew Straw > Cc: Drain, Theodore R; [email protected] > Subject: Re: [matplotlib-devel] requesting permission to remove traits > and configobj > > On Thu, Dec 11, 2008 at 01:37:01PM -0800, Andrew Straw wrote: > > Prabhu Ramachandran has also done similar things for mayavi2 using > VTK's > > image comparison (see compare_image_with_saved_image in > > > https://svn.enthought.com/enthought/browser/Mayavi/trunk/integrationtes > ts/mayavi/common.py > > ). > > Yeah, and it always fails due to the hardware rendering being slightly > different on different computers :). I think we are giving up on this > approach. > > Gaël > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.9.17/1844 - Release Date: > 12/11/2008 8:58 PM -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Tue, Dec 16, 2008 at 6:12 AM, Sandro Tosi wrote: > So, should the doc be build using sphinx 0.5? Would it be the standard > version of sphinx used by mpl now on? Just to know what dependency to > throw in once building mpl for Debian :) Yep, 0.5 it is. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Mon, Dec 15, 2008 at 10:02 AM, Darren Dale wrote: > You're right, the error does not occur with sphinx-0.5. It looks like the > API for registering nodes has changed as of 0.5. The development branch of > sphinx was throwing errors when it got to latex, so I had a look and came up > with some changes that work with both version 0.5 and the development > branch. The changes are not compatible with sphinx-0.4.2, but it looks like > we are requiring version 0.5 or later now anyway. If this is the case, I'll > go ahead and commit the changes. Here is the diff, please let me know if I > should commit or if I should hold off: I am getting errors trying to apply this patch on the 0.98.5 branch. Could you send a fresh diff against the HEAD of that branch, and attach it rather than paste it. Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
One question to ask is whether we need both the .pdf and .html manuals,
or whether that could be broken up into two packages. That seems like
an easy one if that fits Debian policies (which I know nothing about) --
and wouldn't degrade the documentation experience at all.
Is there any way to transparently gzip compress the html files (as I
believe Debian does with manpages)?
Another option would be to not generate the high-res png and pdf
examples. (Either or both). Just removing them after the fact won't
work, since one would end up with broken links from the docs. We would
also have to change the html to not include those links. It should be
fairly simple to provide an option to the doc build system to do this,
and I'm happy to implement that if we all agree that's the direction to
take.
Beyond that, we'd be looking at selectively including certain examples,
which I worry would add additional maintenance burden if there's too
much divergence between the "full" and "small" manuals. I think that
road should be a last resort.
Mike
Sandro Tosi wrote:
> Hello,
> the problem is this:
>
> $ ls -l python-matplotlib-doc_0.98.5-1_all.deb
> -rw-r--r-- 1 morph morph 91141234 2008-12-16 10:39
> python-matplotlib-doc_0.98.5-1_all.deb
>
> 90M of doc package is a "little bit"... and expanded it's
>
> $ du . -hs
> 119M
>
> In this package we install: doc/build/html/
> doc/build/latex/Matplotlib.pdf examples/*
>
> So I dig into a bit to identify the cause of such a big jump (0.98.3
> has a 16M doc package) and the biggest dir seems to be
> html/_static/plot_directive/mpl_examples/pylab_examples with >50M (a
> full result of "find examples/ html/ -type d -exec du -s {} \;" is
> attached; if you need I can add a full file list). In that particular
> dir (like in many other) i see a png, and hi-res png and a pdf file:
> are those all needed?
>
> At the end, is there a way we packagers can reduce this package size?
> (a fast stat showed it would be the second biggest -doc package in
> Debian.)
>
> Thanks,
>
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>
>
> ___
> Matplotlib-devel mailing list
> [email protected]
> 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
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 0.98.5 - API_CHANGES removed from tarball
Hello, I see API_CHANGES is removed from tarball. it's a nice-to-have file, in order to allow a smooth transition from old to new version. Is it intentional? Is there another source from this information? is it not useful anymore? Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
Hello,
the problem is this:
$ ls -l python-matplotlib-doc_0.98.5-1_all.deb
-rw-r--r-- 1 morph morph 91141234 2008-12-16 10:39
python-matplotlib-doc_0.98.5-1_all.deb
90M of doc package is a "little bit"... and expanded it's
$ du . -hs
119M
In this package we install: doc/build/html/
doc/build/latex/Matplotlib.pdf examples/*
So I dig into a bit to identify the cause of such a big jump (0.98.3
has a 16M doc package) and the biggest dir seems to be
html/_static/plot_directive/mpl_examples/pylab_examples with >50M (a
full result of "find examples/ html/ -type d -exec du -s {} \;" is
attached; if you need I can add a full file list). In that particular
dir (like in many other) i see a png, and hi-res png and a pdf file:
are those all needed?
At the end, is there a way we packagers can reduce this package size?
(a fast stat showed it would be the second biggest -doc package in
Debian.)
Thanks,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
3616examples/
76 examples/animation
144 examples/api
2124examples/data
60 examples/event_handling
36 examples/misc
796 examples/pylab_examples
120 examples/tests
108 examples/tests/pngsuite
64 examples/units
140 examples/user_interfaces
48 examples/widgets
108924 html/
2868html/api
1744html/_sources
124 html/_sources/api
40 html/_sources/devel
1424html/_sources/examples
76 html/_sources/examples/animation
144 html/_sources/examples/api
60 html/_sources/examples/event_handling
40 html/_sources/examples/misc
8 html/_sources/examples/pngsuite
808 html/_sources/examples/pylab_examples
20 html/_sources/examples/tests
72 html/_sources/examples/units
140 html/_sources/examples/user_interfaces
48 html/_sources/examples/widgets
40 html/_sources/faq
4 html/_sources/glossary
108 html/_sources/users
328 html/devel
4480html/examples
244 html/examples/animation
420 html/examples/api
204 html/examples/event_handling
132 html/examples/misc
16 html/examples/pngsuite
2512html/examples/pylab_examples
64 html/examples/tests
228 html/examples/units
476 html/examples/user_interfaces
136 html/examples/widgets
168 html/faq
12 html/glossary
612 html/users
67008 html/_static
1344html/_static/examples
72 html/_static/examples/animation
140 html/_static/examples/api
56 html/_static/examples/event_handling
36 html/_static/examples/misc
4 html/_static/examples/pngsuite
792 html/_static/examples/pylab_examples
12 html/_static/examples/tests
64 html/_static/examples/units
120 html/_static/examples/user_interfaces
44 html/_static/examples/widgets
62064 html/_static/plot_directive
57892 html/_static/plot_directive/mpl_examples
53344 html/_static/plot_directive/mpl_examples/pylab_examples
2584html/_static/plot_directive/mpl_examples/pylab_examples/thumbnails
4132html/_static/plot_directive/mpl_examples/api
244 html/_static/plot_directive/mpl_examples/api/thumbnails
300 html/_static/plot_directive/mpl_examples/units
20 html/_static/plot_directive/mpl_examples/units/thumbnails
116 html/_static/plot_directive/mpl_examples/widgets
8 html/_static/plot_directive/mpl_examples/widgets/thumbnails
4172html/_static/plot_directive/pyplots
208 html/_static/plot_directive/pyplots/thumbnails
1976html/_static/mathmpl
27628 html/_images
3372html/pyplots
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom wrote: > Another option would be to not generate the high-res png and pdf > examples. (Either or both). Just removing them after the fact won't > work, since one would end up with broken links from the docs. We would > also have to change the html to not include those links. It should be > fairly simple to provide an option to the doc build system to do this, > and I'm happy to implement that if we all agree that's the direction to > take. This is fine with me. Just add an rc option doc.minimal_footprint or something like that which drops the high res and pdf. This will prbably reduce the size 50-60% I have also removed the mpl_data symlink in my doc tree, and am still testing before I commit, because that is causing our binaries to get much larger on platforms which do not properly support linking. Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the docs. I am leaving the mpl_examples symlink because of all the relative path woes in pyplot. Other than simple optimizations like this, I am discinclined to try and build smaller manuals simply to reduce their size. The feature that caused the explosion in size between 98.3 and 98.5 is the gallery, and image enhanced examples, which is arguably the most useful feature on the site. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5 - API_CHANGES removed from tarball
On Tue, Dec 16, 2008 at 12:03 PM, Sandro Tosi wrote: > Hello, > I see API_CHANGES is removed from tarball. it's a nice-to-have file, > in order to allow a smooth transition from old to new version. > > Is it intentional? Is there another source from this information? is > it not useful anymore? doc/api/api_changes.rst JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5 - Doc building question on matplotlibrc
Hello John and Darren,
On Sun, Dec 14, 2008 at 22:05, John Hunter wrote:
> On Sun, Dec 14, 2008 at 7:46 PM, Sandro Tosi wrote:
>
>> Well, what I'm actually asking is: can I use any matplotlibrc file (be
>> it from any location in the tarball or forged during build process) or
>> the one in doc/mpl_data has something specific to documentation that
>> needs to be preserved.
>
> In svn, doc/mpl_data is just a symlink to lib/matplotlib/mpl-data
>
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/doc/mpl_data?view=markup
>
> Apparently symlinks are lost in building an sdist, and doc/mpl_data
> becomes a copy. So in the actual src, the rc files are not just
> identical in the two locations, they are the same file. It makes the
> most sense for the users to see in the docs the default rc file they
> are getting with your actual install.
Ah, now it's clear! I added a patch to just:
-shutil.copy('mpl_data/matplotlibrc', '_static/matplotlibrc')
+shutil.copy('../lib/matplotlib/mpl-data/matplotlibrc',
'_static/matplotlibrc')
And now the doc is built (but another problem, worth another thread, comes out).
Thanks & Cheers,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Tue, Dec 16, 2008 at 8:40 AM, John Hunter wrote: > On Tue, Dec 16, 2008 at 6:12 AM, Sandro Tosi wrote: > >> So, should the doc be build using sphinx 0.5? Would it be the standard >> version of sphinx used by mpl now on? Just to know what dependency to >> throw in once building mpl for Debian :) > > Yep, 0.5 it is Let me correct that -- I will test Darren's patch and if we can make it work with an earlier sphinx I'm happy to try. Stay tuned. Darren, can I assume you have tested this with 0.4.2 and the docs are building for you with your patch. I will test on my tree. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
On Tue, Dec 16, 2008 at 9:48 AM, John Hunter wrote:
> On Mon, Dec 15, 2008 at 10:02 AM, Darren Dale wrote:
>
> > You're right, the error does not occur with sphinx-0.5. It looks like the
> > API for registering nodes has changed as of 0.5. The development branch
> of
> > sphinx was throwing errors when it got to latex, so I had a look and came
> up
> > with some changes that work with both version 0.5 and the development
> > branch. The changes are not compatible with sphinx-0.4.2, but it looks
> like
> > we are requiring version 0.5 or later now anyway. If this is the case,
> I'll
> > go ahead and commit the changes. Here is the diff, please let me know if
> I
> > should commit or if I should hold off:
>
> I am getting errors trying to apply this patch on the 0.98.5 branch.
> Could you send a fresh diff against the HEAD of that branch, and
> attach it rather than paste it.
>
Here is the diff. I think I wasn't clear though, this diff is intended to
be compatible with sphinx-0.5 and later, it is not compatible with earlier
versions. I can build the documentation using sphinx-0.5 with or without
this patch, but the patch will be needed for future versions of sphinx,
including the sphinx development branch.
I never did get to the bottom of the error building our docs with
sphinx-0.4.2. I think it was an entirely different issue.
Index: doc/sphinxext/inheritance_diagram.py
===
--- doc/sphinxext/inheritance_diagram.py(revision 6626)
+++ doc/sphinxext/inheritance_diagram.py(working copy)
@@ -39,8 +39,6 @@
from md5 import md5
from docutils.nodes import Body, Element
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
from docutils.parsers.rst import directives
from sphinx.roles import xfileref_role
@@ -409,12 +407,9 @@
inheritance_diagram_directive)
def setup(app):
-app.add_node(inheritance_diagram)
-
-HTMLTranslator.visit_inheritance_diagram = \
-visit_inheritance_diagram(html_output_graph)
-HTMLTranslator.depart_inheritance_diagram = do_nothing
-
-LaTeXTranslator.visit_inheritance_diagram = \
-visit_inheritance_diagram(latex_output_graph)
-LaTeXTranslator.depart_inheritance_diagram = do_nothing
+app.add_node(inheritance_diagram,
+ html=(visit_inheritance_diagram(html_output_graph),
+ do_nothing))
+app.add_node(inheritance_diagram,
+ latex=(visit_inheritance_diagram(latex_output_graph),
+do_nothing))
Index: doc/sphinxext/mathmpl.py
===
--- doc/sphinxext/mathmpl.py(revision 6626)
+++ doc/sphinxext/mathmpl.py(working copy)
@@ -6,8 +6,6 @@
from docutils import nodes
from docutils.parsers.rst import directives
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
import warnings
# Define LaTeX math node:
@@ -69,8 +67,6 @@
self.body.append(latex2html(node, source))
def depart_latex_math_html(self, node):
pass
-HTMLTranslator.visit_latex_math = visit_latex_math_html
-HTMLTranslator.depart_latex_math = depart_latex_math_html
# Add visit/depart methods to LaTeX-Translator:
def visit_latex_math_latex(self, node):
@@ -83,9 +79,14 @@
'\\end{equation}'])
def depart_latex_math_latex(self, node):
pass
-LaTeXTranslator.visit_latex_math = visit_latex_math_latex
-LaTeXTranslator.depart_latex_math = depart_latex_math_latex
+app.add_node(latex_math, html=(visit_latex_math_html,
+ depart_latex_math_html))
+app.add_node(latex_math, latex=(visit_latex_math_latex,
+depart_latex_math_latex))
+app.add_role('math', math_role)
+
+
from matplotlib import rcParams
from matplotlib.mathtext import MathTextParser
rcParams['mathtext.fontset'] = 'cm'
Index: doc/sphinxext/only_directives.py
===
--- doc/sphinxext/only_directives.py(revision 6626)
+++ doc/sphinxext/only_directives.py(working copy)
@@ -4,8 +4,6 @@
#
from docutils.nodes import Body, Element
-from docutils.writers.html4css1 import HTMLTranslator
-from sphinx.latexwriter import LaTeXTranslator
from docutils.parsers.rst import directives
class html_only(Body, Element):
@@ -63,9 +61,6 @@
directives.register_directive('latexonly', LatexOnlyDirective)
def setup(app):
-app.add_node(html_only)
-app.add_node(latex_only)
-
# Add visit/depart methods to HTML-Translator:
def visit_perform(self, node):
pass
@@ -76,12 +71,7 @@
def depart_ignore(self, node):
node.children = []
-HTMLTranslator.visit_html_only = visit_perform
-HTMLTranslator.depar
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
On Tue, Dec 16, 2008 at 9:39 AM, John Hunter wrote: > On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom > wrote: > > > Another option would be to not generate the high-res png and pdf > > examples. (Either or both). Just removing them after the fact won't > > work, since one would end up with broken links from the docs. We would > > also have to change the html to not include those links. It should be > > fairly simple to provide an option to the doc build system to do this, > > and I'm happy to implement that if we all agree that's the direction to > > take. > > This is fine with me. Just add an rc option > > doc.minimal_footprint > > or something like that which drops the high res and pdf. This will > prbably reduce the size 50-60% > > I have also removed the mpl_data symlink in my doc tree, and am still > testing before I commit, because that is causing our binaries to get > much larger on platforms which do not properly support linking. > Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the > docs. I am leaving the mpl_examples symlink because of all the > relative path woes in pyplot. > > Other than simple optimizations like this, I am discinclined to try > and build smaller manuals simply to reduce their size. The feature > that caused the explosion in size between 98.3 and 98.5 is the > gallery, and image enhanced examples, which is arguably the most > useful feature on the site. > It seems like the documentation should be a separately installable package as far as package managers are concerned. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Automated test harness discussion...
On Tue, Dec 16, 2008 at 11:12 AM, Drain, Theodore R wrote: > - Embed a font with the tests to eliminate font server differences (no > experience with this so I'm not sure how hard this would be). We could even > create a dummy font that just has black squares for each character - it still > tests that everything is drawn in the correct place and runs properly and > eliminates subtle character differences. Since we ship our own fonts, it is pretty easy to test against a known set. Just set up the rc to use Vera, and cm* or stix* for math. > - Create a testing backend that records the drawing commands as a set of > meta-data like (draw red line from point 1 to point 2). The test case then > checks that the proper commands were issued by the test script. This > eliminates drawing completely. A nice comparison suite would allow loose > comparisons like "make sure a vertical line was drawn from (10,20) to (30,40) > with a pixel slop of 2 pixels. I think this idea has promise. I'll also add that we can do *a lot* more with simple API tests that do not look at the output but at least make sure the inputs, in all their variety, are at least accepted. backend_driver does this to an extent, but I will be adding nose tests for any new features I add. Eg, for the recent markevery, which can be None, an integer or a length 2 tuple, I added this simple test to unit/nose_tests def test_markevery(): x, y = np.random.rand(2, 100) # check marker only plot fig = plt.figure() ax = fig.add_subplot(111) ax.plot(x, y, 'o', label='default') ax.plot(x, y, 'd', markevery=None, label='mark all') ax.plot(x, y, 's', markevery=10, label='mark every 10') ax.plot(x, y, '+', markevery=(5, 20), label='mark every 5 starting at 10') ax.legend() fig.canvas.draw() plt.close(fig) # check line/marker combos fig = plt.figure() ax = fig.add_subplot(111) ax.plot(x, y, '-o', label='default') ax.plot(x, y, '-d', markevery=None, label='mark all') ax.plot(x, y, '-s', markevery=10, label='mark every 10') ax.plot(x, y, '-+', markevery=(5, 20), label='mark every 5 starting at 10') ax.legend() fig.canvas.draw() plt.close(fig) Having well defined tests that heavily exercise the frontend API would be a significant step forward, and the harder question of output comparison could be added in. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Automated test harness discussion...
On Tue, Dec 16, 2008 at 09:12:24AM -0800, Drain, Theodore R wrote: > Continued from: requesting permission to remove traits and configobj... > Gael, > There might be ways to handle these problems. A lot of depends on what we're > trying to test. I agree that if we take the example scripts, run them, and > save the plots, we'll never get an automated test harness to figure things > out because of machine differences. Absolutely. I was just saying that we where giving up because, in our case the cost was bigger than the benefit. However, we rely strongly on hardware acceleration, so we don't control completely our rendering pipeline, and images can vary by a huge amount (eg when the z-ordering is screwed up). You can always design more robust test by proper analysis of the images, but that could also be a PhD research program :). I am not saying MPL shouldn't be going down that way, though. Gaël -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] os x egg fubar?
Charlie Moad wrote: > Most people > get a successful install, but then setuptools tries to go out and grab > the source anyways. I can't say that I know a good solution for osx. This may be moot due to what John H. has done, but I thought all you need to do to stop setuptools from going and grabbing the source is to re-name the egg -- couldn't we just put the same egg up on the website with different names for different OS versions? for instance, I renamed: matplotlib-0.98.3-py2.5-macosx-10.3.egg to: matplotlib-0.98.3-py2.5.egg and easy_install installed it without a hitch on 10.4 Indeed, that name may work for 10.5 too. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 0.98.5 - API_CHANGES removed from tarball
On Tue, Dec 16, 2008 at 19:09, John Hunter wrote: > On Tue, Dec 16, 2008 at 12:03 PM, Sandro Tosi wrote: >> Hello, >> I see API_CHANGES is removed from tarball. it's a nice-to-have file, >> in order to allow a smooth transition from old to new version. >> >> Is it intentional? Is there another source from this information? is >> it not useful anymore? > > doc/api/api_changes.rst So now it's even nicely formatted, great! Thanks, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] os x egg fubar?
On Tue, Dec 16, 2008 at 1:04 PM, Christopher Barker wrote: > for instance, I renamed: > matplotlib-0.98.3-py2.5-macosx-10.3.egg > > to: > matplotlib-0.98.3-py2.5.egg > > and easy_install installed it without a hitch on 10.4 > > Indeed, that name may work for 10.5 too. I've posted new eggs and a binary mpkg installer for OS X and a new tarball. I've tried your egg renaming trick. Let me know how it goes. https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644 You have two choices for OS X : * matplotlib-0.98.5.1-py2.5-macosx10.5.zip - a binary mpkg installer * matplotlib-0.98.5.1-py2.5-macosx.egg - an egg with the known problems fixed. Please give it another whirl and let me know. JDH > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Basemap question for Jeff: different data directory?
Jeff, Is it possible to install the basemap data into a different directory? I'm trying to set up a tool delivery layout for our users that allows me to rapidly update packages that tend to change. We have a core set of software that our code is built on and it's a lot of work for us to update that and test it on every platform. What I'm doing is separating out the packages of that core set that we generally need to update at a higher rate (currently that's matplotlib and sphinx) because they're under more active development. The largest piece (by an order of magnitude) of these active tools is the basemap data. What I'd really like to do is install the basemap data with the core set of tools and then tell basemap where it's located instead of having to redeliver this large chunk of unchanging data every time we do a bug fix update to MPL. Perhaps by setting an environment variable that takes precedence over the default location? Any thoughts? I could put a patch together for it if you think it's worthwhile. Thanks, Ted -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
On Tue, Dec 16, 2008 at 15:39, John Hunter wrote: > On Tue, Dec 16, 2008 at 8:10 AM, Michael Droettboom wrote: > >> Another option would be to not generate the high-res png and pdf >> examples. (Either or both). Just removing them after the fact won't >> work, since one would end up with broken links from the docs. We would >> also have to change the html to not include those links. It should be >> fairly simple to provide an option to the doc build system to do this, >> and I'm happy to implement that if we all agree that's the direction to >> take. > > This is fine with me. Just add an rc option > > doc.minimal_footprint > > or something like that which drops the high res and pdf. This will > prbably reduce the size 50-60% yes yes please :) It would be really great to have it full pylab_examples: 53M pylab_examples no hires: 26M pylab_examples no hires and no pdf: 12M completely another story! ;) > I have also removed the mpl_data symlink in my doc tree, and am still > testing before I commit, because that is causing our binaries to get > much larger on platforms which do not properly support linking. > Instead, we'll refer explicitly to ../lib/matplotlib/mpl-data in the > docs. I am leaving the mpl_examples symlink because of all the > relative path woes in pyplot. Another patch I can remove as soon as another release is done :) > Other than simple optimizations like this, I am discinclined to try > and build smaller manuals simply to reduce their size. The feature Exactly the same goal I have in mind: I don't want to reduce the information, but only those parts that adds "little" to the end users while add a lot of space (if you get what I mean). > that caused the explosion in size between 98.3 and 98.5 is the > gallery, and image enhanced examples, which is arguably the most > useful feature on the site. And even as a local reference!! I had once to display dates and I was sure I've seen an example that did it, but I didn't remember which one, so I run all of them to find it. Now I would have to look up a nice page full of images: much better! Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
Hello Darren, On Tue, Dec 16, 2008 at 16:03, Darren Dale wrote: > It seems like the documentation should be a separately installable package > as far as package managers are concerned. We already have separate the doc from other mpl parts, to be precise we have these pkgs: python-matplotlib - the real module - 2.3M python-matplotlib-data - data pkg - 1.1M python-matplotlib-dbg - debug symbols - 11M python-matplotlib-doc - documentation - 87M So reducing -doc package is something I'd like to archive, before upload the package into Debian archive. Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
On Tue, Dec 16, 2008 at 15:10, Michael Droettboom wrote: > One question to ask is whether we need both the .pdf and .html manuals, or > whether that could be broken up into two packages. That seems like an easy > one if that fits Debian policies (which I know nothing about) -- and > wouldn't degrade the documentation experience at all. Well, if you're talking about Matplotlib.pdf, the whole manual in pdf format, then maybe it doesn't worth: we already have a separate package for documentation, so I think that all doc should be there (with an adequate size :) ). > Is there any way to transparently gzip compress the html files (as I believe > Debian does with manpages)? sadly, the compression of manpage is handled directly by "man" executable, that uncompress and pipe the manpage into a PAGER. html pages are rendered by web browser, and in case of local documentation, the pages are read from local disk (so so web server to "uncompress"-on-the-fly). > Another option would be to not generate the high-res png and pdf examples. > (Either or both). that would be great. while pdf images are not that useful (at least from my pov: I'm browsing web pages, I don't want to spawn a pdf viewer to look at an image) hires could be "dropped" because even "normal-res" images seems to give a clear idea of the power of mpl. > Just removing them after the fact won't work, since one > would end up with broken links from the docs. We would also have to change > the html to not include those links. It should be fairly simple to provide > an option to the doc build system to do this, and I'm happy to implement > that if we all agree that's the direction to take. FWIW, I really like to see such an option :) > Beyond that, we'd be looking at selectively including certain examples, > which I worry would add additional maintenance burden if there's too much > divergence between the "full" and "small" manuals. I think that road should > be a last resort. If the size it's reasonable, then I would like to generate all the examples, because... well, I like them! :) Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?
On Tue, Dec 16, 2008 at 10:57 PM, Sandro Tosi wrote: > Hello Darren, > > On Tue, Dec 16, 2008 at 16:03, Darren Dale wrote: >> It seems like the documentation should be a separately installable package >> as far as package managers are concerned. > > We already have separate the doc from other mpl parts, to be precise > we have these pkgs: > > python-matplotlib - the real module - 2.3M > python-matplotlib-data - data pkg - 1.1M > python-matplotlib-dbg - debug symbols - 11M > python-matplotlib-doc - documentation - 87M > > So reducing -doc package is something I'd like to archive, before > upload the package into Debian archive. Thanks Sandro for working on it. Btw, having some form of the gallery as a Debian package would be useful, I was missing this recently, when I was hacking without an internet connection. Ondrej -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Native backend for Mac OS X
Dear all,
I have now implemented the draw_path_collection, draw_quad_mesh, and
draw_markers methods in the Mac OS X native backend (see patch 2179017 at
http://sourceforge.net/tracker/?func=detail&atid=560722&aid=2179017&group_id=80706).
Some timings are below. In terms of raw drawing speed, the native backend can
be either faster or slower than agg. On the other hand, the native backend can
be considerably faster if the agg backend uses many calls to draw(); the native
backend can avoid these superfluous because it has complete control over the
event loop (see the third example below).
Best,
--Michiel.
# Scatter plot
n = 1e6
import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(n)
y=np.sin(x)
ax=f.add_subplot(111)
plt.scatter(x,y,c=x**2.0)
# Time in seconds
# n100,0001,000,000 2,000,0003,000,000
# MacOSX645 92 140
# WxAgg 756 112 172
# TkAgg 956 113 172
# GtkAgg755 111 173
# Quad mesh
import numpy as np
from matplotlib.pyplot import figure, show, savefig
from matplotlib import cm, colors
from numpy import ma
n = 1000
x = np.cos(np.linspace(-1.5,1.5,n))
y = np.linspace(-1.5,1.5,n*2)
X,Y = np.meshgrid(x,y);
Qx = np.sin(Y**2) - np.cos(X)
Qz = np.sin(Y) + np.sin(X)
Qx = (Qx + 1.1)
Z = np.sqrt(X**2 + Y**3)/5;
Z = (Z - Z.min()) / (Z.max() - Z.min())
# The color array can include masked values:
Zm = ma.masked_where(np.fabs(Qz) < 0.5*np.amax(Qz), Z)
fig = figure()
ax = fig.add_subplot(111)
ax.set_axis_bgcolor("#bdb76b")
ax.pcolormesh(Qx,Qz,Z)
show()
# Timings in seconds
# nMac OS X TkAgg
# 500 6 6
# 1000 23 7
# 2000138 40
# Subplots
from pylab import *
figure()
x=np.arange(20)
y=1+x**2
n = 4
for i in range(n*n):
subplot(n,n,i+1)
bar(x,y,log=True)
xlim(-5,25)
ylim(1,1e4)
# Timings in seconds
# n Mac OS X TkAgg
# 2 2 6
# 3 3 23
# 4 5 66
--- On Tue, 10/28/08, Michiel de Hoon wrote:
> --- On Tue, 10/28/08, John Hunter
> wrote:
> > I haven't had a chance to look at the code yet,
> > but I suspect he hasn't implemented the
> > path collection draw method. If it's not
> > implemented, we fall back on drawing each path
> > separately, which is a lot slower. scatter ultimately
> > triggers a call to Renderer.draw_path_collection
> > which has a default implementation and a specialization
> > in backend_agg.
>
> Good point. Indeed I was not aware of the
> draw_path_collection method and I have not implemented it. I
> will implement this method and report back with the timings
> for Eric's example.
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] calculate axes position at drawing time
Hello, I'm thinking about slightly modifying the draw() method of the Axes class, so that user can optionally calculate the position of the axes at drawing time. It may be considered as a general version of the apply_aspect() method. For example, instead of "self.apply_aspect()" call in the draw function, we may put something like below. if self._axes_locator: self._axes_locator(self, renderer) else: self.apply_aspect() where self._axes_locator is a (user-supplied) callable object which takes the axes itself and the renderer as arguments. I have been running a similar version of this, and I found it quite helpful especially when drawing images. Here are a few of my use cases. * colorbar (or any kind of axes) whose location is adjusted to match the image location (which is calculated on the fly with apply_aspect). * grid of images (of same size) with fixed space between them. I guess the needed change is not significant and I don't think it will interfere with other things of Axes class. So, how do others think? Regards, -JJ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] (group) id support for artist
John and others, I just committed a small patch that add gid(group id) as a property of the Artist. And also some small changes here and there, so that the svg backend use this gid as the ID of each element. To do this, I slightly changed the calling convention of the open_group() methods in Backends class. I have mentioned about this some time ago, and these changes are meant to be useful for some postprocessing of the svg fie http://www.nabble.com/Re%3A-SVG-clickable-images-p20241569.html I added two example, which apply gaussian blurring filter (for dropshadow) and some lighting effects to the svg files created with MPL. I added them under "examples/misc" because the examples are SVG specific. Let me know if there is any other suitable place. Note that the svg filter is not supported by all the svg renderer. Inkscape is the best open source tool that I know of which supports svg filter. The lighting filters (used svg_filter_pie.py) work fine with inkscape. Gaussian blurring (svg_filter_line.py) is also supported by firefox. Regards, -JJ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
