matplotlib-devel Mailing List for matplotlib

I have attached a PDF created with matplotib/basemap. On my mac, 
Preview opens this file without any errors. However, Adobe Acrobat 
9.2.0 (Mac) reports this error:
"An error exists on this page. Acrobat may not display the page 
correctly. Please contact the person who created the PDF document to 
correct the problem."
It then goes ahead and displays the image correctly.
I have found similar issues with Illustrator, and older versions of 
Acrobat Professional where those pieces of software are unable to open 
the PDF at all.
The only free software I could find to validate PDFs (http://multivalent.sourceforge.net/index.html 
) has no complaints about this file.
Does anyone have any idea what might be causing these errors to 
(sometimes) occur?
Info:
matplotlib: 0.99.0
basemap: 0.99.4
The code that created the PDF is below:
#!/usr/bin/env python
import matplotlib
matplotlib.use('agg')
from mpl_toolkits.basemap import Basemap
from pylab import savefig,close,figure,arange,array
figwidth=6
figheight=6
clat = 39.132332
clon = -98.261719
fig = figure(figsize=(figwidth,figheight),edgecolor='g',facecolor='g')
ax1 = fig.add_axes([0,0,1.0,1.0])
map = Basemap(resolution='c',
 projection='ortho',
 lon_0=clon,lat_0=clat,ax=ax1)
map.drawcountries(linewidth=0.1,color=[0.2,0.2,0.2])
map.drawcoastlines(linewidth=0.05,color=[0.2,0.2,0.2])
map.drawlsmask((230,230,230,255),(119,155,207,255))
meridians = arange(-180,210,30)
parallels = arange(-90,120,30)
map 
.drawmeridians(meridians,linewidth=0.1,dashes=[1,0],color=[0.2,0.2,0.2])
map 
.drawparallels(parallels,linewidth=0.1,dashes=[1,0],color=[0.2,0.2,0.2])
pcx,pcy = map(clon,clat)
map 
.plot 
(array 
([pcx]),array([pcy]),'ro',linewidth=1,markersize=5,markeredgecolor='r')
map.drawmapboundary(color='k',linewidth=2.0)
savefig('testfig.pdf')
close('all')

On Wed, Oct 14, 2009 at 3:47 PM, Ryan May <rm...@gm...> wrote:
> On Wed, Oct 14, 2009 at 3:08 PM, John Hunter <jd...@gm...> wrote:
>> Most likely this is just due to an oversight in the __all__ so just
>> add it there in the branch and it should get picked up next time we
>> build the docs
>
> Done. I also added them to the module-level docstring.
>
> Along these lines, I was trying to make use of AutoDateLocator, and as
> far as I can tell, there's no way to customize its behavior right now.
> So when trying to use this for doing major and minor ticks, there's
> no difference. It looks like in the get_locator() method of
> AutoDateLocator, numticks is used to control what types of ticking
> (yearly, monthly) is used. Would it make sense to have this as an
> attribute of self so that the user can tweak it? Or maybe go to:
>
> 1) minticks (instead of numticks) which specifies a minimum number of
> ticks that are desired,
>   to select yearly, monthly, etc.
> 2) maxticks, which specifies a maximum number of ticks, which can be
> used to calculate the interval
>   (every N'th month). Right now, the rules for selecting this are hard coded.
>
> I'm interested in hacking this up. But since you wrote the code, I
> want to make sure that going this direction makes sense to you.
I don't have a strong opinion on this -- making it more customizable
is a good thing -- this came up at scipy as well, where I contributed
a patch to make the AutoDateFormatter a little more customizable by
exposing a scaled dictionary mapping the scale to a format string. As
long as the extension to the AutoDateLocator preserves the core
functionality, I say have at it.
JDH

On Wed, Oct 14, 2009 at 3:08 PM, John Hunter <jd...@gm...> wrote:
> Most likely this is just due to an oversight in the __all__ so just
> add it there in the branch and it should get picked up next time we
> build the docs
Done. I also added them to the module-level docstring.
Along these lines, I was trying to make use of AutoDateLocator, and as
far as I can tell, there's no way to customize its behavior right now.
 So when trying to use this for doing major and minor ticks, there's
no difference. It looks like in the get_locator() method of
AutoDateLocator, numticks is used to control what types of ticking
(yearly, monthly) is used. Would it make sense to have this as an
attribute of self so that the user can tweak it? Or maybe go to:
1) minticks (instead of numticks) which specifies a minimum number of
ticks that are desired,
 to select yearly, monthly, etc.
2) maxticks, which specifies a maximum number of ticks, which can be
used to calculate the interval
 (every N'th month). Right now, the rules for selecting this are hard coded.
I'm interested in hacking this up. But since you wrote the code, I
want to make sure that going this direction makes sense to you.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Oct 14, 2009 at 2:16 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Anybody know what the status of AutoDateLocator/AutoDateFormatter in
> matplotlib.dates are? They work and seem reasonably well documented.
> However, they do not show up in our online docs:
>
> http://matplotlib.sourceforge.net/api/dates_api.html
>
> They show up in the inheritance graph, but are not mentioned elsewhere
> in the page and in fact have no link from the image. They're also not
> present in the __all__ in the dates module. If this is just an
> oversight, what do I need to do to make the classes show up in the
> docs?
Most likely this is just due to an oversight in the __all__ so just
add it there in the branch and it should get picked up next time we
build the docs
JDH

Hi,
Anybody know what the status of AutoDateLocator/AutoDateFormatter in
matplotlib.dates are? They work and seem reasonably well documented.
However, they do not show up in our online docs:
http://matplotlib.sourceforge.net/api/dates_api.html
They show up in the inheritance graph, but are not mentioned elsewhere
in the page and in fact have no link from the image. They're also not
present in the __all__ in the dates module. If this is just an
oversight, what do I need to do to make the classes show up in the
docs?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Andrew Straw wrote:
> Michael Droettboom wrote:
>
>> A couple more comments about the test framework -- which has already 
>> paid for itself ten times over. In Numpy (and a number of local 
>> Python projects), I can 'cd' to the tests directory and do something 
>> like:
>>
>> nosetests test_simplification.py:test_hatch_simplify
>>
>> and run on particular test, or a single file of tests. It's a huge 
>> time saver when trying to fix a bug. However, with matplotlib I get:
>>
>> > nosetests test_simplification.py
>> E
>> ======================================================================
>> ERROR: Failure: ImportError (cannot import name cbook)
>> <snip>
>> I suspect this is something peculiar to how matplotlib gets imported.
>> 
>
> Yes, it would be very nice, I absolutely agree. I'm not sure what's 
> going on, either, but I agree that it would be nice to fix. See below 
> for an idea.
>
>
>> Also, I have a quad-core machine, so I put this in my .noserc, which 
>> will run tests in parallel:
>>
>> [nosetests]
>> processes=4
>>
>> Unfortunately, due to however matplotlib is delegating to nose, this 
>> doesn't seem to get picked up.
>>
>> I don't know if I'll get a chance to look at these things right away, 
>> but thought I'd share in case the solutions are obvious to anyone 
>> else (which I know isn't good form, but hey... ;)
>> 
> My guess is that this may actually be related to the first issue. On 
> this second issue, though, I have a specific idea -- in order for MPL 
> to pickup the nose plugin, I had to do the song and dance in test() of 
> matplotlib/__init__.py in which I create a nose.config.Config 
> instance. I suspect this is why your processes argument isn't getting 
> through -- we're completely bypassing any local nose config and 
> creating ours programattically. I'm definitely not in favor the big 
> song and dance, so if you can rip it out and still get the plugin to 
> load, that would be super.
>
> Once that is figured out, presumably the direct call to "nosetests 
> test_simplification.py:test_hatch_simplify" will also load the nose 
> plugins and thus not exhibit weird behavior when a known failure is 
> encountered.
>
> I almost certainly won't get a chance to look at these right away, so 
> if anyone wants to go spelunking in the nose/mpl interaction, feel free.
I have a partial solution to these problems.
You can now do (from any directory)
 nosetests matplotlib.tests
and this automatically picks up nose parameters, so you can do 
multiprocessing, pdb, coverage and other nose niceties.
Strangely, I still can't make running "nosetests" from the 
lib/matplotlib/tests directory work. The imports seem to get all 
screwed up in that case, presumably because nose is messing with 
sys.path. Unfortunately, nosetests -P (which is supposed to not touch 
sys.path) doesn't seem to help.
I made sure that "import matplotlib; matplotlib.test()" still works, so 
the buildbots should be unaffected.
As a side note, I disabled the xmllint testing since curl (which xmllint 
uses to fetch the SVG DTD) has some problems with caching in a 
multiprocess situation. It gives random "Operation in progress" errors.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA