matplotlib-users Mailing List for matplotlib (Page 2)

On 19/05/2010 20:45, David wrote:
> Werner F. Bruhin<werner.bruhin@...>  writes:
>
>    
>>
>> On 19/05/2010 19:55, David Grudoski wrote:
>>
>>    I'm trying to build an executable using
>> PY2EXE; running Python 2.5.2 and wxPython 2.8.10.1 and MatplotLib 0.99.0
>>    I tried using the setup.py from the
>> PY2EXE.org Matplotlib page and although everything compiles correctly
>> and generates an executable.
>>    When I launch the executable I get the
>> following error:
>>    ================================================
>>    "The application requires a version of
>> wxPython greater than or equal to 2.8, but a matching version was not
>> found."
>>    You currently have these version(s)
>> installed.
>>
>>    ================================================
>>
>>
>>    I can compile an executable with PY2EXE and
>> wxPython that works fine, but apparantly somethins in the setup for
>> matplotlib is causing a problem.
>>
>>    Has anyone else seen this problem or know of
>> a solution?
>>
>> You need to patch matplotlib (backend_wx.py), see the bottom of this
>> page:http://www.py2exe.org/index.cgi/MatPlotLib
>> Werner
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>      
> Thanks for the reply Werner,
> I decided to try and construct the executable from the site using the
> "embedding_in_wx2.py" example. Again making sure the patch was in place on the
> backend_wx.py I again ran the python setup.py py2exe and everything compiled.
> Now when I run the exe it generate the following log file errors:
> Traceback (most recent call last):
>    File "embedding_in_wx2.py", line 21, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\backends\backend_wxagg.pyo", line 20, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\figure.pyo", line 19, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\axes.pyo", line 14, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\collections.pyo", line 21, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\backend_bases.pyo", line 32, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\widgets.pyo", line 12, in<module>
>    File "zipextimporter.pyo", line 82, in load_module
>    File "matplotlib\mlab.pyo", line 376, in<module>
> TypeError: unsupported operand type(s) for %: 'NoneType' and 'dict'
>    
This is due to using "optimize 1 or 2" in py2exe, the work around is to 
fix four lines in mpl.mlab.py as shown on the wiki page mentioned in the 
last thread.

Werner

Yes, it's true that uncommenting path.simplify : False line inside the
matplotlibrc file fixes the artifacts.  However, it also produces HUGE
PDF/EPS file sizes.  Perhaps, it's better to change path.simplify parameter
as needed inside the code via:

import matplotlib.pyplot as plt
plt.rcParams['path.simplify'] = False
# Plotting Code Block goes here
plt.rcdefaults()

Does anyone have another fix for this problem that DOES NOT produce HUGE
PDF/EPS files?


efiring wrote:
> 
> Jouni K. Seppänen wrote:
>> Jordan Dawe <jd...@eo...> writes:
>> 
>>> Contourf plots that I output in vector format files have little
>>> triangular glitches at the contour boundaries if the contoured array
>>> is larger than about 200x200. The same files in png format are
>>> perfect, even at very high dpi values.
>> 
>> The current svn trunk doesn't have the really jarring little triangles
>> (at least in the pdf output), but there are still several very obtuse
>> white triangles between the regions. Rasterization at a high dpi makes
>> the output somewhat better at the cost of larger output files:
>> 
>> c=contourf(X, Y, Z, 10)
>> axis((-3, 3, -3, 3))
>> savefig('unrasterized.pdf')
>> for d in c.collections:
>>     d.set_rasterized(True)
>> savefig('rasterized.pdf',dpi=200)
> 
> 
> At least in the trunk--and maybe in 0.99.0--the problem is caused by 
> path simplification.  In the trunk, for the eps file, it goes away 
> completely if I use a matplotlibrc with
> 
> path.simplify : False
> 
> In the trunk, what seems to be happening is that when a contour boundary 
> is almost straight, but has an inflection point, the curves for the 
> adjacent patch boundaries are simplified slightly differently.  This is 
> not surprising; if nothing else, the path will be traveled in a 
> different direction when it is an outer boundary than when it is an 
> inner boundary (for a set of concentric boundaries).
> 
> Jordan, try using a local matplotlibrc with the above.  Unless you are 
> already customizing via a local matplotlibrc, that line is all you need.
> 
> One reason the trunk behavior differs from 0.99.0 is that contour patch 
> boundaries are now being turned into compound boundaries instead of 
> using a branch cut to connect the outside path to the inside path.  I 
> suspect simplification is causing the artifacts in both cases, though.
> 
> Eric
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://old.nabble.com/eps-pdf-svg-contourf-contours-don%27t-overlap-properly-with-high-resolution-data-tp26982883p28617537.html
Sent from the matplotlib - users mailing list archive at Nabble.com.