docutils-develop — For developer discussions of the implementation.

[Docutils-develop] Minimal writer?

[Bill B. <bb...@co...>]

Is there a minimal writer example available?

I want to write a minimal HTML writer that can produce non-stylesheet 
documents that are conformant to the O'Reilly devcenter article 
specification.

This seems like a *really* easy writer to create and would make a very 
good example of how to write a minimal, relatively stupid, writer.   I 
just have no freakin' clue how to get the basic writer up and running 
in a fashion to get to this point.  The jump from pseudoxml to 
html2css1 is to large for me to efficiently figure out where I fall in 
between.

Specifically, the requirements are as follows.

---
- comply with XHTML;  <br/> for break, close all tags, lower case, 
etc...

<h2></h2>:  Headline
<h3></h3>:  Subheading
ul, li, ol: for unordered and ordered lists
<p></p>: for all paragraphs

Standard <a..> and <img..> for all hyperlinking and images, 
respectively.

<pre> and <code> are used for examples and code.   CODE should be 50 
characters wide or less.   Images no larger than 450 pixels wide.
---

Obviously, if such a writer were to exist, a bunch of free publicity in 
the form of an O'Reilly article discussing authoring O'Reilly articles 
using DocUtils is a possibility... :-)

thanks,
b.bum

[Docutils-develop] Installing commands

[<bb...@ma...>]

On Friday, Dec 20, 2002, at 15:19 US/Eastern, 
doc...@li... wrote:
... thoughts on doing a cvs style CLI deleted ...
> It gets tricky when you want to specify the input format and/or
> context as well.  One way is to use options::
>
>     docutils html --reader pep ...

I like this and was going to suggest it when I had a moment to breath 
again.

I have done many, many, many command line tools that use a user 
interface of this nature.  Total win-- easy to develop, easy to use, 
easy to extend, and-- in the case of python-- makes it trivial to embed 
the program (just construct an array of args and call the appropriate 
main() directly with something other than sys.argv as the arglist).

The above situation is not that tricker, if done right.  First, 
consider the basic CLI format:

python <python options> docutils <docutils global options> command 
<command specific options>

Now, in the above case, you have a command specific option that can 
also have options.  In this case, I suggest following the pattern of 
the 'mount' command.  That is:

--reader pep,--option1,--option2=1234,--option3,-d,-v --writer 
html,--foo,--bar=1234

And, of course, if you need spaces in that string, just stick quotes 
around it.  Commas are a problem...

I have done this in the past.  It isn't exactly pretty, but this 
complex of a CLI has to make a sacrifice somewhere.  Most importantly, 
it works and scales easily.  Just split the argument to --reader on 
',', yank the first arg to find the reader module, and pass the rest as 
an array of args....

b.bum

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Thu, 19 Dec 2002, David Goodger wrote:

> > tables are an itch and used far to often
>
> Not following you here.
>
> > the configuration files entries might be done by a description
> > environment as the option-list, but this might need another markup,
> > if we donot use field-lists.
>
> That's just avoiding the real issue.  If there's a bug in table

i agree on that a bug needs a fix, but an argument is an argument
and just because in html historically tables where the means to
place items on the page does not mean everything is a table.

cheers
-- 
 BINGO: empower strategic product evolution
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] Re: [ docutils-Feature Requests-654826 ] install command line tools via setup.py

[David G. <go...@py...>]

David Abrahams wrote:
> As a mostly-outsider, my only comment is that the plethora of very
> similar-sounding tools is confusing.  Is there anything to the idea
> of unifying html.py, pep2html.py, pep.py, and maybe even builhtml.py
> with some kind of command-line option to select behaviors?

A CVS-style command with subcommands could be constructed.  For
example::

    docutils html input.txt output.html
    docutils latex ...

It gets tricky when you want to specify the input format and/or
context as well.  One way is to use options::

    docutils html --reader pep ...

Then the order of options becomes important.  You have to specify
"--reader xyz" before you can specify an xyz-reader-specific option.
See <http://docutils.sf.net/spec/notes.html#front-end-tools> for more
thoughts on "partially qualified" and "unqualified" front ends.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[David G. <go...@py...>]

