future of mpl documentation

Development matplotlib-devel
41

Well, we definitely want our docs to build so we're happy to get the
feedback -- sometimes it's a simple matter of a dev forgetting to
commit a critical file. I am getting this error too. It appears to
be a bug in the pyplot docstrings -- Darren, perhaps you haven't
committed all you recent changes? But if I remove entirely the pyplot
api doc which is causing this problem, I get lots of other errors
along the lines of those shown below. Is this a latex or sphinxext
config error?

[8 <./pyplot_formatstr.png> <./pyplot_three.png>] [9] [10]
<pyplot_two_subplots.png, id=368, 578.16pt x 433.62pt>
<use pyplot_two_subplots.png> <use pyplot_two_subplots.png> [11 <./pyplot_two_s
ubplots.png>] <pyplot_text.png, id=375, 578.16pt x 433.62pt>
<use pyplot_text.png> <use pyplot_text.png> [12 <./pyplot_text.png>] [13]
[14]
Chapter 2.
[15] [16]
! Undefined control sequence.
<recently read> \mathbb

l.954 \end{tabulary}

?
! Undefined control sequence.
<recently read> \mathcircled

l.954 \end{tabulary}

...and lots more like this....

JDH

···

On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fperez.net@...149...> wrote:

I don't know if you are so in the middle of things that you'd rather
not get bug reports on this for a while. If that's the case I'll wait
until the dust settles a bit.

42

And I made several changes -- mainly to simplify the logo. My wife
thought it looked busy, and she has better taste than I do, so I
stripped it down a bunch and added the many small subplots as a
sidebar on the right. Let me know what you think and don't be shy
about being critical despite Darren's kind sensitivities. I don't
take pride in my graphic design abilities and so will happily make
changes

See http://matplotlib.sf.net for the new logo(s) and the attached for
the stripped down script.

JDH

logo2.png

···

On Mon, May 26, 2008 at 1:50 PM, Tony Yu <tsyu80@...149...> wrote:

I played around with the script, but in the process I ended up rewriting it
a bunch. I'm sure I've violated come coding guidelines along the way; my
apologies.

43

Well, I remember the last time quite clearly, when Perry sent me a
doughnut in the mail from Maryland to settle a "dollars-to doughnuts"
bet. Unfortunately, I can't remember the subject of the bet right
now (Perry?), though I kept the doughnut in my freezer, in the
addressed envelope, for many months as a souvenir.

JDH

···

On Sat, May 31, 2008 at 3:19 PM, Darren Dale <darren.dale@...143...> wrote:

  > I have to break here for the weekend, I'll be back monday afternoon.
  > Leave some for me! (although I'll owe doughnut to whoever can fix the
  > arrow docstring).

  > I'll claim that doughnut.

  > When was the last time you received one in the mail?

44

I think that following their guidelines is a good idea for the most
part, but we needn't adhere to them religiously. For one thing,
matplotlib uses *a lot* more keyword args than either numpy or scipy,
and what works for them for kwargs may not be best for us. In
particular, if we use the format they suggest, I'm afraid our
docstrings will simply take up too much space. For example, see
http://mentat.za.net/numpy/refguide/functions.xhtml#all-a-axis-none-out-none
. What if we formatted all the Line2d kwargs that way? It seems a
bit bloated in terms of vertical space for the number of kwargs we
need to handle, and so a ReST table may in fact be better.

We want our documentation to be mostly consistent to aid the folks
trying to put together bits and pieces of documentation from several
projects to write in-house docs (which incorporate local docs) or
books, but I'm not sure we need our doc formatting to be entirely
consistent at the API level.

JDH

···

On Sat, May 31, 2008 at 7:50 PM, Darren Dale <darren.dale@...143...> wrote:

I just realized, though, that I should probably be striving to conform with
the standard that the numpy and scipy folks put together:
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and
http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments? I
think I have been relying too heavily on tables for the keyword arguments.

45

> I don't know if you are so in the middle of things that you'd rather
> not get bug reports on this for a while. If that's the case I'll wait
> until the dust settles a bit.

Well, we definitely want our docs to build so we're happy to get the
feedback -- sometimes it's a simple matter of a dev forgetting to
commit a critical file. I am getting this error too. It appears to
be a bug in the pyplot docstrings -- Darren, perhaps you haven't
committed all you recent changes?

