matplotlib-devel Mailing List for matplotlib

Hello all,
I am trying (unsuccessfully at present) to build the sampledoc tutorial on
windows with the freshest sampledoc tutorial and svn-build matplotlib on
windows xp, and I was wondering if I was missing a step along the way. I
would really like to be able to use Sphinx to document my project. A
collection of errors is generated when I try to do
make html
in the root sampledoc_tut folder that I pulled from svn. When I open the
generated html files, rather than seeing the plots on the extensions page, I
see no-image icons and the links to the code, png, and pdf files are output
as :
[`source code <.\plot_directive\pyplots/ellipses.py>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
, `hires.png <.\plot_directive\pyplots/ellipses.hires.png>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
,`pdf <.\plot_directive\pyplots/ellipses.pdf>`__<file:///C:/Documents%20and%20Settings/ibell/Desktop/sampledoc_tut/_build/html/extensions.html#id2>
]
Something seems to be messed up somewhere along the way. It should build
straight away out of the box, no??
The build errors that I get are:
C:\Documents and
Settings\ibell\Desktop\sampledoc_tut\sphinxext\inheritance_diagram.py:312:
DeprecationWarning: xfileref_role is deprecated, use XRefRole
 'class', ':class:`%s`' % name, name, 0, state)
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
(ERROR/3) Anonymous hyperlink mismatch: 5 references but 0 targets.
See "backrefs" attribute for IDs.
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\pyplots\ellipses.png
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\pyplots\ellipses.pdf
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\inline\aa2bc10136.png
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst::
WARNING: image file not readable:
C:\DocumentsandSettings\ibell\Desktop\sampledoc_tut\build\plot_directive\inline\aa2bc10136.pdf
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [ 50%] extensions
###writing output... [100%] index
C:\Documents and Settings\ibell\Desktop\sampledoc_tut\extensions.rst:220:
(WARNING/2) 'dot' called with invalid arguments
writing additional files... genindex search
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 6 warnings.
process_begin: CreateProcess(NULL, echo, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [html] Error 2
Any help would be greatly appreciated.
Ian
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

Sandro Tosi, on 2011年01月18日 19:29, wrote:
> Hi,
> 
> On Tue, Jan 18, 2011 at 15:00, Michael Droettboom <md...@st...> wrote:
> > I'm not sure PIL enters into it -- there shouldn't be any code path
> > involving PIL in that case.
> >
> > I think this a case where the image comparison tolerance needs to be
> > increased. You would do this be passing a "tol" parameter to the
> > image_comparison decorator on the pcolormesh test. The default is 1e-3,
> > but it should be conservatively increased until the test passes. You
> > can perform this experiment yourself, or attach the result image for the
> > test to this list and I can experiment to find a correct value.
> 
> I'm attaching the images, just for reference; as you can see, the
> difference is very tiny and with a tolerance of 0.02 I was able to
> pass the test (RMS Value: 0.0116511801977).
I just wanted to chime in that there *is* structure in the
differences between the images - which don't show up on screens
which don't have linearized gamma (the difference between 0 and 1
are much smaller in brightness than the difference between 127
and 128, for example).
A quick way to get around this is to just invert the colors.
in X11, I do this with 'xcalib -a -i' which toggles back to
normal if you run the command twice (Compiz also has it's own
version of this via some keyboard shortcut, IIRC, but I don't use
it). ImageMagick's convert can do this with the -negate flag. On
OS X, there's something like command-F8 to do this. 
For completeness, if you're interested in doing this in
matplotlib, ;) just subtract your (floating point 0.0-1.0) color
from (1.,1.,1.) to get the new color.
I'm attaching the difference image, with its colors inverted.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Thanks. I have increased the tolerance in the SVN repository in r 
8926/r8927.
Cheers,
Mike
On 01/18/2011 01:29 PM, Sandro Tosi wrote:
> Hi,
>
> On Tue, Jan 18, 2011 at 15:00, Michael Droettboom<md...@st...> wrote:
>> I'm not sure PIL enters into it -- there shouldn't be any code path
>> involving PIL in that case.
>>
>> I think this a case where the image comparison tolerance needs to be
>> increased. You would do this be passing a "tol" parameter to the
>> image_comparison decorator on the pcolormesh test. The default is 1e-3,
>> but it should be conservatively increased until the test passes. You
>> can perform this experiment yourself, or attach the result image for the
>> test to this list and I can experiment to find a correct value.
> I'm attaching the images, just for reference; as you can see, the
> difference is very tiny and with a tolerance of 0.02 I was able to
> pass the test (RMS Value: 0.0116511801977).
>
> Cheers,