[David Goodger]
>> 2. Near the end of the table, there's a cell that spans both
>>    columns.  It doesn't have any border in the PDF file.  It
>>    should.  In this particular case it looks OK (it's a
>>    pseudo-title), but it's >> still wrong.

[Engelbert Gruber]
> in the html version there is no border at all. is this because the
> table was without vertical lines or because of me.

Are you referring to the markup in the source file being a simple
table, without "|" characters between columns?  That doesn't get
stored in the doctree, and doesn't influence the output.  A grid table
produces the exact same doctree as an equivalent simple table.

I suspect it may be a browser/stylesheet issue.  In Mozilla and IE I
see the table with full borders and row/column separators.

> should i make no border too.

There should be a border by default.

> tables are an itch and used far to often

Not following you here.

> the configuration files entries might be done by a description
> environment as the option-list, but this might need another markup,
> if we donot use field-lists.

That's just avoiding the real issue.  If there's a bug in table
processing, you can't say "use feature X instead", unless tables (or
some aspect of tables) are not supported at all, in which case the
docs and help (and even the code) should say so explicitly.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Thu, 19 Dec 2002, Richard Jones wrote:

> On Thu, 19 Dec 2002 6:06 pm, gr...@us... wrote:
> > On Wed, 18 Dec 2002, Richard Jones wrote:
> > > 2. I'd like to be able to turn off the table of contents - it's not much
> > > use in most (if not all) of the pdfs generated for the Roundup
> > > documentation.
> >
> > you mean a switch --suppress-latex-toc ?
>
> That sounds good to me. Are you intending to provide page numbers in the LaTeX
> TOC at some stage?

in the one you do want to switch off with the above command ?-)

i will place it in the todo, but somehow this could make for another switch
--use-latex-toc. i did use it for test.txt because there are two tocs
the test.txt toc and a toc of a sample document.

where should the options go:
commandline, conf file, rst document ?

cheers

-- 
 BINGO: Testing! Testing! Testing! Testing! This is your nine o'clock alarm call!
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] latex writer

[Richard J. <rj...@ek...>]

On Thu, 19 Dec 2002 6:06 pm, gr...@us... wrote:
> On Wed, 18 Dec 2002, Richard Jones wrote:
> > 2. I'd like to be able to turn off the table of contents - it's not much
> > use in most (if not all) of the pdfs generated for the Roundup
> > documentation.
>
> you mean a switch --suppress-latex-toc ?

That sounds good to me. Are you intending to provide page numbers in the LaTeX 
TOC at some stage?


    Richard

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Wed, 18 Dec 2002, Richard Jones wrote:

> I agree - great stuff. I've just run latex.py over the Roundup documentation -
> and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I
> can't run it over the cusomtizing.txt file because of the number of heading
> levels - it ends up generating a \subsubsubsection which there's no handler
> for.

i limited too subsubsection.

from latex documentation, next headings should be paragraph and subparagraph
but it did not work here, the heading looks the same as the following
paragraph (obviously).

section numbering is done by docutils, so this should work, but we might
limit it sometime to avoid section 1.3.2.4.3.5 ...

pdfbookmark are only four levels. (more might be possible, there is something
lurking in my head that i read ... but i think this should do).

> My other random comments:
>
> 1. There seems to be a missing line break in definition lists after the term,
>    possibly only when the definition is a list - for an example, see
>      http://roundup.sf.net/doc-0.5/features.pdf
>
> 2. I'd like to be able to turn off the table of contents - it's not much use
>    in most (if not all) of the pdfs generated for the Roundup documentation.

you mean a switch --suppress-latex-toc ?


-- 
 BINGO: Das lassen wir aussen vor
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Tue, 17 Dec 2002, David Goodger wrote:

> [David Goodger]
> >> 1. There's no vertical space between paragraphs in table cells.
>
> [Richard Jones]
> > I'm not sure I have a problem with this. I think it looks OK as it is...
>
> In this particular case, one paragraph or two doesn't matter much.  But in
> the general case of table cells containing multiple paragraphs (or other
> objects, like lists etc.), there has to be some indication of separation.
> If now way can be found for TeX tables to handle multiple paragraphs, it's a
> documentation issue (at least until a way *is* found).  But I have to
> believe that TeX can handle just about anything.

yes of course but not everything can be fetched from the rst.

but i think the paragraph separation should work.
currently i have turned off first line intendation and use paragraph separation
seams to fail inside longtable.

tables are an itch and used far to often the configuration files entries might
be done by a description environment as the option-list, but this might need
another markup, if we donot use field-lists.

e.g.::

     _destination --  Path to output destination, set from positional
                      arguments.

                      Default: stdout (None).  No command-line
                      options.

     _source   --     Path to input source, set from positional
                      arguments.

                      Default: stdin (None).  No command-line options.

would be easier to type (in fact we could still make it a table

as a field list (are not set correct up to now IMHO)::

     :_destination:   Path to output destination, set from positional
                      arguments.

                      Default: stdout (None).  No command-line
                      options.

     :_source:        Path to input source, set from positional
                      arguments.

                      Default: stdin (None).  No command-line options.

cheers

-- 
 BINGO: Einpflegen
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Tue, 17 Dec 2002, David Goodger wrote:

> gr...@us... wrote:
> > the generated pdf:
> > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf
>
> Looking good!  There are two things I notice though:
>
> 1. There's no vertical space between paragraphs in table cells.

still itching.

> 2. Near the end of the table, there's a cell that spans both columns.
>    It doesn't have any border in the PDF file.  It should.  In this
>    particular case it looks OK (it's a pseudo-title), but it's still
>    wrong.

in the html version there is no border at all. is this because the
table was without vertical lines or because of me.
should i make no border too.

> > anyway due to limited interest in the public, i will proceed at my
> > pace.
>
> Of course, by all means.  It's all about scratching your *own* itch,
> after all!

-- 
 BINGO:
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] Python Reader module parser now usable

[Richard J. <rj...@ek...>]

On Thu, 19 Dec 2002 3:44 pm, David Goodger wrote:
> Richard Jones wrote:
> >>> I've found a module it breaks on ;)
> >>>
> >>> I'm looking into why right now...
> >
> > But at the moment the rhs evaluation gets mighty confused when it hits
> > that second '='.
>
> Some naive logic in the TokenParser.  Fixed now.

Yep, all better now :)

The structure output looks mighty promising - great job!


   Richard

Re: [Docutils-develop] Python Reader module parser now usable

[David G. <go...@py...>]

Richard Jones wrote:
>>> I've found a module it breaks on ;)
>>> 
>>> I'm looking into why right now...
> 
> But at the moment the rhs evaluation gets mighty confused when it hits that
> second '='.

Some naive logic in the TokenParser.  Fixed now.  Thanks for making this bug
shallow!  

-- David Goodger    go...@py...

Re: [Docutils-develop] Python Reader module parser now usable

[Richard J. <rj...@ek...>]

On Thu, 19 Dec 2002 2:10 pm, Richard Jones wrote:
> On Thu, 19 Dec 2002 1:59 pm, Richard Jones wrote:
> > On Thu, 19 Dec 2002 12:17 pm, David Goodger wrote:
> > > I've also added a "showdoc" script to test/test_readers/test_python
> > > which processes input from the test_parser.py module, or stdin,
> > > depending on how it's called.  Please play with these; any input is
> > > welcome.
> >
> > I've found a module it breaks on ;)
> >
> > I'm looking into why right now...
>
> This breaks, still looking into it:
>
>
> class foo:
>     def __init__(self):
>         x = self.frozz(a="a", b="b")

I've checked in the simplest breaking expression:

class C:
    def __init__(self):
        local = foo(a = 1)

which I believe should evaluate to:

<Module filename="test data">
    <Class lineno="1" name="C">
        <Method lineno="2" name="__init__">
            <ParameterList lineno="2">
                <Parameter lineno="2" name="self">
            <Attribute lineno="3" name="local">
                <Expression lineno="3">
                    foo(a = 1)


