docutils-users — General discussions, questions, help requests.

Re: [Docutils-users] Question About Section Levels

[Guenter M. <mi...@us...>]

On 2019-10-01, Kent Borg wrote:
> As I understand it reStructuredText section levels are absolute, not
> relative. 
> That is, at any point one can do another section at the
> current level, do a section one level deeper, or do a section
> shallower. But in each case it must be an explicit level indicated
> by an explicit underlining character.

However, the mapping "adornment style" -> `section_level` is done "on the
go", i.e.  the first style encountered will be level 1, the second style
will be level 2, the third will be level 3, and so on.

http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#sections


> Is there a way to do a section that is merely "this level" or "one
> deeper than the current level" or "X number of levels shallower than
> the current level"? That's all reStructuredText wants to know, there
> must be a way to say that...

"this level": 
  use the style of the previous section title.

"one deeper than the current level":
  use the style "established" for one level deepter by previous use.
  If there  is no "established" style yet, use a new style.

"X number of levels shallower than the current level"
  ! not allowed in rST !
  

> The use-case is to make include files useful at different
> levels. Imagine a long document with lots of detail sitting in
> different include files, and imagine an executive summary document
> that has less detail, but wants to include a specific section to
> highlight something notable, using an include file that is also used
> by the long document. Cool, no problem...but what if the section
> level in the executive summary will be shallower than in the
> detailed document?

Then, you must change the section title adornment style in one of the
documents. Unfortunately, this means advance planning of section styles
(or lookup and editing later on). A good editor__ may help (e.g. by
producing an outline showing the adornments used in a document).

__ http://docutils.sourceforge.net/docs/user/links.html#editors


> Is there some option to include that will make contents relative to
> the depth at which the include directive appeared?

No. (It would be a nice thing but is non-trivial to implement.)

> Is there some way I might make a custom directive that can do
> relative sections?

This would be tricky, because currently, the included file is
included as source replacing the "include" directive and then parsing
continues (i.e. the result is the same as if the file content were
inserted into the master file before calling Docutils).


Thanks,

Günter

[Docutils-users] Question About Section Levels

[Kent B. <ken...@bo...>]

As I understand it reStructuredText section levels are absolute, not
relative. That is, at any point one can do another section at the
current level, do a section one level deeper, or do a section
shallower. But in each case it must be an explicit level indicated
by an explicit underlining character.

Is there a way to do a section that is merely "this level" or "one
deeper than the current level" or "X number of levels shallower than
the current level"? That's all reStructuredText wants to know, there
must be a way to say that...

The use-case is to make include files useful at different
levels. Imagine a long document with lots of detail sitting in
different include files, and imagine an executive summary document
that has less detail, but wants to include a specific section to
highlight something notable, using an include file that is also used
by the long document. Cool, no problem...but what if the section
level in the executive summary will be shallower than in the
detailed document?

Is there some option to include that will make contents relative to
the depth at which the include directive appeared?

Is there some way I might make a custom directive that can do
relative sections?

Thanks,

-kb

Re: [Docutils-users] CSV Table with code block inside a column

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

A sample of reST from the test suite is below (if the indentation doesn't
come through, see [1]_). The third column of the header and the first
column of the table body row consist of multi-line block markup, in this
case bullet lists. Note that between quotation marks, line breaks are
significant. All lines must be indented, and the greatest common
indentation is removed.

.. csv-table:: complex internal structure
   :header: "Treat", Quantity, "
            * Description,
            * Definition, or
            * Narrative"

   "
   * Ice cream
   * Sorbet
   * Albatross", 2.99, "On a stick!"

.. [1]
https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/test/test_parsers/test_rst/test_directives/test_tables.py

David Goodger
<https://david.goodger.org>


On Thu, 26 Sep 2019 at 22:32, jacques yakoub <jac...@ho...>
wrote:

> Hello,
>
> I would like to insert a code-block inside this csv table (inside the
> "code" column ).
>
> .. csv-table:: Compilations errors
>     :header: "File","Line","Error Message","Code"
>     :widths: auto
>
> As explained in the docs (
> http://docutils.sourceforge.net/docs/ref/rst/directives.html#id4 )  : "
>
> *Block markup and inline markup within cells is supported. Line ends are
> recognized within cells.*",
>
> I would like to use an block markup so that I can replace it with the
> right code-block later ( the code could be on multiple lines ). Can you
> give me a code sample for this situation, if it is possible ?
>
> If not, feel free to suggest an alternative as I should programmatically
> generate this code in python.
>
> Thanks for your help.
>
> Jacques
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>

[Docutils-users] CSV Table with code block inside a column

[jacques y. <jac...@ho...>]

Hello,

I would like to insert a code-block inside this csv table (inside the "code" column ).

.. csv-table:: Compilations errors
    :header: "File","Line","Error Message","Code"
    :widths: auto

As explained in the docs ( http://docutils.sourceforge.net/docs/ref/rst/directives.html#id4 )  : "

Block markup and inline markup within cells is supported. Line ends are recognized within cells.",

I would like to use an block markup so that I can replace it with the right code-block later ( the code could be on multiple lines ). Can you give me a code sample for this situation, if it is possible ?

If not, feel free to suggest an alternative as I should programmatically generate this code in python.

Thanks for your help.

Jacques

Re: [Docutils-users] Inline markup status

[Saša J. <sja...@gm...>]

On Tue, 10 Sep 2019 11:50:12 +0200
Martin Koutecký <m...@ef...> wrote:

> For my purposes, it would suffice if we could have one level of nested
> inline markup: there are substitution references which serve for
> deduplication, but some occurrences of the strings are emphasized
> while other are not -- this is where I need nesting.

Just to add that I'd very happy with that as well!

At the moment I'm considering whether to use rst or asciidoc(tor) markup for
all my writings which includes study notes, web content (via
static-site-generator), articles, slide-show presentations...up to working on
full-fledged book(s).

Although rst has strange mark for some things, it's still vwery powerful and
the tooling is much lighter - recently heard that reference implementation for
Asciidoc(tor)'s spec is going to be implemented in Java which does not sound
too great for me not liking to use Java in general...


Sincerely,
Gour

-- 
The senses, the mind and the intelligence are the sitting places
of this lust. Through them lust covers the real knowledge of the
living entity and bewilders him.

[Docutils-users] Inliner.init_customizations uses locals()

[Eric H. <er...@he...>]

because Inliner.init_customizations uses locals(), it can't be used in a subclass. This breaks subclasses that override init_customizations because they can't call super(). but super.init_customizations must be called because otherwise patterns is not initialized.

For an example of how this problem required a workaround, see https://github.com/gutenbergtools/ebookmaker/pull/13 <https://github.com/gutenbergtools/ebookmaker/pull/13>


Eric Hellman
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
https://go-to-hellman.blogspot.com/
twitter: @gluejar

Re: [Docutils-users] Inline markup status

[Guenter M. <mi...@us...>]

Dear Martin,

On 2019-09-10, Martin Koutecký wrote:

> I would like to ask about the current status of the inline markup feature.
> I'm aware of the reported state here:
> http://docutils.sourceforge.net/FAQ.html#is-nested-inline-markup-possible
> but I'm also curious because it doesn't mention the effort described here:
> https://sourceforge.net/p/docutils/feature-requests/22/ which seems to have
> gotten quite far. However, the patch doesn't apply against the current tree.

> For my purposes, it would suffice if we could have one level of nested
> inline markup: there are substitution references which serve for
> deduplication, but some occurrences of the strings are emphasized while
> other are not -- this is where I need nesting.

> Could you please give me a gauge of

> 1. How difficult would it be to port the patch in
> https://sourceforge.net/p/docutils/feature-requests/22/ to the current
> version?
> 2. What happened to that and the nesting branch?

Both are currently "sleeping". It may be interesting to revive them, but I
cannot tell how much work this would be.

> 3. If both above are useless / too hard, how difficult would it be to
> implement a "one level nesting" feature and whether you would be interested
> in including it, even though it falls short of the target described in the
> FAQ?

This may be a start but possibly not simpler than the original target of
recursive nesting.

Suggestions and patches are welcome, preferably in smaller steps so we can
discuss the changes "interactively".

Thanks,
Günter

[Docutils-users] Inline markup status

[Martin K. <m...@ef...>]

Hi,

I would like to ask about the current status of the inline markup feature.
I'm aware of the reported state here:
http://docutils.sourceforge.net/FAQ.html#is-nested-inline-markup-possible
but I'm also curious because it doesn't mention the effort described here:
https://sourceforge.net/p/docutils/feature-requests/22/ which seems to have
gotten quite far. However, the patch doesn't apply against the current tree.

For my purposes, it would suffice if we could have one level of nested
inline markup: there are substitution references which serve for
deduplication, but some occurrences of the strings are emphasized while
other are not -- this is where I need nesting.

Could you please give me a gauge of

1. How difficult would it be to port the patch in
https://sourceforge.net/p/docutils/feature-requests/22/ to the current
version?
2. What happened to that and the nesting branch?
3. If both above are useless / too hard, how difficult would it be to
implement a "one level nesting" feature and whether you would be interested
in including it, even though it falls short of the target described in the
FAQ?

Thanks a lot,

Martin Koutecky

Re: [Docutils-users] Writing Custom Directives, Expand Using Dynamic Data?

[Kent B. <ken...@bo...>]

On 9/2/19 9:26 AM, Guenter Milde via Docutils-users wrote:
> Did you try list tables or CSV tables? Depending on your needs these 
> may facilitate your task a lot. 

I have not used them.

RST tables are powerful, and we are using some of those powerful 
features, so of course there will be problems. As we have hit problems 
we have figure them out continued. At the moment they are doing what we 
need.

One thing that was surprising was when we put Chinese characters in a 
table it broke. I traced through and saw it was an alignment issue, with 
wide east asian characters being considered twice as wide as ASCII.

-kb

Re: [Docutils-users] Docutils docs as a single HTML or PDF?

[Guenter M. <mi...@us...>]

On 2019-09-01, Libor Jelinek wrote:
> Hello,
> before manually collecting all documents... How to read Docutils
> documentation as a single HTML or PDF that I will easily print, or save and
> read offline?

Unfortunately, there is no such meta file.

There were attempts to create a Sphinx version of the Docutils
documentation. This would provide for a cross-linked set of HTML
documents as well as a single PDF (via LaTeX). I don't know of a finished
such project, though.

Günter

Re: [Docutils-users] Writing Custom Directives, Expand Using Dynamic Data?

[Guenter M. <mi...@us...>]

On 2019-09-01, Kent Borg wrote:

> So, since that previous e-mail, I went off and, with some help, did what 
> I described, and we are very close to declaring Phase I a victory. Phase 
> II will be putting this to practical work.

> Let me give you a report on how things have gone:

...

> Building tables programmatically with ASCII art---um, no, correction: 
> utf-8 art!---

?? https://sourceforge.net/p/docutils/feature-requests/6/

> is a bit ugly. 
> And building tables by creating the right 
> doctree nodes directly is not exactly well documented. At the moment we 
> are doing some of each and we will need to rationalize that.

Did you try list tables or CSV tables? Depending on your needs these may
facilitate your task a lot.

http://docutils.sourceforge.net/docs/ref/rst/directives.html#tables

Günter

Re: [Docutils-users] Writing Custom Directives, Expand Using Dynamic Data?

[Kent B. <ken...@bo...>]

Hey, I got an answer! I didn't see it until now--this list does not have 
much traffic...

So, since that previous e-mail, I went off and, with some help, did what 
I described, and we are very close to declaring Phase I a victory. Phase 
II will be putting this to practical work.

Let me give you a report on how things have gone:

  * First looked at sample code in the docutils tree for how to process
    RST data programmaticly, from inside another Python program, and the
    resulting code has worked with few ongoing changes needed.

  * Have written quite a few custom directives. I am usually not a fan
    of being too object oriented, but with inheritance patterns I set up
    it is possible for me to create new custom directive for a new
    dynamically generated table in just a few lines of code. Or for a
    new dynamically generated graphic in just a few lines of code.

  * Have done a couple custom roles for cases where we needed syntax
    that could occur without breaking off into a new paragraph.

  * Pending nodes are our friends! We can drop them in the doctree as we
    go, then traverse them later, giving each a chance to convert itself
    into appropriate static data.

  * The API going into this code is roughly three calls:

     1. Instantiate the thing, passing in the name of a starting RST
        file (in other words, initialize a context for everything else
        that happens);
     2. Make a call asking what dynamic data is needed, passing in an
        initially empty dictionary, get back a list of missing data,
        fetch what is missing, update the dictionary, call
        again...repeat until there is no more missing data;
     3. With the now-complete dictionary of dynamic data make a render
        call, listing the needed output format(s), and get back the
        results, make more render calls on the same context if desired.

    The code on the RST side is kept completely ignorant of where the
    dynamic data actually comes from, and the code doing the data fetch
    is kept completely ignorant of all details of what RST looks like or
    might mean. This was important, not necessarily obvious it was
    needed, and not trivial to do.

  * Not everything can be done as a pending node, some things need to
    happen at parse time.

    This was a problem! We aren't changing RST syntax, we mostly have no
    gripes with what the parser does and had no interest in rewriting or
    otherwise messing with it, but when the parser hits one of our
    custom directives or custom roles and that code immediately needs
    some external data, there is no provision to communicate those needs
    up the call chain. So we go around the call chain: We run the parser
    as its own thread and when our code needs to communicate with the
    outside world it does so over a pair of Python queues, one for
    communicating out what dynamic data is needed, the other for getting
    back in the requested stuff. When it has what it needs, it acts
    accordingly, and the parsing continues per normal until some other
    directive or role needs additional data at parse time. This is
    admittedly a hack, but I think a reasonable one.

The state machine code that implements the three-call API, initializes 
things, fires up the second thread, etc., is not simple, but its 
responsibilities are otherwise very limited, so it has been stable for 
some time, we don't need to mess with it much. That file is less than 
500-lines long, and that's with a lot of comments. Not bad.

Building tables programmatically with ASCII art---um, no, correction: 
utf-8 art!---is a bit ugly. And building tables by creating the right 
doctree nodes directly is not exactly well documented. At the moment we 
are doing some of each and we will need to rationalize that.

We have a couple custom directives that we don't use from our RST files 
at all, rather they are instantiated programmatically by custom roles, 
to set up pending operations.

It all works pretty well. We are at the point that we /can/ get the code 
to do what we want (sometimes after some exploring when we want 
something new), now we mostly have to make sure it /does/ do what we 
want. We are dealing with content issues now, which was the whole point.

The hardest parts were two:

 1. Figuring what custom directives and roles would accomplish what we
    needed while still being sensible RST. There was a risk of inventing
    a whole new, completely obscure, domain-specific, programming
    language here. I needed to avoid that. Our source documents need to
    be something that normal people who know how to write, can write.
 2. Segregating concerns wherever we could, and keeping the
    implementation as architecturally clean as possible. I have left out
    a lot here, there are other system concerns that had to be accounted
    for yet still chased away and not allowed to creep into and
    complexify this into never working.

It is hard to make something simple. I think we have done a pretty 
decent job.


-kb

[Docutils-users] Docutils docs as a single HTML or PDF?

[Libor J. <lje...@vi...>]

Hello,
before manually collecting all documents... How to read Docutils
documentation as a single HTML or PDF that I will easily print, or save and
read offline?

Libor

Re: [Docutils-users] 0.15.1.post1 packaging/versioning problem

[engelbert g. <eng...@gm...>]

post is (in my understanding) if no code changed.

so an upgrade from -0.15.1 to 0.15.1.post1 would not be necessary

to a system (e.g. pip) would not read the "post" word but only count parts
in the version
0.15.1 is the same as 0.15.1-post1 and both are smaller than 0.15.1.post1

whl-packages of version 0.15.1.post1 have to be changed
if the "-" ist used (0.15.1-post1) then the whl-file can be simply renamed.

then i will pack 0.15.2 soon

On Fri, 26 Jul 2019 at 13:02, Guenter Milde via Docutils-users <
doc...@li...> wrote:

> On 2019-07-25, Andrew Jaffe wrote:
>
> > Hi,
>
> > There’s a problem with the latest release version — even if you install
> > the `post1` version, it doesn’t register and still shows a need to
> > upgrade. Happens with `pip`/`pip2`/`pip3`.
>
>
> > ~$ pip list --outdated
> > Package  Version Latest       Type
> > -------- ------- ------------ -----
> > docutils 0.15.1  0.15.1.post1 sdist
>
> > ~$ pip install --upgrade docutils
> > Collecting docutils
> > Installing collected packages: docutils
> >   Found existing installation: docutils 0.15.1
> >     Uninstalling docutils-0.15.1:
> >       Successfully uninstalled docutils-0.15.1
> > Successfully installed docutils-0.15.1
>
> > ~$ pip list --outdated
> > Package  Version Latest       Type
> > -------- ------- ------------ -----
> > docutils 0.15.1  0.15.1.post1 sdist
>
> I suppose this is because the tar archive should have been named
> "docutils-0.15.1.tar.gz" instead of docutils-0.15.1-post1.tar.gz
> (the post1 is only for sub-sub micro releases).
>


> To fix the version issues and the test failures reported by Dmitry,
> I suggest a 0.15.2 release with
>
> * docutils-0.15.2.tar.gz
> * docutils-0.15.2-py2-none-any.whl
> * docutils-0.15.2-py3-none-any.whl
>
> (even if no change to 0.15 is required for py3).
>
> Günter
>
>
>
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>

Re: [Docutils-users] 0.15.1.post1 packaging/versioning problem

[Guenter M. <mi...@us...>]

On 2019-07-25, Andrew Jaffe wrote:

> Hi, 

> There’s a problem with the latest release version — even if you install
> the `post1` version, it doesn’t register and still shows a need to
> upgrade. Happens with `pip`/`pip2`/`pip3`.


> ~$ pip list --outdated 
> Package  Version Latest       Type 
> -------- ------- ------------ -----
> docutils 0.15.1  0.15.1.post1 sdist

> ~$ pip install --upgrade docutils
> Collecting docutils
> Installing collected packages: docutils
>   Found existing installation: docutils 0.15.1
>     Uninstalling docutils-0.15.1:
>       Successfully uninstalled docutils-0.15.1
> Successfully installed docutils-0.15.1

> ~$ pip list --outdated 
> Package  Version Latest       Type 
> -------- ------- ------------ -----
> docutils 0.15.1  0.15.1.post1 sdist

I suppose this is because the tar archive should have been named
"docutils-0.15.1.tar.gz" instead of docutils-0.15.1-post1.tar.gz
(the post1 is only for sub-sub micro releases).

To fix the version issues and the test failures reported by Dmitry,
I suggest a 0.15.2 release with 

* docutils-0.15.2.tar.gz
* docutils-0.15.2-py2-none-any.whl 
* docutils-0.15.2-py3-none-any.whl

(even if no change to 0.15 is required for py3).

Günter

[Docutils-users] 0.15.1.post1 packaging/versioning problem

[Andrew J. <a.h...@gm...>]

Hi, 

There’s a problem with the latest release version — even if you install the `post1` version, it doesn’t register and still shows a need to upgrade. Happens with `pip`/`pip2`/`pip3`.


~$ pip list --outdated 
Package  Version Latest       Type 
-------- ------- ------------ -----
docutils 0.15.1  0.15.1.post1 sdist

~$ pip install --upgrade docutils
Collecting docutils
Installing collected packages: docutils
  Found existing installation: docutils 0.15.1
    Uninstalling docutils-0.15.1:
      Successfully uninstalled docutils-0.15.1
Successfully installed docutils-0.15.1

~$ pip list --outdated 
Package  Version Latest       Type 
-------- ------- ------------ -----
docutils 0.15.1  0.15.1.post1 sdist

[Docutils-users] Release 0.15.1 for python2

[engelbert g. <eng...@gm...>]

Bugfix release for bugs #366 circular import.

Only necessary for python2

all the best

Re: [Docutils-users] [Doc-SIG] docutils release 0.15

[Roger G. <rga...@ga...>]

On 21 July 2019 10:39:58 BST, engelbert gruber <eng...@gm...> wrote:
>Note
> Docutils 0.15.x is compatible with Python versions 2.6, 2.7 and 3.3 to
>3.5

Is there a problem with 3.6, 3.7 and 3.8 betas? Or is this an oversight in the announcement text



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Docutils-users] docutils release 0.15

[engelbert g. <eng...@gm...>]

Note
   Docutils 0.15.x is compatible with Python versions 2.6, 2.7 and 3.3 to
3.5

* reStructuredText:

  - Allow embedded colons in field list field names (before, tokens like
    ``:this:example:`` were considered ordinary text).

  - Fixed a bug with the "trim" options of the "unicode" directive.

* languages: Added Korean (ko) mappings and latin.

* Several fixes to keep mor information on source in parsed elements,
  isolate documents roles from other documents parsed, smartquotes,
  table gets width and latex table multicolumn cells, ...

all the best
 engelbert

Re: [Docutils-users] Writing Custom Directives, Expand Using Dynamic Data?

[Guenter M. <mi...@us...>]

Dear Kent,

On 2019-05-22, Kent Borg wrote:
> Hello,

> I am looking at using reStructuredText in the following custom way:

>   - Write documents using conventional rst for static data,

>   - And define my own custom directives and roles for dynamic data,

>   - Programmatically process my hybrid static/dynamic documents, 
> substituting/expanding my custom directives into static data,

>   - Likely write my own "writer"--or two or three--for custom output 
> formats, though that will come later.

> I don't see a lot of documentation on this kind of work. Looking about I 
> made it as far as core.publish_programmatically() and that looks 
> promising, plus the documentation there says that if I think I want to 
> use this code I should ask on the list first.

> So, two questions:

> 1) And I crazy?

Ambitious.

Docutils is designed with this use-case in mind, so it is not too hard to
achieve. However, there is no user manual for this task, so you will need
to read and understand the source code.


> 2) How should I go about this?

I suggest starting with a custom `front end tool`__ that imports and
enhances the parser prior to the call to publish_cmdline().

__ http://docutils.sourceforge.net/docs/api/cmdline-tool.html

An example for this approach is http://docutils.sourceforge.net/sandbox/jensj/latex_math/tools/rst2latexmath.py
from the times Docutils did not have native math support.


* Get a general understanding of rST and Docutils.

* Look for examples in the sandbox or other extensions__.

  __ http://docutils.sourceforge.net/docs/user/links.html#extensions


* Look for examples for directives and roles in docutils/parsers/rst/

* Eventually study examples for "transforms" (working on the generated
  document tree Python object) in docutils/transforms


Start with a simple example and come back to the list if there are
specific questions.

Good luck,

Günter

Re: [Docutils-users] width vs csv-table

[Alan I. <ala...@gm...>]

Apologies, I shd have updated before reporting.  It's fixed in latest Subversion (8256).
(Unfortunately I did not check the revision I was updating from so I cannot report that.)

Alan


On 6/11/2019 3:44 AM, Guenter Milde via Docutils-users wrote:
> On 2019-06-10, Alan Isaac wrote:
>> If I understand the documentation, the following should work::
> 
>>     .. csv-table:: Test
>>        :width: 50%
> 
>>        test01
>>        test02
> 
>> The html5 write produces no content for this.
>> If I remove the `width` specification, the output is as expected.
> 
> I cannot reproduce. Here, with
> `rst2html5 --link-stylesheet example.txt` I get the expected:
> 
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
> <head>
> <meta charset="utf-8"/>
> <meta name="generator" content="Docutils 0.15b.dev: http://docutils.sourceforge.net/" />
> <title>widetable.rst</title>
> <link rel="stylesheet" href="<path-to>/docutils/writers/html5_polyglot/minimal.css" type="text/css" />
> <link rel="stylesheet" href="<path-to>/docutils/writers/html5_polyglot/plain.css" type="text/css" />
> </head>
> <body>
> <div class="document">
> 
> 
> <table style="width: 50%">
> <caption>Test</caption>
> <colgroup>
> <col style="width: 100%" />
> </colgroup>
> <tbody>
> <tr><td><p>test01</p></td>
> </tr>
> <tr><td><p>test02</p></td>
> </tr>
> </tbody>
> </table>
> </div>
> </body>
> </html>
> 
> 
> Günter
> 
> 
> 
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
> 
> Please use "Reply All" to reply to the list.
> 

Re: [Docutils-users] width vs csv-table

[Guenter M. <mi...@us...>]

On 2019-06-10, Alan Isaac wrote:
> If I understand the documentation, the following should work::

>    .. csv-table:: Test
>       :width: 50%

>       test01
>       test02

> The html5 write produces no content for this.
> If I remove the `width` specification, the output is as expected.

I cannot reproduce. Here, with
`rst2html5 --link-stylesheet example.txt` I get the expected:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="utf-8"/>
<meta name="generator" content="Docutils 0.15b.dev: http://docutils.sourceforge.net/" />
<title>widetable.rst</title>
<link rel="stylesheet" href="<path-to>/docutils/writers/html5_polyglot/minimal.css" type="text/css" />
<link rel="stylesheet" href="<path-to>/docutils/writers/html5_polyglot/plain.css" type="text/css" />
</head>
<body>
<div class="document">


<table style="width: 50%">
<caption>Test</caption>
<colgroup>
<col style="width: 100%" />
</colgroup>
<tbody>
<tr><td><p>test01</p></td>
</tr>
<tr><td><p>test02</p></td>
</tr>
</tbody>
</table>
</div>
</body>
</html>


Günter 

Re: [Docutils-users] transition inside container

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

Transitions are structural elements, along with sections & sidebars.
Containers are body elements, which cannot contain structural
elements. See docs/ref/docutils.dtd for complete technical details.

You could simulate a transition with an empty paragraph (escaped space: "\ ").

Compared to Docutils, HTML has a much more permissive, anything-goes,
way-too-loose document model.

David Goodger
<https://david.goodger.org>

On Mon, 10 Jun 2019 at 12:26, Alan Isaac <ala...@gm...> wrote:
>
> I want to indicate a thematic transition inside a containter.
>
> It seems that transitions (http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#transitions)
> are not allowed inside containers.  Why is that?  (E.g., an HR element can certainly go inside a DIV element
> in an HTML document.)
>
> Thank you,
> Alan Isaac
>
>
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.

[Docutils-users] width vs csv-table

[Alan I. <ala...@gm...>]

If I understand the documentation, the following should work::

   .. csv-table:: Test
      :width: 50%

      test01
      test02

The html5 write produces no content for this.
If I remove the `width` specification, the output is as expected.

Alan Isaac

[Docutils-users] transition inside container

[Alan I. <ala...@gm...>]

I want to indicate a thematic transition inside a containter.

It seems that transitions (http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#transitions)
are not allowed inside containers.  Why is that?  (E.g., an HR element can certainly go inside a DIV element
in an HTML document.)

Thank you,
Alan Isaac