Hi,
On Tue, Jan 18, 2011 at 15:00, Michael Droettboom <md...@st...> wrote:
> I'm not sure PIL enters into it -- there shouldn't be any code path
> involving PIL in that case.
>
> I think this a case where the image comparison tolerance needs to be
> increased. You would do this be passing a "tol" parameter to the
> image_comparison decorator on the pcolormesh test. The default is 1e-3,
> but it should be conservatively increased until the test passes. You
> can perform this experiment yourself, or attach the result image for the
> test to this list and I can experiment to find a correct value.
I'm attaching the images, just for reference; as you can see, the
difference is very tiny and with a tolerance of 0.02 I was able to
pass the test (RMS Value: 0.0116511801977).
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I'm not sure PIL enters into it -- there shouldn't be any code path 
involving PIL in that case.
I think this a case where the image comparison tolerance needs to be 
increased. You would do this be passing a "tol" parameter to the 
image_comparison decorator on the pcolormesh test. The default is 1e-3, 
but it should be conservatively increased until the test passes. You 
can perform this experiment yourself, or attach the result image for the 
test to this list and I can experiment to find a correct value.
Mike
On 01/17/2011 02:44 PM, Sandro Tosi wrote:
> Hi Ben,
> thanks for the fast reply!
>
> On Mon, Jan 17, 2011 at 20:35, Benjamin Root<ben...@ou...> wrote:
>> I have seen this before, and I think it was discussed once before.
>> Visually, there is very little difference,
> indeed, looking at the 2 images, I can't see any difference.
>
>> but supposedly there is some sort
>> of issue with different PIL versions. What version of PIL do you have?
> 1.1.7
>
> Cheers,

Dear matplotlib developpers,
I use matplotlib for several years and I'm very satisfied with the it.
I started using the basemap package a few days ago, and I noticed something
that looks like a bug :
With the Mollweide projection (and others too), when specifying rsphere=1.0,
the coastlines is not drawn in the
left part of the plot. With rsphere=2.0 the hidden part is smaller, and with
rsphere=10.0 it is not visible.
I'm using matplotlib 1.0.0 and basemap 1.0
To reproduce the bug :
m = Basemap(projection='moll',lon_0=180,rsphere=1.0)
m.drawcoastlines(linewidth=0.5, color='grey') # draw discrete coastlines
m.drawmapboundary() # draw a line around the map region
show()
Finally the hammer projection is missing for me :
In [5]: m=Basemap(projection='hammer',lon_0=180)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
/home/nat/pkg/python-matplotlib-basemap/<ipython console> in <module>()
/usr/lib/python2.7/site-packages/mpl_toolkits/basemap/__init__.pyc in
__init__(self, llcrnrlon, llcrnrlat, urcrnrlon, urcrnrlat, llcrnrx, llcrnry,
urcrnrx, urcrnry, width, height, projection, resolution, area_thresh,
rsphere, lat_ts, lat_1, lat_2, lat_0, lon_0, lon_1, lon_2, no_rot,
suppress_ticks, satellite_height, boundinglat, fix_aspect, anchor, ax)
 698 print 'warning: width and height keywords ignored
for %s projection' % _projnames[self.projection]
 699 else:
--> 700 raise ValueError(_unsupported_projection % projection)
 701
 702 # initialize proj4
ValueError: 'hammer' is an unsupported projection.
The supported projections are:
 aeqd Azimuthal Equidistant
 poly Polyconic
 gnom Gnomonic
 moll Mollweide
 tmerc Transverse Mercator
 nplaea North-Polar Lambert Azimuthal
 gall Gall Stereographic Cylindrical
 mill Miller Cylindrical
 merc Mercator
 stere Stereographic
 npstere North-Polar Stereographic
 geos Geostationary
 nsper Near-Sided Perspective
 vandg van der Grinten
 laea Lambert Azimuthal Equal Area
 mbtfpq McBryde-Thomas Flat-Polar Quartic
 sinu Sinusoidal
 spstere South-Polar Stereographic
 lcc Lambert Conformal
 npaeqd North-Polar Azimuthal Equidistant
 eqdc Equidistant Conic
 cyl Cylindrical Equidistant
 omerc Oblique Mercator
 aea Albers Equal Area
 spaeqd South-Polar Azimuthal Equidistant
 ortho Orthographic
 cass Cassini-Soldner
 splaea South-Polar Lambert Azimuthal
 robin Robinson

