Full rebuild in order

thanks Darren,
I just tried and it completed to a readable pdf files, though after a couple of error message of this type :
! Undefined control sequence.
<recently read> \Equiv
                      l.2379 \end{tabulary}
                    ? x

escaping with 'x' everythime lead to completion....
best,
Johann

Darren Dale wrote:

···

On Thursday 12 June 2008 08:08:41 am Michael Droettboom wrote:
  

It looks as if the docs can't be built if text.usetex is "True", first
because of needing Unicode (which also requires setting
text.latex.unicode to True), and second because the dollar_ticks.py demo
doesn't escape '$'.

I suppose we should hardcode text.usetex to "False" when building the
documentation figures. Better yet, it might be a good idea to provide a
"documentation-only" matplotlibrc (or use only the defaults) so that we
can always get consistent results when building the documentation.
    
I think an empty matplotlibrc file is the right way to go. I added it in svn.

That's my bad -- I added even more symbols to the symbol table without updating the preamble. I should have a fix shortly.

Cheers,
Mike

Johann Cohen-Tanugi wrote:

···

thanks Darren,
I just tried and it completed to a readable pdf files, though after a couple of error message of this type :
! Undefined control sequence.
<recently read> \Equiv
                     l.2379 \end{tabulary}
                   ? x

escaping with 'x' everythime lead to completion....
best,
Johann

Darren Dale wrote:

On Thursday 12 June 2008 08:08:41 am Michael Droettboom wrote:

It looks as if the docs can't be built if text.usetex is "True", first
because of needing Unicode (which also requires setting
text.latex.unicode to True), and second because the dollar_ticks.py demo
doesn't escape '$'.

I suppose we should hardcode text.usetex to "False" when building the
documentation figures. Better yet, it might be a good idea to provide a
"documentation-only" matplotlibrc (or use only the defaults) so that we
can always get consistent results when building the documentation.
    
I think an empty matplotlibrc file is the right way to go. I added it in svn.
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This may have been obvious to all of you,but I am just discovering it.
The problem is that *sphinx* is defining \Cap as a color, and this is
clashing with the ams name. From Matplotlib.tex::

    \newcommand\Car[1]{\textcolor[rgb]{0.73,0.38,0.84}{#1}}
    \newcommand\Caq[1]{\textcolor[rgb]{0.38,0.68,0.84}{#1}}
    \newcommand\Cap[1]{\textcolor[rgb]{0.78,0.36,0.04}{#1}}
    \newcommand\Caw[1]{\textcolor[rgb]{0.13,0.50,0.31}{#1}}

but I haven't yet found the file which is adding this. This looks
like a docutils/sphinx bug.

JDH
JDH

···

On Wed, Jun 11, 2008 at 4:00 PM, John Hunter <jdh2358@...149...> wrote:

! LaTeX Error: Command \Cap already defined.
              Or name \end... illegal, see p.192 of the manual.

Interestingly, sphinx *doesn't* define it for me. One of the first things I did was "grep Cap" on the latex build directory.

I updated sphinx from SVN pretty recently... I wonder if that has anything to do with it. If that doesn't fix it, yes, that sounds like something to report.

Cheers,
Mike

John Hunter wrote:

···

On Wed, Jun 11, 2008 at 4:00 PM, John Hunter <jdh2358@...149...> wrote:

! LaTeX Error: Command \Cap already defined.
              Or name \end... illegal, see p.192 of the manual.
    
This may have been obvious to all of you,but I am just discovering it.
The problem is that *sphinx* is defining \Cap as a color, and this is
clashing with the ams name. From Matplotlib.tex::

    \newcommand\Car[1]{\textcolor[rgb]{0.73,0.38,0.84}{#1}}
    \newcommand\Caq[1]{\textcolor[rgb]{0.38,0.68,0.84}{#1}}
    \newcommand\Cap[1]{\textcolor[rgb]{0.78,0.36,0.04}{#1}}
    \newcommand\Caw[1]{\textcolor[rgb]{0.13,0.50,0.31}{#1}}

but I haven't yet found the file which is adding this. This looks
like a docutils/sphinx bug.

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

Personnally I get:
build/latex/Matplotlib.tex:\\Cap \code{\textbackslash{}Cap}
but I have sphinx 0.3 which is the version easy_installed on my FC8 box. Actually I wonder how much trouble this 0.3 version is a promise of.....
Johann

Michael Droettboom wrote:

···

Interestingly, sphinx *doesn't* define it for me. One of the first things I did was "grep Cap" on the latex build directory.

I updated sphinx from SVN pretty recently... I wonder if that has anything to do with it. If that doesn't fix it, yes, that sounds like something to report.

Cheers,
Mike

John Hunter wrote:
  

On Wed, Jun 11, 2008 at 4:00 PM, John Hunter <jdh2358@...149...> wrote:

! LaTeX Error: Command \Cap already defined.
              Or name \end... illegal, see p.192 of the manual.
    

This may have been obvious to all of you,but I am just discovering it.
The problem is that *sphinx* is defining \Cap as a color, and this is
clashing with the ams name. From Matplotlib.tex::

    \newcommand\Car[1]{\textcolor[rgb]{0.73,0.38,0.84}{#1}}
    \newcommand\Caq[1]{\textcolor[rgb]{0.38,0.68,0.84}{#1}}
    \newcommand\Cap[1]{\textcolor[rgb]{0.78,0.36,0.04}{#1}}
    \newcommand\Caw[1]{\textcolor[rgb]{0.13,0.50,0.31}{#1}}

but I haven't yet found the file which is adding this. This looks
like a docutils/sphinx bug.

JDH
  

It appears to be Pygments (source code highlighter) that produces these lines. I have Pygments 0.10 which "works for me" (TM).

pygments/formatters/latex.py
158: cmndef = r'\textcolor[rgb]{%s}{%s}' % (

Cheers,
Mike

Michael Droettboom wrote:

···

Interestingly, sphinx *doesn't* define it for me. One of the first things I did was "grep Cap" on the latex build directory.
I updated sphinx from SVN pretty recently... I wonder if that has anything to do with it. If that doesn't fix it, yes, that sounds like something to report.

Cheers,
Mike

John Hunter wrote:

On Wed, Jun 11, 2008 at 4:00 PM, John Hunter <jdh2358@...149...> wrote:

! LaTeX Error: Command \Cap already defined.
              Or name \end... illegal, see p.192 of the manual.
    
This may have been obvious to all of you,but I am just discovering it.
The problem is that *sphinx* is defining \Cap as a color, and this is
clashing with the ams name. From Matplotlib.tex::

    \newcommand\Car[1]{\textcolor[rgb]{0.73,0.38,0.84}{#1}}
    \newcommand\Caq[1]{\textcolor[rgb]{0.38,0.68,0.84}{#1}}
    \newcommand\Cap[1]{\textcolor[rgb]{0.78,0.36,0.04}{#1}}
    \newcommand\Caw[1]{\textcolor[rgb]{0.13,0.50,0.31}{#1}}

but I haven't yet found the file which is adding this. This looks
like a docutils/sphinx bug.

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

The sphinx highlighting module uses
pygments.formatters.latex.LatexFormatter which cycles through letters
using a command prefix which defaults to 'C'

    def _create_stylecmds(self):
        t2c = self.ttype2cmd = {Token: ''}
        c2d = self.cmd2def = {}
        cp = self.commandprefix

        letters = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
        first = iter(letters)
        second = iter(letters)
        firstl = first.next()

In sphinx.highlighting, I can override this default with commandprefix='PYGC'
and get the build to work,

class PygmentsBridge(object):
    def __init__(self, dest='html', stylename='sphinx'):
        self.dest = dest
        if not pygments:
            return
        if stylename == 'sphinx':
            style = SphinxStyle
        elif '.' in stylename:
            module, stylename = stylename.rsplit('.', 1)
            style = getattr(__import__(module, None, None, ['']), stylename)
        else:
            style = get_style_by_name(stylename)
        self.hfmter = {False: HtmlFormatter(style=style),
                       True: HtmlFormatter(style=style, linenos=True)}
        self.lfmter = {False: LatexFormatter(style=style, commandprefix='PYGC'),
                       True: LatexFormatter(style=style, linenos=True,
commandprefix='PYGC')}

···

On Thu, Jun 12, 2008 at 9:25 AM, Michael Droettboom <mdroe@...31...> wrote:

Interestingly, sphinx *doesn't* define it for me. One of the first things I
did was "grep Cap" on the latex build directory.
I updated sphinx from SVN pretty recently... I wonder if that has anything
to do with it. If that doesn't fix it, yes, that sounds like something to
report.

Johann Cohen-Tanugi wrote:

Personnally I get:
build/latex/Matplotlib.tex:\\Cap \code{\textbackslash{}Cap}

That's a usage, not a definition. The problem is related to duplicate definitions of \Cap.

but I have sphinx 0.3 which is the version easy_installed on my FC8 box. Actually I wonder how much trouble this 0.3 version is a promise of.....

Eventually, we'll have to track down and document which versions of sphinx, docutils and pygments work to build the matplotlib documentation. There's a lot of moving parts here...

Cheers,
Mike

···

Johann

Michael Droettboom wrote:

Interestingly, sphinx *doesn't* define it for me. One of the first things I did was "grep Cap" on the latex build directory.
I updated sphinx from SVN pretty recently... I wonder if that has anything to do with it. If that doesn't fix it, yes, that sounds like something to report.

Cheers,
Mike

John Hunter wrote:

On Wed, Jun 11, 2008 at 4:00 PM, John Hunter <jdh2358@...149...> wrote:

! LaTeX Error: Command \Cap already defined.
              Or name \end... illegal, see p.192 of the manual.
          

This may have been obvious to all of you,but I am just discovering it.
The problem is that *sphinx* is defining \Cap as a color, and this is
clashing with the ams name. From Matplotlib.tex::

    \newcommand\Car[1]{\textcolor[rgb]{0.73,0.38,0.84}{#1}}
    \newcommand\Caq[1]{\textcolor[rgb]{0.38,0.68,0.84}{#1}}
    \newcommand\Cap[1]{\textcolor[rgb]{0.78,0.36,0.04}{#1}}
    \newcommand\Caw[1]{\textcolor[rgb]{0.13,0.50,0.31}{#1}}

but I haven't yet found the file which is adding this. This looks
like a docutils/sphinx bug.

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

Documenting is good, and I don't mind requiring updated versions of
everything, or even svn for now, to get the docs to build. I
consider these to be development/bleeding edge only, and don't want to
announce them to the user community until we have a reasonably
complete set of docs. But having a documented combination that works
in the dev guide would be useful.

···

On Thu, Jun 12, 2008 at 9:52 AM, Michael Droettboom <mdroe@...31...> wrote:

Eventually, we'll have to track down and document which versions of sphinx,
docutils and pygments work to build the matplotlib documentation. There's a
lot of moving parts here...

Now that we have this bug fixed, we don't need to consider any of
these alternatives. But not having correct bounding boxes for the PDF
mathtext expressions is a problem worth fixing. What is the status of
this: tried and impossible, tried but haven't figured it out, haven't
tried, etc? Jouni, is this something you could take another look at?

In a perfect world, we would have mathtext format our math using the
pdf backend for the mathtext expressions in the spirit of "what you
see is what you get", but I don't consider this to be a high priority
now that users can build some docs (html) w/o a latex install. Since
building PDF requires latex anyhow, using our own mathtext is only a
marginal benefit.

JDH

···

On Thu, Jun 12, 2008 at 7:47 AM, Michael Droettboom <mdroe@...31...> wrote:

Barring that, I suppose we'll have to a) drop the symbol table or b) use
mathtext to generate the math for LaTeX (there's something very patricidal
about that... ;). b) may be a little bit of work to do well, since we don't
currently have a way to get a nice tightly-bound PDF of a math expression,
and embedding PNGs will look bad.

right, I agree : I tried because I did not know for sure whether it would work or not, and because that was post-lunch time :slight_smile: .... Looks like bleeding edge sphinx is not required seemingly!
Johann

John Hunter wrote:

···

On Thu, Jun 12, 2008 at 9:52 AM, Michael Droettboom <mdroe@...31...> wrote:

Eventually, we'll have to track down and document which versions of sphinx,
docutils and pygments work to build the matplotlib documentation. There's a
lot of moving parts here...
    
Documenting is good, and I don't mind requiring updated versions of
everything, or even svn for now, to get the docs to build. I
consider these to be development/bleeding edge only, and don't want to
announce them to the user community until we have a reasonably
complete set of docs. But having a documented combination that works
in the dev guide would be useful.

John Hunter wrote:

Barring that, I suppose we'll have to a) drop the symbol table or b) use
mathtext to generate the math for LaTeX (there's something very patricidal
about that... ;). b) may be a little bit of work to do well, since we don't
currently have a way to get a nice tightly-bound PDF of a math expression,
and embedding PNGs will look bad.
    
Now that we have this bug fixed, we don't need to consider any of
these alternatives. But not having correct bounding boxes for the PDF
mathtext expressions is a problem worth fixing. What is the status of
this: tried and impossible, tried but haven't figured it out, haven't
tried, etc? Jouni, is this something you could take another look at?

I don't think this is a PDF problem necessarily. I only meant that there is no mathtext2pdf (equivalent to mathtext2png). It would need to render the math to determine its bounding box (doable now), and then create a new figure of the correct size to render to. Not difficult, but potentially finicky.

We still have the problem of a lack of baseline output from mathtext (but that exists regardless of backend).

In a perfect world, we would have mathtext format our math using the
pdf backend for the mathtext expressions in the spirit of "what you
see is what you get", but I don't consider this to be a high priority
now that users can build some docs (html) w/o a latex install. Since
building PDF requires latex anyhow, using our own mathtext is only a
marginal benefit.
  

Right -- that's how I see it, too. Plus having LaTeX render the math means that everything looks like it belongs (the right sizes, spacing etc.)

Cheers,
Mike

···

On Thu, Jun 12, 2008 at 7:47 AM, Michael Droettboom <mdroe@...31...> wrote:

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