But at the moment the rhs evaluation gets mighty confused when it hits that 
second '='.


    Richard

Re: [Docutils-develop] Python Reader module parser now usable

[Richard J. <rj...@ek...>]

On Thu, 19 Dec 2002 1:59 pm, Richard Jones wrote:
> On Thu, 19 Dec 2002 12:17 pm, David Goodger wrote:
> > I've also added a "showdoc" script to test/test_readers/test_python
> > which processes input from the test_parser.py module, or stdin,
> > depending on how it's called.  Please play with these; any input is
> > welcome.
>
> I've found a module it breaks on ;)
>
> I'm looking into why right now...

This breaks, still looking into it:


class foo:
    def __init__(self):
        x = self.frozz(a="a", b="b")


[there's a problem with trying to pop the closing bracket from the stack, the 
stack is already empty]



    Richard

Re: [Docutils-develop] Python Reader module parser now usable

[Richard J. <rj...@ek...>]

On Thu, 19 Dec 2002 12:17 pm, David Goodger wrote:
> I've also added a "showdoc" script to test/test_readers/test_python
> which processes input from the test_parser.py module, or stdin,
> depending on how it's called.  Please play with these; any input is
> welcome.

I've found a module it breaks on ;)

I'm looking into why right now...


   Richard

[Docutils-develop] Python Reader module parser now usable

[David G. <go...@py...>]

The first part of the Docutils Python Source Reader component is in a
usable form:
<http://docutils.sf.net/docutils/readers/python/moduleparser.py>.  It
takes a module's text (a string) and converts it into a
documentation-oriented tree.  Assignments/attributes, functions,
classes, and methods are all converted.  Arbitrarily complex
right-hand sides of assignments (including default parameter values)
are supported by parsing tokens from tokenize.py.  Comments are not
handled yet, and namespaces are not computed.  There's a list of open
issues at the end of the module docstring.

I've also added a "showdoc" script to test/test_readers/test_python
which processes input from the test_parser.py module, or stdin,
depending on how it's called.  Please play with these; any input is
welcome.

Here's a sample.  Given this module as input::

    # comment

    """Docstring"""

    """Additional docstring"""

    __docformat__ = 'reStructuredText'

    a = 1
    """Attribute docstring"""

    class C(Super):

        """C's docstring"""

        class_attribute = 1
        """class_attribute's docstring"""

        def __init__(self, text=None):
            """__init__'s docstring"""

            self.instance_attribute = (text * 7
                                       + ' whaddyaknow')
            """instance_attribute's docstring"""


    def f(x,                            # parameter x
          y=a*5,                        # parameter y
          *args):                       # parameter args
        """f's docstring"""
        return [x + item for item in args]

    f.function_attribute = 1
    """f.function_attribute's docstring"""

Here's the output tree, with objects converted to the pseudo-XML form
I'm fond of::

    <Module filename="<stdin>">
        <Docstring>
            Docstring
        <Docstring lineno="5">
            Additional docstring
        <Attribute lineno="7" name="__docformat__">
            <Expression lineno="7">
                'reStructuredText'
        <Attribute lineno="9" name="a">
            <Expression lineno="9">
                1
            <Docstring lineno="10">
                Attribute docstring
        <Class bases="Super" lineno="12" name="C">
            <Docstring lineno="12">
                C's docstring
            <Attribute lineno="16" name="class_attribute">
                <Expression lineno="16">
                    1
                <Docstring lineno="17">
                    class_attribute's docstring
            <Method lineno="19" name="__init__">
                <Docstring lineno="19">
                    __init__'s docstring
                <ParameterList lineno="19">
                    <Parameter lineno="19" name="self">
                    <Parameter lineno="19" name="text">
                        <Default lineno="19">
                            None
                <Attribute lineno="22" name="self.instance_attribute">
                    <Expression lineno="22">
                        (text * 7 + ' whaddyaknow')
                    <Docstring lineno="24">
                        instance_attribute's docstring
        <Function lineno="27" name="f">
            <Docstring lineno="27">
                f's docstring
            <ParameterList lineno="27">
                <Parameter lineno="27" name="x">
                <Parameter lineno="27" name="y">
                    <Default lineno="27">
                        a * 5
                <ExcessPositionalArguments lineno="27" name="args">
        <Attribute lineno="33" name="f.function_attribute">
            <Expression lineno="33">
                1
            <Docstring lineno="34">
                f.function_attribute's docstring

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

[Docutils-develop] Re: [ docutils-Feature Requests-654826 ] install command line tools via setup.py

[David A. <da...@bo...>]

David Goodger <go...@py...> writes:

> All input is welcome.

As a mostly-outsider, my only comment is that the plethora of very
similar-sounding tools is confusing.  Is there anything to the idea of
unifying html.py, pep2html.py, pep.py, and maybe even builhtml.py with
some kind of command-line option to select behaviors?

-- 
                       David Abrahams
   da...@bo... * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

Re: [Docutils-develop] latex writer

[David G. <go...@py...>]

[David Goodger]
>> 1. There's no vertical space between paragraphs in table cells.

[Richard Jones]
> I'm not sure I have a problem with this. I think it looks OK as it is...

In this particular case, one paragraph or two doesn't matter much.  But in
the general case of table cells containing multiple paragraphs (or other
objects, like lists etc.), there has to be some indication of separation.
If now way can be found for TeX tables to handle multiple paragraphs, it's a
documentation issue (at least until a way *is* found).  But I have to
believe that TeX can handle just about anything.

But without any concrete TeX knowledge I can't contribute to that code.  All
I can do is point out issues, and hope for the best.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[Richard J. <rj...@ek...>]

On Wed, 18 Dec 2002 11:58 am, David Goodger wrote:
> gr...@us... wrote:
> > the generated pdf:
> > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf
>
> Looking good!

I agree - great stuff. I've just run latex.py over the Roundup documentation - 
and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I 
can't run it over the cusomtizing.txt file because of the number of heading 
levels - it ends up generating a \subsubsubsection which there's no handler 
for.

My other random comments:

1. There seems to be a missing line break in definition lists after the term,
   possibly only when the definition is a list - for an example, see
     http://roundup.sf.net/doc-0.5/features.pdf

2. I'd like to be able to turn off the table of contents - it's not much use
   in most (if not all) of the pdfs generated for the Roundup documentation.

The result looks great though!


>  There are two things I notice though:
>
> 1. There's no vertical space between paragraphs in table cells.

I'm not sure I have a problem with this. I think it looks OK as it is...



    Richard

Re: [Docutils-develop] latex writer

[David G. <go...@py...>]

gr...@us... wrote:
> the generated pdf:
> http://docutils.sourceforge.net/sandbox/grubert/tools.pdf

Looking good!  There are two things I notice though:

1. There's no vertical space between paragraphs in table cells.