Seems to resolve the problem!
Thanks
2011年1月18日 Jae-Joon Lee <lee...@gm...>:
> Can you see if setting the "should_simplify" to False work? i.e.,
>
> path=cs.collections[5].get_paths()[0] #210 vertices
> path.should_simplify = False
> path.to_polygons()
>
> At least, it seems to conserve the number of vertices.
>
> Regards,
>
> -JJ
>
>
> On Tue, Jan 18, 2011 at 5:07 PM, Lionel Roubeyrie
> <lio...@gm...> wrote:
>> Hi,
>> is there a existing patch for this problem or do we have to use/modify
>> iter_segments for the moment?
>> thanks
>>
>> 2011年1月15日 Lionel Roubeyrie <lio...@gm...>:
>>> The problem appends on some paths/polygons, not all. Have a look at
>>> the joined pictures. The to_polygons method normally take care about
>>> polygons holes, but here some vertices are not converted, resulting in
>>> wrong geometries.
>>> #############
>>> import numpy as np
>>> import pylab as plb
>>> a=np.recfromtxt('rpatch3.grid', delimiter='\t',names=True)
>>> lev=np.linspace(a.ux.min(), a.ux.max(), 10)
>>> cs=plb.tricontourf(a.lon, a.lat, a.ux, lev)
>>> path=cs.collections[5].get_paths()[0] #210 vertices
>>> path.to_polygons() #16 vertices :(
>>> #############
>>> Cheers
>>>
>>> 2011年1月14日 Michael Droettboom <md...@st...>:
>>>> It's not obvious to me that this is wrong. The path has a MOVETO
>>>> command (1) in the middle, and thus should require the creation of two
>>>> polygons. Can you provide some code or pictures that demonstrate the
>>>> problem?
>>>>
>>>> Mike
>>>>
>>>> On 01/13/2011 05:54 PM, Lionel Roubeyrie wrote:
>>>>> Hi all,
>>>>> Using the last 1.0.1 matplotlib version,sometimes exporting paths to
>>>>> polygons gives wrong results like here (paths come from a
>>>>> tricontourset) :
>>>>> In [94]: path
>>>>> Out[94]:
>>>>> Path([[ 172.0079229  -43.79390934]
>>>>>  [ 171.97660793 -43.785   ]
>>>>>  [ 171.96206864 -43.78273625]
>>>>>  [ 171.959    -43.78114859]
>>>>>  ...
>>>>>  [ 171.593    -44.00678244]
>>>>>  [ 171.64906502 -44.01   ]
>>>>>  [ 171.654    -44.01077106]
>>>>>  [ 171.7068607  -44.0160044 ]], [1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>> 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2
>>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2])
>>>>> In [95]: path.vertices.shape
>>>>> Out[95]: (210, 2)
>>>>>
>>>>> but to_polygons gives another result :
>>>>> In [98]: path.to_polygons()
>>>>> Out[98]:
>>>>> [array([[ 172.0079229 , -43.79390934],
>>>>>     [ 171.86039224, -43.65   ],
>>>>>     [ 172.081   , -43.54450289],
>>>>>     [ 172.386   , -43.57010293],
>>>>>     [ 172.60631978, -43.67753099],
>>>>>     [ 172.59231502, -43.71219961],
>>>>>     [ 172.325   , -43.78095532],
>>>>>     [ 172.02   , -43.79497729]]),
>>>>>  array([[ 171.715   , -44.0160044 ],
>>>>>     [ 173.02676111, -43.92   ],
>>>>>     [ 172.935   , -43.53340591],
>>>>>     [ 171.40281884, -43.70029758],
>>>>>     [ 171.37760645, -43.94389688],
>>>>>     [ 171.54044973, -44.0037666 ],
>>>>>     [ 171.7068607 , -44.0160044 ],
>>>>>     [ 171.7068607 , -44.0160044 ]])]
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Space Telescope Science Institute
>>>> Baltimore, Maryland, USA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Lionel Roubeyrie
>>> lio...@gm...
>>> http://youarealegend.blogspot.com
>>>
>>
>>
>>
>> --
>> Lionel Roubeyrie
>> lio...@gm...
>> http://youarealegend.blogspot.com
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
-- 
Lionel Roubeyrie
lio...@gm...
http://youarealegend.blogspot.com

Can you see if setting the "should_simplify" to False work? i.e.,
path=cs.collections[5].get_paths()[0] #210 vertices
path.should_simplify = False
path.to_polygons()
At least, it seems to conserve the number of vertices.
Regards,
-JJ
On Tue, Jan 18, 2011 at 5:07 PM, Lionel Roubeyrie
<lio...@gm...> wrote:
> Hi,
> is there a existing patch for this problem or do we have to use/modify
> iter_segments for the moment?
> thanks
>
> 2011年1月15日 Lionel Roubeyrie <lio...@gm...>:
>> The problem appends on some paths/polygons, not all. Have a look at
>> the joined pictures. The to_polygons method normally take care about
>> polygons holes, but here some vertices are not converted, resulting in
>> wrong geometries.
>> #############
>> import numpy as np
>> import pylab as plb
>> a=np.recfromtxt('rpatch3.grid', delimiter='\t',names=True)
>> lev=np.linspace(a.ux.min(), a.ux.max(), 10)
>> cs=plb.tricontourf(a.lon, a.lat, a.ux, lev)
>> path=cs.collections[5].get_paths()[0] #210 vertices
>> path.to_polygons() #16 vertices :(
>> #############
>> Cheers
>>
>> 2011年1月14日 Michael Droettboom <md...@st...>:
>>> It's not obvious to me that this is wrong. The path has a MOVETO
>>> command (1) in the middle, and thus should require the creation of two
>>> polygons. Can you provide some code or pictures that demonstrate the
>>> problem?
>>>
>>> Mike
>>>
>>> On 01/13/2011 05:54 PM, Lionel Roubeyrie wrote:
>>>> Hi all,
>>>> Using the last 1.0.1 matplotlib version,sometimes exporting paths to
>>>> polygons gives wrong results like here (paths come from a
>>>> tricontourset) :
>>>> In [94]: path
>>>> Out[94]:
>>>> Path([[ 172.0079229  -43.79390934]
>>>>  [ 171.97660793 -43.785   ]
>>>>  [ 171.96206864 -43.78273625]
>>>>  [ 171.959    -43.78114859]
>>>>  ...
>>>>  [ 171.593    -44.00678244]
>>>>  [ 171.64906502 -44.01   ]
>>>>  [ 171.654    -44.01077106]
>>>>  [ 171.7068607  -44.0160044 ]], [1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>> 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2
>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2])
>>>> In [95]: path.vertices.shape
>>>> Out[95]: (210, 2)
>>>>
>>>> but to_polygons gives another result :
>>>> In [98]: path.to_polygons()
>>>> Out[98]:
>>>> [array([[ 172.0079229 , -43.79390934],
>>>>     [ 171.86039224, -43.65   ],
>>>>     [ 172.081   , -43.54450289],
>>>>     [ 172.386   , -43.57010293],
>>>>     [ 172.60631978, -43.67753099],
>>>>     [ 172.59231502, -43.71219961],
>>>>     [ 172.325   , -43.78095532],
>>>>     [ 172.02   , -43.79497729]]),
>>>>  array([[ 171.715   , -44.0160044 ],
>>>>     [ 173.02676111, -43.92   ],
>>>>     [ 172.935   , -43.53340591],
>>>>     [ 171.40281884, -43.70029758],
>>>>     [ 171.37760645, -43.94389688],
>>>>     [ 171.54044973, -44.0037666 ],
>>>>     [ 171.7068607 , -44.0160044 ],
>>>>     [ 171.7068607 , -44.0160044 ]])]
>>>>
>>>> Cheers
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Space Telescope Science Institute
>>> Baltimore, Maryland, USA
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> --
>> Lionel Roubeyrie
>> lio...@gm...
>> http://youarealegend.blogspot.com
>>
>
>
>
> --
> Lionel Roubeyrie
> lio...@gm...
> http://youarealegend.blogspot.com
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
is there a existing patch for this problem or do we have to use/modify
iter_segments for the moment?
thanks
2011年1月15日 Lionel Roubeyrie <lio...@gm...>:
> The problem appends on some paths/polygons, not all. Have a look at
> the joined pictures. The to_polygons method normally take care about
> polygons holes, but here some vertices are not converted, resulting in
> wrong geometries.
> #############
> import numpy as np
> import pylab as plb
> a=np.recfromtxt('rpatch3.grid', delimiter='\t',names=True)
> lev=np.linspace(a.ux.min(), a.ux.max(), 10)
> cs=plb.tricontourf(a.lon, a.lat, a.ux, lev)
> path=cs.collections[5].get_paths()[0] #210 vertices
> path.to_polygons() #16 vertices :(
> #############
> Cheers
>
> 2011年1月14日 Michael Droettboom <md...@st...>:
>> It's not obvious to me that this is wrong. The path has a MOVETO
>> command (1) in the middle, and thus should require the creation of two
>> polygons. Can you provide some code or pictures that demonstrate the
>> problem?
>>
>> Mike
>>
>> On 01/13/2011 05:54 PM, Lionel Roubeyrie wrote:
>>> Hi all,
>>> Using the last 1.0.1 matplotlib version,sometimes exporting paths to
>>> polygons gives wrong results like here (paths come from a
>>> tricontourset) :
>>> In [94]: path
>>> Out[94]:
>>> Path([[ 172.0079229  -43.79390934]
>>>  [ 171.97660793 -43.785   ]
>>>  [ 171.96206864 -43.78273625]
>>>  [ 171.959    -43.78114859]
>>>  ...
>>>  [ 171.593    -44.00678244]
>>>  [ 171.64906502 -44.01   ]
>>>  [ 171.654    -44.01077106]
>>>  [ 171.7068607  -44.0160044 ]], [1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>> 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2
>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>>>  2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2])
>>> In [95]: path.vertices.shape
>>> Out[95]: (210, 2)
>>>
>>> but to_polygons gives another result :
>>> In [98]: path.to_polygons()
>>> Out[98]:
>>> [array([[ 172.0079229 , -43.79390934],
>>>     [ 171.86039224, -43.65   ],
>>>     [ 172.081   , -43.54450289],
>>>     [ 172.386   , -43.57010293],
>>>     [ 172.60631978, -43.67753099],
>>>     [ 172.59231502, -43.71219961],
>>>     [ 172.325   , -43.78095532],
>>>     [ 172.02   , -43.79497729]]),
>>>  array([[ 171.715   , -44.0160044 ],
>>>     [ 173.02676111, -43.92   ],
>>>     [ 172.935   , -43.53340591],
>>>     [ 171.40281884, -43.70029758],
>>>     [ 171.37760645, -43.94389688],
>>>     [ 171.54044973, -44.0037666 ],
>>>     [ 171.7068607 , -44.0160044 ],
>>>     [ 171.7068607 , -44.0160044 ]])]
>>>
>>> Cheers
>>>
>>>
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Lionel Roubeyrie
> lio...@gm...
> http://youarealegend.blogspot.com
>
-- 
Lionel Roubeyrie
lio...@gm...
http://youarealegend.blogspot.com

