matplotlib-devel Mailing List for matplotlib (Page 2)

The bug was actually in the path simplification. In really degenerate 
cases (bravo for finding it) of paths that are completely outside of the 
clip region, it would create a path with a single LINETO command.
This is now fixed in SVN on the branch and trunk.
Mike
Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
> 
>> Jeff Whitaker <js...@fa...> writes:
>>
>> 
>> 
>>> Jouni: That test script now crashes with:
>>>
>>> File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
>>> line 1214, in pathOperations
>>> raise ValueError, 'Path lacks initial MOVETO'
>>> ValueError: Path lacks initial MOVETO
>>> 
>>> 
>> I think this confirms my suspicion that the bug is really elsewhere. A
>> path in PDF needs to begin with a "m" that sets the initial point, and
>> that particular Path object only consisted of one LINETO operation. Am I
>> correct in thinking that this is an invalid path?
>> 
>> 
> Yes -- that path should be considered invalid, though the Path class 
> doesn't do any verification. I'll add this. I'm surprised that it's 
> coming from the line class, which in general doesn't allow for 
> customization of the path codes. There must be something unanticipated 
> happening.
>
> Cheers,
> Mike
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jouni K. Seppänen wrote:
> Jeff Whitaker <js...@fa...> writes:
>
> 
>> Jouni: That test script now crashes with:
>>
>> File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
>> line 1214, in pathOperations
>> raise ValueError, 'Path lacks initial MOVETO'
>> ValueError: Path lacks initial MOVETO
>> 
>
> I think this confirms my suspicion that the bug is really elsewhere. A
> path in PDF needs to begin with a "m" that sets the initial point, and
> that particular Path object only consisted of one LINETO operation. Am I
> correct in thinking that this is an invalid path?
> 
Yes -- that path should be considered invalid, though the Path class 
doesn't do any verification. I'll add this. I'm surprised that it's 
coming from the line class, which in general doesn't allow for 
customization of the path codes. There must be something unanticipated 
happening.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jeff Whitaker <js...@fa...> writes:
> Jouni: That test script now crashes with:
>
> File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
> line 1214, in pathOperations
> raise ValueError, 'Path lacks initial MOVETO'
> ValueError: Path lacks initial MOVETO
I think this confirms my suspicion that the bug is really elsewhere. A
path in PDF needs to begin with a "m" that sets the initial point, and
that particular Path object only consisted of one LINETO operation. Am I
correct in thinking that this is an invalid path?
I'm not too familiar with Path (and I'm terribly busy today) but I think
the way to catch this bug is to add a sanity check to Path, similar to
the check in the pdf backend that produces that error. Then the
traceback would show what code is creating the invalid path -- the
traceback from the backend is too late in the execution to tell us that.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jouni K. Seppänen wrote:
> Could somebody test that script with current trunk (rev. 7899)? I don't
> have basemap installed, but I think my latest change might shake out the
> bug.
>
> 
Jouni: That test script now crashes with:
Traceback (most recent call last):
 File "testpdf.py", line 28, in <module>
 savefig('testfig.pdf')
 File "/Users/jwhitaker/lib/python/matplotlib/pyplot.py", line 355, in 
savefig
 return fig.savefig(*args, **kwargs)
 File "/Users/jwhitaker/lib/python/matplotlib/figure.py", line 1055, in 
savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/Users/jwhitaker/lib/python/matplotlib/backend_bases.py", line 
1618, in print_figure
 **kwargs)
 File "/Users/jwhitaker/lib/python/matplotlib/backend_bases.py", line 
1476, in print_pdf
 return pdf.print_pdf(*args, **kwargs)
 File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
line 2094, in print_pdf
 self.figure.draw(renderer)
 File "/Users/jwhitaker/lib/python/matplotlib/artist.py", line 55, in 
draw_wrapper
 draw(artist, renderer, *kl)
 File "/Users/jwhitaker/lib/python/matplotlib/figure.py", line 772, in draw
 for a in self.axes: a.draw(renderer)
 File "/Users/jwhitaker/lib/python/matplotlib/artist.py", line 55, in 
draw_wrapper
 draw(artist, renderer, *kl)
 File "/Users/jwhitaker/lib/python/matplotlib/axes.py", line 1761, in draw
 a.draw(renderer)
 File "/Users/jwhitaker/lib/python/matplotlib/artist.py", line 55, in 
draw_wrapper
 draw(artist, renderer, *kl)
 File "/Users/jwhitaker/lib/python/matplotlib/lines.py", line 533, in draw
 drawFunc(renderer, gc, tpath, affine.frozen())
 File "/Users/jwhitaker/lib/python/matplotlib/lines.py", line 869, in 
_draw_lines
 self._lineFunc(renderer, gc, path, trans)
 File "/Users/jwhitaker/lib/python/matplotlib/lines.py", line 920, in 
_draw_dashed
 renderer.draw_path(gc, path, trans)
 File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
line 1353, in draw_path
 rgbFace is None and gc.get_hatch_path() is None)
 File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
line 1235, in writePath
 cmds = self.pathOperations(path, transform, clip)
 File "/Users/jwhitaker/lib/python/matplotlib/backends/backend_pdf.py", 
line 1214, in pathOperations
 raise ValueError, 'Path lacks initial MOVETO'
ValueError: Path lacks initial MOVETO
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Could somebody test that script with current trunk (rev. 7899)? I don't
have basemap installed, but I think my latest change might shake out the
bug.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

See my feedback in the bug report.
Mike
Thomas Robitaille wrote:
> Hi,
>
> Running the simple attached test.py script creates a very simple 
> test.eps. Converting this to a pdf file with ps2pdf causes the 
> negative numbers to disappear (except the minus sign). Of course, the 
> PDF backend can be used from the start, but there are situations (e.g. 
> typesetting with LaTeX where one needs to include an EPS file, and the 
> final document will be a PDF file, in which case the negative numbers 
> disappear during the conversion). I have submitted a bug report:
>
> https://sourceforge.net/tracker/?func=detail&aid=2883256&group_id=80706&atid=560720 
>
>
> Cheers,
>
> Tom
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> 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

Hi,
Running the simple attached test.py script creates a very simple 
test.eps. Converting this to a pdf file with ps2pdf causes the 
negative numbers to disappear (except the minus sign). Of course, the 
PDF backend can be used from the start, but there are situations (e.g. 
typesetting with LaTeX where one needs to include an EPS file, and the 
final document will be a PDF file, in which case the negative numbers 
disappear during the conversion). I have submitted a bug report:
https://sourceforge.net/tracker/?func=detail&aid=2883256&group_id=80706&atid=560720
Cheers,
Tom

On Wed, Oct 21, 2009 at 09:23:54AM +0200, Georg Brandl wrote:
> Hi,
> one thing I missed when I switched from Gnuplot to matplotlib was that I
> can't press "q" to close a window but have to use the window manager; in
> one environment I work in that means I have to use the mouse to close a
> window.
I am +1 on that feature request. I don't have time to code it, though
:).
Gaël

Hi,
one thing I missed when I switched from Gnuplot to matplotlib was that I
can't press "q" to close a window but have to use the window manager; in
one environment I work in that means I have to use the mouse to close a
window.
I made a custom key handler that does the following:
 try:
 event.canvas.manager.destroy()
 except AttributeError:
 pass
which seems to work, at least with GtkAgg (I didn't venture to find out
why the AttributeError is raised, it works in spite of that).
Would it make sense to have that shortcut by default (and working for all
windowing backends)?
Georg
-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

Hi all,
Last night, I committed a patch to support what I'm calling a
patheffect. You may think of it as a customization of the
Renderer.draw_path method.
I added an example "patheffect_demo.py" and its output is attached.
Actually, this is nothing new, and mpl already can do these kind of
thing. What I wanted with the patheffects feature is to make it more
easy (especially with Text). And something like below is what I came
up with.
 txt = ax1.annotate("test", (1., 1.)), (0., 0),
 txt.set_path_effects([PathEffects.withStroke(linewidth=3, foreground="w")])
I'm not quite sure if the current API is optimal and I'll appreciate
any API suggestions.
Regards,
-JJ

Hi,
It seems that the PatchCollection class does not preserve the 
facecolor attribute of patches when match_original=True. I have 
submitted a bug report with a script to reproduce the issue:
https://sourceforge.net/tracker/?func=detail&aid=2881485&group_id=80706&atid=560720
Cheers,
Tom

Eric Bruning wrote:
> I'm using basemap to plot a dataset* that has longitude values like so:
>
> lon = [0, 2, 4, ..., 356, 358]
>
> I'd like to use Basemap.shiftgrid to transform the longitudes and data
> to the -180, 180 interval, but I get 'ValueError, cyclic point not
> included' since 360 isn't among the longitudes.
>
> Attached is a version of shiftgrid that attempts to handle the
> non-cyclic case. There are pseudo-unit-tests that demonstrate the
> cyclic and non-cyclic case for a 180 degree shift.
>
> Thanks,
> Eric
> 
Eric: Thanks - I've updated the shiftgrid function in SVN with your 
changes, and added your tests to test.py.
-Jeff

[Putting this back on devel]
> Have you checked scikits.timeseries.lib.plotlib ? We provide some functions
> that adapt the ticks to the frequency of you base series, but also according
> to the range of the axes. For example, if you work with a 100-y daily
> timeseries, you'll have major ticks every 5 years if you plot the whole
> series, every month if you plot or zoom on one year only, etc.
> it may be worthwhile to give it a try. I'd be happy to help adapting our
> code to remove the dependency on scikits.timeseries if needed...
No, I hadn't seen this. And argh!, I wish I had *before* I had coded
up something that met my needs. I hate to see a duplication of effort
and would love to see more of your matplotlib extensions moved into
matplotlib itself. Having said that, I now have a patch that
accomplishes what I want and (now) keeps our unit tests passing. I've
also pretty much expended all the time I have for matplotlib
development in the short term. So if one of the other devs is
interested, awesome. But for me at this point, I can't go study yet
more code when I have something IMO ready to check in.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Oct 14, 2009 at 3:59 PM, John Hunter <jd...@gm...> wrote:
> 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.
Here's a patch that implements the ideas I have. To the best of my
ability, it preserves the same behavior as before, it just opens it up
to configuration by the user instead of being hard-coded. It adds:
1) Configuring the minimum number of ticks, which determines whether
to do yearly, monthly, etc. ticking
2) Configuring the maximum number of ticks, which is used to select
what interval of ticking to use. This is actually
done on a per-frequency basis. This helps to keep in line with
previous behavior and is useful for keeping tick spacing in line with
what the label would be for a given frequency. The user can also
simply pass an integer that
gives the maximum for all frequencies.
3) A dictionary of intervals corresponding to each frequency. This
keeps the previous functionality of appropriate intervals for each
frequency, but also opens it up to user configuration.
4) Optional ticking on multiples of the interval. Previously, if you
were ticking with, say, 10 minute intervals, and the range happened to
start at 33 minutes, you'd get ticks at 33, 43, 53, etc. With this
flag set, the ticks instead end up at 40, 50, 0, 10, etc.
I'd appreciate anyone looking this over for any glaring problems
before I check this in. I've done my best to preserve old
functionality, though I'm still working on getting the unit tests to
run here. It also passes my own testing here when I fiddle with the
new knobs that have been exposed. My one question is: how important
is keeping API compatibility? The constructor tries to follow the
convention of the rest of the module (tz is last or nearly so), but
this breaks compatibility (where tz was the only argument). Also, to
me, it would be nice to tick multiples of the interval by default.
Thoughts?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Thanks.
I can reproduce the bug and the patch looks good.
The patch is applied to the maint. branch and the svn head.
Regards,
-JJ
On Thu, Oct 15, 2009 at 4:30 PM, Stan West <sta...@nr...> wrote:
> Developers:
>
> I happened upon a small bug in which changing the rotation mode of text does
> not take effect until another property is changed:
>
> t = plt.text(0.5, 0.5, 'Lorem ipsum', rotation=-45)
> # rotation_mode defaults to None
> t.set_rotation_mode('anchor')
> plt.draw() # the new rotation mode doesn't take effect
> t.set_rotation(-44)
> plt.draw() # now the angle and rotation mode are updated
>
> This seems to be corrected by adding _rotation_mode to the properties
> handled by get_prop_tup; I've attached a patch for your review.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I'm using basemap to plot a dataset* that has longitude values like so:
lon = [0, 2, 4, ..., 356, 358]
I'd like to use Basemap.shiftgrid to transform the longitudes and data
to the -180, 180 interval, but I get 'ValueError, cyclic point not
included' since 360 isn't among the longitudes.
Attached is a version of shiftgrid that attempts to handle the
non-cyclic case. There are pseudo-unit-tests that demonstrate the
cyclic and non-cyclic case for a 180 degree shift.
Thanks,
Eric
*SST anomalies from http://nomads.ncdc.noaa.gov/thredds/dodsC/ersstv3Agg

Jens wrote:
> Hi,
> 
> on a fresh CentOS5.3 with SciPy installed from repository
> http://software.opensuse.org/download/home:/ashigabou/ and additional
> packages
> 	freetype-devel-2.*
> libpng-devel-1.*
> pygtk2-devel
> gtk2-devel
> the matplotlib-setup script "setup.py" fails with error:
> 
> ...
> wxPython: no
> * wxPython not found
> Traceback (most recent call last):
> File "setup.py", line 146, in ?
> import wx
> ImportError: No module named wx
> 
> This does _not_ happen if I use the 0.99.0 archive (on the _same_ machine).
> 
> It seems as if the setup.py 0.99.1.1 only runs if the optional package
> wx is installed.
It sounds to me like this is caused by a glitch in the release process, 
in which a version of setup.cfg was included accidentally. If you have 
such a file, try deleting it.
Eric
> 
> Greetings
> Jens
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, Oct 15, 2009 at 4:26 AM, Jens <jen...@gm...> wrote:
> Hi,
>
> just a remark.
> qt4 does not get detected on centos5.3 (probably the same on centos5.x
> and redhat 5.x). Installed are qt4-4.2.1* packages and qt4-devel-4.2.1*
> packages.
You need to install PyQt4

Hi,
just a remark.
qt4 does not get detected on centos5.3 (probably the same on centos5.x
and redhat 5.x). Installed are qt4-4.2.1* packages and qt4-devel-4.2.1*
packages.
Greetings
Jens

Hi,
on a fresh CentOS5.3 with SciPy installed from repository
http://software.opensuse.org/download/home:/ashigabou/ and additional
packages
	freetype-devel-2.*
 libpng-devel-1.*
 pygtk2-devel
 gtk2-devel
the matplotlib-setup script "setup.py" fails with error:
...
 wxPython: no
 * wxPython not found
Traceback (most recent call last):
 File "setup.py", line 146, in ?
 import wx
ImportError: No module named wx
This does _not_ happen if I use the 0.99.0 archive (on the _same_ machine).
It seems as if the setup.py 0.99.1.1 only runs if the optional package
wx is installed.
Greetings
Jens

Michael Hearne <mh...@us...> writes:
> 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."
This is probably a bug in the pdf backend. Ghostscript 8.62 complains
with "Error: /nocurrentpoint in --run--". This suggests that an "m"
(moveto) command is missing somewhere. I'm too busy to debug this today,
but please file a bug in the tracker.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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