All my changes had already been committed. I had only been creating html
(./make.py html) and it looks like some of the tables I have been creating
dont agree with latex. I'll fix it tomorrow, but in the meantime, please just
make html.

But if I remove entirely the pyplot
api doc which is causing this problem, I get lots of other errors
along the lines of those shown below. Is this a latex or sphinxext
config error?

Not sure, I'll look into it on Sunday as well.

Cheers,
Darren

···

On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:

On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fperez.net@...149...> wrote:

46

And I made several changes -- mainly to simplify the logo. My wife
thought it looked busy, and she has better taste than I do, so I
stripped it down a bunch and added the many small subplots as a
sidebar on the right.

I agree, the stripped down logo looks much better.

Let me know what you think and don't be shy
about being critical despite Darren's kind sensitivities. I don't
take pride in my graphic design abilities and so will happily make
changes

See http://matplotlib.sf.net for the new logo(s) and the attached for
the stripped down script.

I like the new color scheme on the website. Since you asked for criticism, though, I'm not a fan of the blue "matplotlib" in the logo (on the website, the attached logo is actually different). I think black or a dark gray looks better (color=[0.2, 0.2, 0.2]). Or, if you prefer blue, something less like the default hyperlink color (e.g. color=[.1,.1,.5]). My 2 cents.

BTW, I noticed that website is a little old (pure HTML, no CSS). If you're ever interested in redesigning the website (nothing fancy, mainly just moving to CSS), I'd be happy to help out.

-Tony

···

On May 31, 2008, at 10:30 PM, John Hunter wrote:

JDH
<logo2.png>

47

I like the new color scheme on the website. Since you asked for criticism,
though, I'm not a fan of the blue "matplotlib" in the logo (on the website,
the attached logo is actually different). I think black or a dark gray looks
better (color=[0.2, 0.2, 0.2]). Or, if you prefer blue, something less like
the default hyperlink color (e.g. color=[.1,.1,.5]). My 2 cents.

I agree -- I had already reverted to black (hit refresh). But if you
think some other shade of dark gray or blue/gray is better let me
know.

BTW, I noticed that website is a little old (pure HTML, no CSS). If you're
ever interested in redesigning the website (nothing fancy, mainly just
moving to CSS), I'd be happy to help out.

We're definitely interested. Try checking out the htdocs svn
repository. Admittedly we do things in our own special way (eg the
YAPTU template engine), but if we could improve the look-and-feel that
would be great. None of us have any special powers in the
website-design department. Even better, as part of our new trunk
documentation effort, we have moved to a sphinx based documentation
system (in the doc subdir of svn trunk). If you could figure out a
way to hook custom CSSandr mpl figures/screenshots or any other snazzy
features into the base sphinx build system, that would be a big help
since we hope to jettison the somewhat anachronistic website build
system n the not-too-distant-future.

JDH

···

On Sat, May 31, 2008 at 11:27 PM, Tony Yu <tsyu80@...149...> wrote:

48

> I like the new color scheme on the website. Since you asked for
> criticism, though, I'm not a fan of the blue "matplotlib" in the logo (on
> the website, the attached logo is actually different). I think black or a
> dark gray looks better (color=[0.2, 0.2, 0.2]). Or, if you prefer blue,
> something less like the default hyperlink color (e.g. color=[.1,.1,.5]).
> My 2 cents.

I agree -- I had already reverted to black (hit refresh). But if you
think some other shade of dark gray or blue/gray is better let me
know.

Speaking as a recovering graphical design major and insensitive curmudgeon...
it looks great, nice work!

I do have two comments though: the 90 and 270 ticklabels are cut off, and I
think the plot would look a little cleaner if the ticklabel pad were
increased so the radial ticks were a little further from the axes.

> BTW, I noticed that website is a little old (pure HTML, no CSS). If
> you're ever interested in redesigning the website (nothing fancy, mainly
> just moving to CSS), I'd be happy to help out.

We're definitely interested. Try checking out the htdocs svn
repository. Admittedly we do things in our own special way (eg the
YAPTU template engine), but if we could improve the look-and-feel that
would be great. None of us have any special powers in the
website-design department. Even better, as part of our new trunk
documentation effort, we have moved to a sphinx based documentation
system (in the doc subdir of svn trunk). If you could figure out a
way to hook custom CSSandr mpl figures/screenshots or any other snazzy
features into the base sphinx build system, that would be a big help
since we hope to jettison the somewhat anachronistic website build
system n the not-too-distant-future.

I was intending to write the list and ask if anyone was interested in playing
with CSS to customize the looks of the new sphinx-based documentation effort.
I'm really happy to hear that you're interested in helping out, Tony.

I second Johns suggestion of having a look at the doc/ directory in the trunk,
and getting familiar with sphinx. I think most of the content on the website
is going to find a new home in the sphinx-based docs, and it would be nice if
the front page, sidebars, etc could also be generated with sphinx.

For the moment, you can build the html documentation by running "make.py html"
in the doc directory. The latex->pdf docs are experiencing growing pains,
I'll work on it this morning.

Darren

···

On Sunday 01 June 2008 12:53:48 am John Hunter wrote:

On Sat, May 31, 2008 at 11:27 PM, Tony Yu <tsyu80@...149...> wrote:

49

> > I don't know if you are so in the middle of things that you'd rather
> > not get bug reports on this for a while. If that's the case I'll wait
> > until the dust settles a bit.
>
> Well, we definitely want our docs to build so we're happy to get the
> feedback -- sometimes it's a simple matter of a dev forgetting to
> commit a critical file. I am getting this error too. It appears to
> be a bug in the pyplot docstrings -- Darren, perhaps you haven't
> committed all you recent changes?

All my changes had already been committed. I had only been creating html
(./make.py html) and it looks like some of the tables I have been creating
dont agree with latex. I'll fix it tomorrow, but in the meantime, please
just make html.

Alright, I've tracked down the source of these two errors. Sphinx can not
create tables in latex that have cells spanning multiple rows or multiple
columns. Maybe it is a limitation of latex, I'm not sure, I don't have my
latex books handy. But it looks like tables with row- or column-spanning
cells are henceforth verboten.

I've updated pyplot_api.rst in svn so it is basically empty and will not cause
anyone trouble while I fix the broken tables.

> But if I remove entirely the pyplot
> api doc which is causing this problem, I get lots of other errors
> along the lines of those shown below. Is this a latex or sphinxext
> config error?
>
> [8 <./pyplot_formatstr.png> <./pyplot_three.png>] [9] [10]
> <pyplot_two_subplots.png, id=368, 578.16pt x 433.62pt>
> <use pyplot_two_subplots.png> <use pyplot_two_subplots.png> [11
> <./pyplot_two_s ubplots.png>] <pyplot_text.png, id=375, 578.16pt x
> 433.62pt>
> <use pyplot_text.png> <use pyplot_text.png> [12 <./pyplot_text.png>] [13]
> [14]
> Chapter 2.
> [15] [16]
> ! Undefined control sequence.
> <recently read> \mathbb
>
> l.954 \end{tabulary}

I tracked this down by checking the contents of the generated
build/latex/Matplotlib.tex, line 954. It is from the following code from
mathtext.rst:

When using the STIX fonts, you also have the choice of:

    ================ =================================
    Command Result
    ================ =================================
    ``\mathbb`` :math:`\mathbb{Blackboard}`
    ``\mathcircled`` :math:`\mathcircled{Circled}`
    ``\mathfrak`` :math:`\mathfrak{Fraktur}`
    ``\mathsf`` :math:`\mathsf{sans-serif}`
    ================ =================================

I'm not sure this is being properly rendered in the HTML output for me,
either. Mike, are you able to compile this into a pdf on your machine, and if
so, would you tell us how to configure STIX support? I commented this block
out in svn for now.

Cheers,
Darren

···

On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:

On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fperez.net@...149...> > > wrote:

50

> I just realized, though, that I should probably be striving to conform
> with the standard that the numpy and scipy folks put together:
> http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and
> http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments?
> I think I have been relying too heavily on tables for the keyword
> arguments.

I think that following their guidelines is a good idea for the most
part, but we needn't adhere to them religiously. For one thing,
matplotlib uses *a lot* more keyword args than either numpy or scipy,
and what works for them for kwargs may not be best for us. In
particular, if we use the format they suggest, I'm afraid our
docstrings will simply take up too much space. For example, see
http://mentat.za.net/numpy/refguide/functions.xhtml#all-a-axis-none-out-non
e . What if we formatted all the Line2d kwargs that way? It seems a bit
bloated in terms of vertical space for the number of kwargs we need to
handle, and so a ReST table may in fact be better.

I agree. We should default to parameter lists, but longer lists of kwargs will
be formatted as tables.

There are also some features in the numpy template (like the use of sections)
that cause sphinx to fail. I wonder how the webpage you referenced was
generated?

We want our documentation to be mostly consistent to aid the folks
trying to put together bits and pieces of documentation from several
projects to write in-house docs (which incorporate local docs) or
books, but I'm not sure we need our doc formatting to be entirely
consistent at the API level.

Right, we shouldn't worry about rigorously adhering to a standard, but their
template seems like a good guideline to keep in mind.

···

On Saturday 31 May 2008 10:45:34 pm John Hunter wrote:

On Sat, May 31, 2008 at 7:50 PM, Darren Dale <darren.dale@...143...> wrote:

51

Generally, I like the logo, and think it is a *huge* improvement on the old one.

Two suggestions:

1. The original new logo was done in a Helvetica medium font, which is much nicer for this type of logo. (See the Helvetica movie, and become a true believer...).

2. I like the figure to the side (and agree that there should be only one), but it seems that polar plots are more rarely used than normal x-y plots. Perhaps an x-y plot (the histogram, for example) would be better advertising.

-Rob

···

On Jun 1, 2008, at 4:30 AM, John Hunter wrote:

Let me know what you think...

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

52

We're definitely interested. Try checking out the htdocs svn
repository.

Hmm, the README file says I need all the backends working. I don't think I want to try that on my Mac. I'll try it out with a linux machine I have in lab.

Admittedly we do things in our own special way (eg the
YAPTU template engine), but if we could improve the look-and-feel that
would be great. None of us have any special powers in the
website-design department. Even better, as part of our new trunk
documentation effort, we have moved to a sphinx based documentation
system (in the doc subdir of svn trunk). If you could figure out a
way to hook custom CSSandr mpl figures/screenshots or any other snazzy
features into the base sphinx build system, that would be a big help
since we hope to jettison the somewhat anachronistic website build
system n the not-too-distant-future.

I was intending to write the list and ask if anyone was interested in playing
with CSS to customize the looks of the new sphinx-based documentation effort.
I'm really happy to hear that you're interested in helping out, Tony.

Actually, I really like the default look of sphinx-based docs, but I wouldn't mind playing around with it. What did you have in mind?

For the moment, you can build the html documentation by running "make.py html"
in the doc directory. The latex->pdf docs are experiencing growing pains,
I'll work on it this morning.

html built fine on my machine; it looks really nice. The pdf docs also built without problems. Nice work.

-Tony

···

On Jun 1, 2008, at 6:00 AM, Darren Dale wrote:

On Sunday 01 June 2008 12:53:48 am John Hunter wrote:

53

> I was intending to write the list and ask if anyone was interested
> in playing
> with CSS to customize the looks of the new sphinx-based
> documentation effort.
> I'm really happy to hear that you're interested in helping out, Tony.

Actually, I really like the default look of sphinx-based docs, but I
wouldn't mind playing around with it. What did you have in mind?

Our front page has various sidebars that include announcements, links to the
sourceforge download page, etc. I like the default look of sphinx-based html
as well, but I also like the look of the moin-based scipy page.

> For the moment, you can build the html documentation by running
> "make.py html"
> in the doc directory. The latex->pdf docs are experiencing growing
> pains,
> I'll work on it this morning.

html built fine on my machine; it looks really nice. The pdf docs also
built without problems. Nice work.

Yes, pdf is working again, I sorted out the issues that John and Fernando
reported last night.

Darren

···

On Sunday 01 June 2008 10:23:47 am Tony Yu wrote:

On Jun 1, 2008, at 6:00 AM, Darren Dale wrote:

54

I'm not sure either, it was something simple like having problems building and John suggesting that I blow away the previous installation. But I indeed did eventually mail the doughnut.

Perry

···

On May 31, 2008, at 10:35 PM, John Hunter wrote:

On Sat, May 31, 2008 at 3:19 PM, Darren Dale > <darren.dale@...143...> wrote:

  > I have to break here for the weekend, I'll be back monday afternoon.
  > Leave some for me! (although I'll owe doughnut to whoever can fix the
  > arrow docstring).

  > I'll claim that doughnut.

  > When was the last time you received one in the mail?

Well, I remember the last time quite clearly, when Perry sent me a
doughnut in the mail from Maryland to settle a "dollars-to doughnuts"
bet. Unfortunately, I can't remember the subject of the bet right
now (Perry?), though I kept the doughnut in my freezer, in the
addressed envelope, for many months as a souvenir.

JDH

55

I was the one who originally chose the polar plot. I admit, it was mainly for aesthetics. Here are a few reasons:

* I think a circular plot works better on the logo than a rectangular plot would.
* The polar plot is one of the more attractive plots in the examples.
* It's a plotting featuring that most plotting software wouldn't have so it seems to differentiate matplotlib from other plotting software.

Originally, it wasn't a big deal because there were other plots in the logo. Still, I'd be in favor of keeping the polar plot for aesthetic reasons.

Great, now I'm that guy who's arguing for looks over practicality. :frowning:

-Tony

···

On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote:

2. I like the figure to the side (and agree that there should be only one), but it seems that polar plots are more rarely used than normal x-y plots. Perhaps an x-y plot (the histogram, for example) would be better advertising.

56

Darren Dale wrote:

  

On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fperez.net@...149...>
      

I tracked this down by checking the contents of the generated build/latex/Matplotlib.tex, line 954. It is from the following code from mathtext.rst:

When using the STIX fonts, you also have the choice of:

    ================ =================================
    Command Result
    ================ =================================
    ``\mathbb`` :math:`\mathbb{Blackboard}`
    ``\mathcircled`` :math:`\mathcircled{Circled}`
    ``\mathfrak`` :math:`\mathfrak{Fraktur}`
    ``\mathsf`` :math:`\mathsf{sans-serif}`
    ================ =================================
    
I'm not sure this is being properly rendered in the HTML output for me, either. Mike, are you able to compile this into a pdf on your machine, and if so, would you tell us how to configure STIX support? I commented this block out in svn for now.
  

Sorry about that. It requires the amssymb and/or amsmath LaTeX packages to render correctly. Perhaps it is better to not require the LaTeX installation to have anything special though. I think the best course of action is to just include pre-generated images in the documentation source for this. I'll go ahead and do that.

Cheers,
Mike

···

On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:

On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

57

John Hunter wrote:

  

I'll be working on converting docstrings to rest this weekend. Should any of
this be done on the branch? Or should we just focus on the trunk?
    
As far as I am concerned, the documentation effort is for the trunk.
The only reason to do them on the branch too is to make merges of
other code changes easier, which may be a compelling reason. If the
docstrings get far out of whack, it may make merging other changes
very painful. But at the same time, I don't want the burden of
trying to keep the two in sync stopping you from getting the work done
that you need to do. Maybe you can try it and see how hard it is, and
if proves to be too much of an impediment, just concentrate on the
trunk. Michael, any advice here?
  

I was away on the weekend, so just getting back. Darren: you rock. The documentation is looking great!

I agree with John -- I think the documentation effort should be focused on the trunk. Now that we have (apparently) such a stable 0.91.3, hopefully the maintenance branch will be much less frequently modified anyway. Theoretically, we should only run into merge conflicts related to docstrings if the docstrings on the maintenance branch are themselves edited. If we're just going to be doing bugfixes on the branch, that seems unlikely.

Cheers,
Mike

···

On Sat, May 31, 2008 at 9:19 AM, Darren Dale <darren.dale@...143...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

58

Up to know, we've been adding features and bugs on the branch and then
merging them in. Going forward, I think we should just focus on
bug-fixes on the branch and mostly implement a feature-freeze, which
will promote stability and encourage people who want the new stuff
onto the trunk. We don't have to be fanatical about this -- if there
is a great feature we can put in w/o compromising stability, that's
fine, but I think our default should be bug-fixes only.

JDH

···

On Mon, Jun 2, 2008 at 8:12 AM, Michael Droettboom <mdroe@...31...> wrote:

I agree with John -- I think the documentation effort should be focused on
the trunk. Now that we have (apparently) such a stable 0.91.3, hopefully
the maintenance branch will be much less frequently modified anyway.
Theoretically, we should only run into merge conflicts related to
docstrings if the docstrings on the maintenance branch are themselves
edited. If we're just going to be doing bugfixes on the branch, that seems
unlikely.

59

Hi all

I only read this thread today, and see that we have been battling many
of the same challenges in our documentation efforts. I am glad to see
that you are making such good progress!

2008/6/1 John Hunter <jdh2358@...149...>:

I just realized, though, that I should probably be striving to conform with
the standard that the numpy and scipy folks put together:
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines and
http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py . Any comments? I
think I have been relying too heavily on tables for the keyword arguments.

I think that following their guidelines is a good idea for the most
part, but we needn't adhere to them religiously. For one thing,
matplotlib uses *a lot* more keyword args than either numpy or scipy,
and what works for them for kwargs may not be best for us. In
particular, if we use the format they suggest, I'm afraid our
docstrings will simply take up too much space. For example, see
http://mentat.za.net/numpy/refguide/functions.xhtml#all-a-axis-none-out-none
. What if we formatted all the Line2d kwargs that way? It seems a
bit bloated in terms of vertical space for the number of kwargs we
need to handle, and so a ReST table may in fact be better.

I'd like to explain the rationale behind our approach. Our main focus
was to write produce documentation that is easy to read from a
text-based terminal. While designing our standard, we set aside all
other concerns, such as markup, compatibility with existing tools,
etc. After the standard was more-or-less finalised, we wrote a tool
which parses docstrings into logical units. For example,

In [5]: d = SphinxFunctionDoc(np.ravel)

In [6]: d['Parameters']
Out[6]:
[('a', '{array_like}', ['']),
('order',
  "{'C','F'}, optional",
  ["If order is 'C' the elements are taken in row major order. If order",
   "is 'F' they are taken in column major order."])]

In [7]: print d
**ravel(a, order='C')**

···

-----------------------

Return a 1d array containing the elements of a (copy only if needed).

[...]

Note that, when printing the docstring, it looks entirely different
from the original docstring, and contains customised markup. If you
wanted to use a table to describe keyword arguments, for example, it
would require only a few extra lines of code.

If you are interested in playing with the code, it is available at

https://code.launchpad.net/~stefanv/scipy/numpy-refguide

We also developed a web-framework that allows our community to write
documentation:

http://sd-2116.dedibox.fr/pydocweb

While it was written with NumPy in mind (we have some weird docstring
injection, not unlike yours), it should be trivial to modify for use
by another project.

Good luck!

Stéfan

60

I added doc/static_figs to hold scripts that require optional dependencies to
generate images for the docs. I would like to be able to keep track of how the
images are generated, so if we lose one we know how to recreate it. I added
two scripts (softlinks actually) a README and a make.py to that directory.
make.py saves the images to doc/_static.

···

On Monday 02 June 2008 08:33:55 Michael Droettboom wrote:

Darren Dale wrote:
> On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
>> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
>>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <fperez.net@...149...>
>
> I tracked this down by checking the contents of the generated
> build/latex/Matplotlib.tex, line 954. It is from the following code from
>
> mathtext.rst:
>> When using the STIX fonts, you also have the choice of:
>>
>> ================ =================================
>> Command Result
>> ================ =================================
>> ``\mathbb`` :math:`\mathbb{Blackboard}`
>> ``\mathcircled`` :math:`\mathcircled{Circled}`
>> ``\mathfrak`` :math:`\mathfrak{Fraktur}`
>> ``\mathsf`` :math:`\mathsf{sans-serif}`
>> ================ =================================
>
> I'm not sure this is being properly rendered in the HTML output for me,
> either. Mike, are you able to compile this into a pdf on your machine,
> and if so, would you tell us how to configure STIX support? I commented
> this block out in svn for now.

Sorry about that. It requires the amssymb and/or amsmath LaTeX packages
to render correctly. Perhaps it is better to not require the LaTeX
installation to have anything special though. I think the best course
of action is to just include pre-generated images in the documentation
source for this. I'll go ahead and do that.