Hey,
The test_rendered.html file probably should have been removed from the
release version. The idea behind this was to compare a PNG of the
browser rendered HTML5 plot with the standard PNG backend. (So users
without HTML5 support could see how the plugin performed).
These rendered PNG's are generated from the main test.html page by
running the rec.py receiver, and using the 'Connect' and 'Put images
to server' buttons on the bottom of test.html
Unfortunately the connect method uses a hardcoded IP address for the
WebSocket and so will need to be changed if you wanted to get this
working.
In short, as long as test.html produces three columns of plots (HTML5,
PNG and SVG), things are working fine.
I apologise for the slipshod release that left this code in :)
Cheers,
Simon Ratcliffe
On Fri, Jan 14, 2011 at 11:02 AM, Akad Demo <aka...@gm...> wrote:
> Hello,
>
> I run the test.py example from the folder mplh5canvas/test. This example
> generated in the output folder 2 html pages (test.html and
> test_rendered.html) and also 2 images (filename.png and filename.svg). The
> test.html page is displayed ok, but when I open the test_rendered.html page
> the images from the column "H5 Canvas (PNG from Chrome 4.0 OSX)" are not
> displayed.
>
> After I studied the source code of the test.py example I saw the following
> line:
>
> (line 85) thtml += "<td><img src='%s' width='%dpx' height='%dpx' />" %
> ("h5canvas_" + png_filename, w, h)
>
> Now the question is: What is supposed to be "h5canvas_" + png_filename?
> There is no image generated with this name in the output folder.
>
> The HTML 5 Canvas Backend was downloaded from here:
> http://code.google.com/p/mplh5canvas/downloads/list
>
> Thanks!
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Dear Matplotlib developers,
Attached is a patch to improve the functionality of legend.
The two biggest changes are as follows,
* Drawing of legend is delegated to "legend handlers".
* Introduces a new "Container" class. This is primarily to support
legend of complex plots (e.g., bar, errorbar, etc).
The first change is to ease the creation of customized legends. See
"legend_demo_custom_handler.py" for example.
The second change is to support legend of complex plots. Axes
instances now have a "containers" attribute. And this is only intended
to be used for generating a legend. For example, "bar" plots create a
series of Rectangle patches. Previously, it returned a list of these
patches. With the current change, it creates a container object of
these rectangle patches and return it instead. As the container class
is derived from a tuple, it should be backward-compatible.
Furthermore, the container object is added to the Axes.containers
attributes. And legend command use this "container" attribute to
properly create a legend for the bar.
A two example figures are attached.
As this patch introduces relatively significant changes. I wanted to
get some comments from others before I commit.
The change will be divided into four commits.
Regards,
-JJ