2. Near the end of the table, there's a cell that spans both columns.
   It doesn't have any border in the PDF file.  It should.  In this
   particular case it looks OK (it's a pseudo-title), but it's still
   wrong.

> anyway due to limited interest in the public, i will proceed at my
> pace.

Of course, by all means.  It's all about scratching your *own* itch,
after all!

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Mon, 16 Dec 2002, David Goodger wrote:

> Peter Funk wrote:
> > Do you have example tables long enough to be suitable for testing?
>
> There's a nice long table in docs/tools.txt
> (http://docutils.sf.net/docs/tools.html#configuration-file-entries).

the generated pdf: http://docutils.sourceforge.net/sandbox/grubert/tools.pdf

already handles this long table. the long tables i am talking of are
document information and option-list.
* docinfo still uses tabularx, therefore it is limited to one page.
* option-list now uses a latex list environment, therefore is no longer
  limited to one page. this will be used for the docinfo too.

anyway due to limited interest in the public, i will proceed at my pace.

cheers and have a nice day.

-- 
 BINGO: Das muessen wir noch kommunizieren
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

[Docutils-develop] Re: [ docutils-Feature Requests-654826 ] install command line tools via setup.py

[David G. <go...@py...>]

http://sf.net/tracker/?func=detail&atid=422033&aid=654826&group_id=38414

> Submitted By: Bill Bumgarner (bbum)
> 
> Setup.py should be augmented to install some/all of the
> tools into the appropriate install directory when
> 'python setup.py install' is invoked.
> 
> The tools are very useful as is and this would make
> them even more accessible.
> 
> One issue:  some of the tools should either be renamed
> or not installed.  For example, 'html.py' should be
> renamed such that it is associated more strongly with
> docutils when installed into a relatively cluttered
> spot such as /usr/local/bin/

These issues have come up before.  I'm inclined to agree.  What should the
tools be called?  Here are my initial thoughts:

===============  ======================================================
Current Name     Proposed New Name & Comments
===============  ======================================================
buildhtml.py     ? -- Builds HTML for all .txt files in a directory;
                 handles standalone RST, old-style PEPs & RST PEPs.
                 Kind of like a mini-make util.  Was a proof of concept
                 which may not be generally useful.  Install?

docutils-xml.py  rst2xml.py -- Produces Docutils-native XML.

html.py          rst2html.py

pep2html.py      no change -- Handles plaintext and RST PEPs.  This is
                 a copy of the tool that lives in Python's CVS.
                 Non-standard interface (different from other Docutils
                 tools).  Specialized tool; perhaps it shouldn't be
                 installed (anyone who needs it should get it from
                 Python's CVS).

pep.py           rstpep2html.py? -- Handles RST PEPs only, but with a
                 different command-line interface than pep2html.py;
                 this one has a standard Docutils front end interface.
                 Don't install?  No longer useful since pep2html.py
                 is the standard tool?

publish.py       rst2pseudoxml.py? -- Produces pseudo-XML, used mainly
                 for testing.  Install?

quicktest.py     quickrst.py? -- Produces various output, for testing.
                 This was the first front-end tool, before Docutils
                 existed.  Non-standard interface.  Should it be
                 installed?
===============  ======================================================

Input is welcome: alternative names, thoughts on the questions raised.

Should the .py suffix be kept?  On Linux/Unix it probably doesn't
matter, given a proper #! line, but on Windows it's significant.

See <http://docutils.sf.net/docs/tools.html> for tool details.

> Thanks -- awesome tool --

You're welcome, and thanks for the compliment.

> I have started using docutils
> for everything, including non-python things (and will
> likely have a bunch of bug reports, feature requests
> and patches related to non-Python support).

All input is welcome.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[David G. <go...@py...>]

Peter Funk wrote:
> Do you have example tables long enough to be suitable for testing?

There's a nice long table in docs/tools.txt
(http://docutils.sf.net/docs/tools.html#configuration-file-entries).

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Thu, 12 Dec 2002, Peter Funk wrote:

> Hi,
>
> gr...@us... schrieb:
> [...]
> > open issues
> [...]
> > the tables are problematic anyway.
> > * tabularx (used for docinfo and option list) is only for
> >   single page tables.
> > * table width is always full page width:
> >   possibly to try: assume rst-pagewidth of 80 get tablewidth
> >   and make same ratio in latex.
>
> Have you considered to use the 'supertab' package instead?

we are using longtable for tables, but for docinfo and option-list
i am thinking about a special list environment, with a minimal
term width. this should do it also or even better, as these are no
tables.

> Do you have example tables long enough to be suitable for testing?

we use test.txt, but docinfo or option-list donot exceed a page.
anyway i want to drive away from tables.


-- 
 BINGO: continually leverage existing value-added solutions
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] latex writer

[<pf...@ar...>]

Hi,

gr...@us... schrieb:
[...]
> open issues
[...]
> the tables are problematic anyway.
> * tabularx (used for docinfo and option list) is only for
>   single page tables.
> * table width is always full page width:
>   possibly to try: assume rst-pagewidth of 80 get tablewidth
>   and make same ratio in latex.

Have you considered to use the 'supertab' package instead?  
Do you have example tables long enough to be suitable for testing?

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany)