matplotlib-devel Mailing List for matplotlib (Page 4)

On Fri, Sep 18, 2009 at 17:16, John Hunter <jd...@gm...> wrote:
> I filed a report at
> https://sourceforge.net/tracker/?func=browse&group_id=80706&atid=560720.
Ok, next time I'll file a bug on SF issue tracker instead of writing here.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Michael Droettboom wrote:
> Thanks. The subslicing optimization added in 0.99 was truncating the 
> polar path. Subslicing has been made more "cautious" now and will only 
> be applied when the axes are rectilinear and non-logarithmic.
>
> Interestingly, there was already a test in the test framework for this 
> bug, but the baseline image was wrong :)
I see you fixed that, too -- thanks. I can't remember the history of
this one particular test -- I think maybe I inherited it without a test
image or perhaps I just over-enthusiastically copied a broken image
without realizing it as such.
These unit tests have already shown their worth I think (fixing
non-deterministic layout, getting a grip on freetype, etc.), and their
value in preventing mistakes and regressions from creeping in is hard to
perceive but I think is also very real. As more and more tests are added
(and broken baseline images and test cases are fixed), the number of
regressions will almost certainly drop.
-Andrew

Thanks. The subslicing optimization added in 0.99 was truncating the 
polar path. Subslicing has been made more "cautious" now and will only 
be applied when the axes are rectilinear and non-logarithmic.
Interestingly, there was already a test in the test framework for this 
bug, but the baseline image was wrong :)
Mike
Sandro Tosi wrote:
> Hi all,
> with the simple code here below
>
> $ ipython -pylab
>
> In [1]: import numpy as np
>
> In [2]: theta = np.arange(0., 2., 1./180.)*np.pi
>
> In [3]: plt.polar(3*theta, theta/5)
>
> I obtain the attached images with 0.98.5.3 and 0.99.{0.1rc1} (didn't
> have time to test against SVN).
>
> AFAIUI, the 0.98.5.3 should be the correct behavior, so in 0.99.x
> there's a regression.
>
> Regards,
> 
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

On Fri, Sep 18, 2009 at 9:48 AM, Sandro Tosi <mat...@gm...> wrote:
> Hi all,
> with the simple code here below
>
> $ ipython -pylab
>
> In [1]: import numpy as np
>
> In [2]: theta = np.arange(0., 2., 1./180.)*np.pi
>
> In [3]: plt.polar(3*theta, theta/5)
>
> I obtain the attached images with 0.98.5.3 and 0.99.{0.1rc1} (didn't
> have time to test against SVN).
>
> AFAIUI, the 0.98.5.3 should be the correct behavior, so in 0.99.x
> there's a regression.
I filed a report at
https://sourceforge.net/tracker/?func=browse&group_id=80706&atid=560720.
JDH

Hi all,
with the simple code here below
$ ipython -pylab
In [1]: import numpy as np
In [2]: theta = np.arange(0., 2., 1./180.)*np.pi
In [3]: plt.polar(3*theta, theta/5)
I obtain the attached images with 0.98.5.3 and 0.99.{0.1rc1} (didn't
have time to test against SVN).
AFAIUI, the 0.98.5.3 should be the correct behavior, so in 0.99.x
there's a regression.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Apparently usetex_demo.py and dannys_example.py are same
(matplotlib/examples).
The latter might be deleted if no reference exist for that file.
-- 
Gökhan

Jouni K. Seppänen wrote:
> I just happened to type getp(gca()) on matplotlib 0.99.0, and the output
> looks all garbled:
Fixed in r7780 (branch) and 7781 (trunk).
Eric
> 
>>>> getp(gca())
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/axes.py:1269: DeprecationWarning: use ax.patch instead
> warnings.warn('use ax.patch instead', DeprecationWarning)
> stable = box
> a = 1.0
> or = C
> ated = False
> ct = auto
> scale_on = True
> scalex_on = True
> scaley_on = True
> = Axes(0.125,0.1;0.775x0.8)
> _locator = None
> _bgcolor = w
> [...]
> 
> It's been a long time since I last tried this, but does anyone have an
> idea what changes could have caused this? Could it be related to the
> ReST formatting in the docstrings?
> 
> Querying single attributes as in getp(gca(), 'yscale') seems to work
> fine, it's just this listing of all attributes that seems to be broken.
> 

Hi,
add_line method sets label to something like "_line1" if not set.
def add_line(self, line):
 if not line.get_label():
 line.set_label('_line%d'%len(self.lines))
add_collection sets label to "collection1" if not set.
def add_collection(self, collection, autolim=True):
 label = collection.get_label()
 if not label:
 collection.set_label('collection%d'%len(self.collections))
add_patch does nothing.
Can someone enlighten me why add_line and add_collection method sets the label?
Actually, my issue here is that collections without empty label show
up in the legend as "collection1" etc., instead of being ignored.
Regards,
-JJ

Good point. A test based on Sandro's example has been committed to SVN.
Mike
Andrew Straw wrote:
> Michael Droettboom wrote:
> 
>> Yes -- a bug was introduced where non-finite values were no longer being 
>> ignored by the data extents finder. This has now been fixed on the 
>> 0.99.x branch (r7774) and the trunk.
>> 
>> 
> Hi Mike,
>
> This would seem like something useful to write a test for to make sure
> these regressions don't slip in in the future. Would it be easy to write
> a test (image based or non image based)? If so, would you mind doing it
> and checking it into the trunk? You can look at
> lib/matplotlib/tests/test_axes.py and lib/matplotlib/tests/test_basic.py
> for examples.
>
> Also, apologies about the buildbot master being down last night and this
> morning. It's back online now.
>
> -Andrew
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Yes -- a bug was introduced where non-finite values were no longer being 
> ignored by the data extents finder. This has now been fixed on the 
> 0.99.x branch (r7774) and the trunk.
> 
Hi Mike,
This would seem like something useful to write a test for to make sure
these regressions don't slip in in the future. Would it be easy to write
a test (image based or non image based)? If so, would you mind doing it
and checking it into the trunk? You can look at
lib/matplotlib/tests/test_axes.py and lib/matplotlib/tests/test_basic.py
for examples.
Also, apologies about the buildbot master being down last night and this
morning. It's back online now.
-Andrew

2009年9月17日 John Hunter <jd...@gm...>:
> On Thu, Sep 17, 2009 at 9:30 AM, Michael Droettboom <md...@st...> wrote:
>> Looks fine to me. We were offering to commit this to matplotlib, or
>> should I?
>
> You should let Fernando, so he can survive the annual purge of
> developers no longer committing :-)
Thanks :) I'll take care of it later then, I'll try to fix a warning
we're seeing as well because it lacks a setup.py.
Cheers,
f

Yes -- a bug was introduced where non-finite values were no longer being 
ignored by the data extents finder. This has now been fixed on the 
0.99.x branch (r7774) and the trunk.
Mike
Sandro Tosi wrote:
> Hello,
> with 0.99.{0, 1rc1} I have problem with this code:
>
> In [1]: import matplotlib.pyplot as plt
>
> In [2]: import numpy as np
>
> In [3]: x = np.arange(0., np.e, 0.01)
>
> In [4]: y = np.log(x)
>
> In [5]: print y[:2], y[-2:]
> [ -Inf -4.60517019] [ 0.99325177 0.99694863]
>
> In [6]: plt.plot(x, y);
>
> In [7]: plt.show()
>
> that generates the image attached, that's clearly wrong :)
>
> I works fine with 0.98.5.3, so there's something in the 0.99.* that broke.
>
> Regards,
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

On Thu, Sep 17, 2009 at 9:30 AM, Michael Droettboom <md...@st...> wrote:
> Looks fine to me. We were offering to commit this to matplotlib, or
> should I?
You should let Fernando, so he can survive the annual purge of
developers no longer committing :-)

Looks fine to me. We were offering to commit this to matplotlib, or 
should I?
Mike
Fernando Perez wrote:
> Howdy,
>
> this fixes the ipython console sphinx extension to mark up output
> prompts as well. Mind if I put it in?
>
> Thanks,
>
> f
>
> maqroll[sphinxext]> diff -u ipython_console_highlighting.py
> ~/research/papers/nitime/sphinxext/ipython_console_highlighting.py
> --- ipython_console_highlighting.py	2009年08月26日 00:03:06.000000000 -0700
> +++ /home/fperez/research/papers/nitime/sphinxext/ipython_console_highlighting.py	2009年09月11日
> 18:03:19.000000000 -0700
> @@ -77,8 +77,11 @@
> [(0, Generic.Prompt,
> continue_prompt.group())]))
> curcode += line[continue_prompt.end():]
> elif output_prompt is not None:
> + # Use the 'error' token for output. We should probably make
> + # our own token, but error is typicaly in a bright color like
> + # red, so it works fine for our Output prompts.
> insertions.append((len(curcode),
> - [(0, Generic.Output,
> output_prompt.group())]))
> + [(0, Generic.Error,
> output_prompt.group())]))
> curcode += line[output_prompt.end():]
> else:
> if curcode:
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> 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

Hello,
with 0.99.{0, 1rc1} I have problem with this code:
In [1]: import matplotlib.pyplot as plt
In [2]: import numpy as np
In [3]: x = np.arange(0., np.e, 0.01)
In [4]: y = np.log(x)
In [5]: print y[:2], y[-2:]
[ -Inf -4.60517019] [ 0.99325177 0.99694863]
In [6]: plt.plot(x, y);
In [7]: plt.show()
that generates the image attached, that's clearly wrong :)
I works fine with 0.98.5.3, so there's something in the 0.99.* that broke.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Howdy,
this fixes the ipython console sphinx extension to mark up output
prompts as well. Mind if I put it in?
Thanks,
f
maqroll[sphinxext]> diff -u ipython_console_highlighting.py
~/research/papers/nitime/sphinxext/ipython_console_highlighting.py
--- ipython_console_highlighting.py	2009年08月26日 00:03:06.000000000 -0700
+++ /home/fperez/research/papers/nitime/sphinxext/ipython_console_highlighting.py	2009年09月11日
18:03:19.000000000 -0700
@@ -77,8 +77,11 @@
 [(0, Generic.Prompt,
continue_prompt.group())]))
 curcode += line[continue_prompt.end():]
 elif output_prompt is not None:
+ # Use the 'error' token for output. We should probably make
+ # our own token, but error is typicaly in a bright color like
+ # red, so it works fine for our Output prompts.
 insertions.append((len(curcode),
- [(0, Generic.Output,
output_prompt.group())]))
+ [(0, Generic.Error,
output_prompt.group())]))
 curcode += line[output_prompt.end():]
 else:
 if curcode:

Hi,
The backend_base in the trunk now has the draw_text_as_path method
which draws the text using the textpath module. The draw_text and the
draw_tex method calls it by default. This will enable a primitive
support for text and tex for all the backend which implements
draw_path method. This should not affect the functionality of existing
backends. The draw_text_as_path in the backend_base is a very basic
implementation. It simply calls draw_path for rendering. A special
version of the draw_tex method for the svg backend is implemented,
which caches the glyph paths of characters to reduces the output size.
So, here are examples.
usetex w/ svg backend : http://dl.getdropbox.com/u/178748/mpl/tex_demo.svg
text with html5 canvas backend : http://dl.getdropbox.com/u/178748/mpl/test.html
Well, the quality of the rendered text is not best, but seems good
enough for me.
Regards,
-JJ

Hi Michael,
On Sat, Aug 29, 2009 at 9:45 AM, John Hunter <jd...@gm...> wrote:
> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...> wrote:
>> Here you go. If you can think of anything else to include, I'll work
>> on it. I think the next thing I'll add is something on embedding
>> images in the corners of plots. figimage is the way to do this,
>> right?
This is very nice, many thanks! If you are interested, I think that a
presentation on this would be very well received at the informal
scientific computing in python group that I coordinate at UC Berkeley:
https://cirl.berkeley.edu/view/Py4Science
I don't know how convenient it is for you to make the trip, but if
it's possible, we'd love to have you do a presentation on image
processing. Just let me know any time, it's best if you write
directly to my work address:
Fer...@be...
in case I miss a message on the mailing lists (I monitor that address
much more closely).
Cheers,
f

I was looking through this, and have a suggestion as well:
You have a line that reads
In[10]: plt.hist(lum_img)
This should probably be
plt.hist(lum_img.ravel(),bins=<some larger number>)
As it is right now, you are making a histogram of each line
individually, and my experience has been that this tends to cause
issues (memory and confusion-related) with relatively large images.
On Wed, Sep 2, 2009 at 6:42 AM, Michael Sarahan <mcs...@uc...> wrote:
> Great suggestions. I'll find time to work on them in the near future,
> hopefully.
>
> -Mike
>
> On Sat, Aug 29, 2009 at 6:06 PM, Gary Ruben<gr...@bi...> wrote:
>> Very nice addition Michael.
>>
>> I note that the plt.colormap() line must have gotten lost. It's referred to
>> but not there.
>> I'll add some ideas to John's list:
>>
>> * Demonstrate the imsave() command.
>> * Rather than show 50 lines or so of array data, just show a few lines, but
>> demonstrate what img.shape is before and after slicing out the B channel
>> with img[:,:,0]
>> * It may be worth mentioning explicitly that img[:,:,0] will give you the
>> blue channel for an RGB and an RGBA image.
>> * Demonstrate the "upper" and "lower" keywords where relevant.
>> * Add a pointer to the scipy.ndimage module
>> * Extend the examples with RGB and RGBA images.
>> * You might like to show how to recarrays and views on the individual colour
>> channels. There are examples in the mailing list archives or maybe on the
>> scipy website - I can't remember where.
>> * If you want to get more advanced, talk about higher bit depth images than
>> 8 bits per channel.
>> * If you want to get even more advanced, show how to change the UI to probe
>> the pixel value (I wish matplotlib did this by default).
>>
>> Gary R.
>>
>> John Hunter wrote:
>>>
>>> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...>
>>> wrote:
>>>>
>>>> Here you go. If you can think of anything else to include, I'll work
>>>> on it. I think the next thing I'll add is something on embedding
>>>> images in the corners of plots. figimage is the way to do this,
>>>> right?
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Sep 15, 2009 at 7:57 AM, Michael Droettboom <md...@st...> wrote:
> Yeah, I have the same "not quite right" feeling about it. What about
> putting the caption in an "option" such as:
>
> .. plot:: foo.py
>  :caption: This is my caption
>
> I don't know if the caption can have newlines in this mode, though. I will
> have to experiment.
Not possible, as far as I could tell. This was my first reflex and
all of my experiments ended losing the other lines, and I couldn't
find by searching the lists whether there was any way to do it. But I
admit I didn't go as far as asking on the docutils or sphinx lists.
> It's not possible now. The tricky part of this is that currently we don't
> keep the module around after it's done plotting. This is actually very much
> on purpose since keeping all that data around for all of the example plots
> in the matplotlib documentation would quickly consume a lot of memory.
> Perhaps when used in this mode (with a function argument) we could. Alas,
> again that's api-by-inputs :)
Well, even if the module isn't kept in memory, from an api perspective
I think it would still be useful to have this
.. plot:: script.py func
mode. It would make it easier to organize scripts for plot generation
in papers.
But don't worry too much about it. The real problem was having
figures with captions, and at least we have that done. Hopefully some
time in the future these extensions can be cleaned up a little bit
(the code is indeed a bit messy).
In the meantime, we have something very useful that we need *today*,
so I'm happy :)
Cheers,
f

Fernando Perez wrote:
> Hi Michael,
>
> On Mon, Sep 14, 2009 at 6:57 AM, Michael Droettboom <md...@st...> wrote:
> 
>> I'm not sure it's that bad. It's certainly possible to do all these things
>> with a single directive, since providing a path or providing source code is
>> mutually exclusive. The thing one can't do is provide inline source *and* a
>> caption. I applied your patch, renaming the directive back to "plot" and
>> ran it over the matplotlib docs, and it doesn't seem to break anything.
>> 
>
> Well, if you're OK with the api-by-inputs approach (name+text =
> caption, text only=code), then I have no qualms using it. It felt a
> bit hackish so I was perhaps overly cautious, but I'd much rather:
>
> - have this in upstream mpl than in my own projects
> - have a single directive to remember
>
> So many thanks for integrating it!
> 
Yeah, I have the same "not quite right" feeling about it. What about 
putting the caption in an "option" such as:
 .. plot:: foo.py
 :caption: This is my caption
I don't know if the caption can have newlines in this mode, though. I 
will have to experiment.
>> Of course, we can also provide two directives, "plot" and "figplot" based on
>> essentially the same source code. I'm kind of neutral on the matter.
>> 
>
> I'm pretty neutral too, though perhaps it might be worth thinking
> about this a little more, to get a really good long-term solution.
> 
> 2. An extended version of today's support for files, that can handle
> entry points:
>
> .. plot:: script.py func1
>
> Caption for figure 1
>
> .. plot:: script.py func2
>
> Caption for figure 2
>
> This would *import* script only once, and then for each figure it
> would call the given function (argumentless, to keep things simple for
> now). Basically each call would be the equivalent of
>
> import script; script.funcN() # N=1,2
>
> This would make it easy to compute expensive data in script once, and
> then render multiple plots out of it without re-executing the script
> in full each time.
>
> Or is this already possible with today's plot()?
> 
It's not possible now. The tricky part of this is that currently we 
don't keep the module around after it's done plotting. This is actually 
very much on purpose since keeping all that data around for all of the 
example plots in the matplotlib documentation would quickly consume a 
lot of memory. Perhaps when used in this mode (with a function 
argument) we could. Alas, again that's api-by-inputs :)
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Michael,
On Mon, Sep 14, 2009 at 6:57 AM, Michael Droettboom <md...@st...> wrote:
> I'm not sure it's that bad. It's certainly possible to do all these things
> with a single directive, since providing a path or providing source code is
> mutually exclusive. The thing one can't do is provide inline source *and* a
> caption. I applied your patch, renaming the directive back to "plot" and
> ran it over the matplotlib docs, and it doesn't seem to break anything.
Well, if you're OK with the api-by-inputs approach (name+text =
caption, text only=code), then I have no qualms using it. It felt a
bit hackish so I was perhaps overly cautious, but I'd much rather:
- have this in upstream mpl than in my own projects
- have a single directive to remember
So many thanks for integrating it!
> Of course, we can also provide two directives, "plot" and "figplot" based on
> essentially the same source code. I'm kind of neutral on the matter.
I'm pretty neutral too, though perhaps it might be worth thinking
about this a little more, to get a really good long-term solution.
Basically, what I'd like to have is a directive that can cover these
two scenarios:
1. Like today, plot with code:
.. plot::
 plot(x,y)
2. An extended version of today's support for files, that can handle
entry points:
.. plot:: script.py func1
 Caption for figure 1
.. plot:: script.py func2
 Caption for figure 2
This would *import* script only once, and then for each figure it
would call the given function (argumentless, to keep things simple for
now). Basically each call would be the equivalent of
import script; script.funcN() # N=1,2
This would make it easy to compute expensive data in script once, and
then render multiple plots out of it without re-executing the script
in full each time.
Or is this already possible with today's plot()?
I think this would cover all the use cases I have in mind, from years
of using a similar approach but with Makefiles.
Cheers,
f

Fernando Perez wrote:
> I renamed it because there's a bit of a conflict with the current
> 'plot' directive, which allows a filename *or* a content block, but in
> that case the content block is meant to be the source code, as
> illustrated in sampledoc:
>
> http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
>
> Since I'm not sure if we can find a clean solution to:
>
> - path to script: goes into arg list
> - inlined (multiline) code: goes into content block
> - inlined (possibly multiline) caption: goes into content block
> 
I'm not sure it's that bad. It's certainly possible to do all these 
things with a single directive, since providing a path or providing 
source code is mutually exclusive. The thing one can't do is provide 
inline source *and* a caption. I applied your patch, renaming the 
directive back to "plot" and ran it over the matplotlib docs, and it 
doesn't seem to break anything.
Of course, we can also provide two directives, "plot" and "figplot" 
based on essentially the same source code. I'm kind of neutral on the 
matter.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Fernando Perez wrote:
> I renamed it because there's a bit of a conflict with the current
> 'plot' directive, which allows a filename *or* a content block, but in
> that case the content block is meant to be the source code, as
> illustrated in sampledoc:
>
> http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
>
> Since I'm not sure if we can find a clean solution to:
>
> - path to script: goes into arg list
> - inlined (multiline) code: goes into content block
> - inlined (possibly multiline) caption: goes into content block
> 
I'm not sure it's that bad. It's certainly possible to do all these 
things with a single directive, since providing a path or providing 
source code is mutually exclusive. The thing one can't do is provide 
inline source *and* a caption. I applied your patch, renaming the 
directive back to "plot" and ran it over the matplotlib docs, and it 
doesn't seem to break anything.
Of course, we can also provide two directives, "plot" and "figplot" 
based on essentially the same source code. I'm kind of neutral on the 
matter.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Fernando and all,
>
> Speaking of sphinx for books, as I've mentioned before to John, the
> last big problem is being able to cross-reference arbitrary text
> elements like you can in latex, be they chapters or sections or
> whatever, and get a number or something that's meaningful in print.
>
> I looked around, and apparently it's on the main docutils todo list:
>
> http://docutils.sourceforge.net/docs/dev/todo.html#object-numbering-and-object-references
>
> I hope we don't have to be the ones fixing that one...
>
I should also mention bibliography - using a bibtex bibliography is
also still quite impossible at the moment, without going in and
editing the .tex and running the tex (latex=>bibtex=>latex=>latex)
commands on it yourself. Does anyone of the Sphinx mavens around here
know anything about how to get Sphinx to do that for you? I am
starting to believe that Sphinx can be made to do just about anything
we would want it to for these kinds of uses.
Cheers,
Ariel