Allow non-HTML output for restructuredtext markup filter

[Fredo]

One advantage of reStructuredText over other lightweight markup languages is that it’s not limited to HTML output. Especially, the standard docutils provide a LaTeX writer, which allows for PDF generation. But also ODF output is supported.

I wrote a small patch that allows to change the rst writer, either through the settings module or through a filter parameter.

Please note that this patch conflicts with the one discussed in ticket #9504. It is probably a general design decision which one to prefer, if any.

[dc]

#11708 was marked as duplicate and also contains patch.

[Chris.Wesseling@…]

First of all: Sorry for the duplicate ticket. It was lousy ticket checking on my side. But just to start the design discussion...

So we can pass 1 argument to a filter and we have 2 patches with conflicting uses of that argument.

1. #9504 uses arg to give control over which item from the parts Dict is used.
2. #11342 (and #11708) use it to give control over which Writer is used.

The former excludes the latter, while it's fairly trivial to extend the html4css1 Writer to have parts['body'] contain anything you whish, like say what used to be in another parts item. It will get messy fairly quickly, though; the html4css1 parts has 22 items and implementing the full degree of freedom from the first patch would have you put up to 22 modules (some parts are duplicates or plain senseless in a template) in your pythonpath with Writer classes. Hardly desirable.

Another way would be to parse the argument to split it into 2 bits. But code like

  {{ value|restructuredtext:"html4css1.fragment" }}

has taken a fall from the ugly tree and is hard to document in a clear manner other than RTFC. But "html4css1.fragment" doesn't stray that far from how the template language handles variables.

Having separate filters for both uses seems cleaner:

  {{ value|rst_part:"fragment" }}
  and
  {{ value|rst_writer:"latex"}}

But it doesn't cater the combined case in a clean way.

No decision is also a decision. And resolving these tickets wontfix and have people implement this in custom filters is the simplest thing that could possibly work. ;-)

[Aymeric Augustin]

I've just closed #9504 which is incompatible with this ticket. The explanation is much clearer here. Whoever makes the design decision should consider both tickets.

[Aymeric Augustin]

Upon further thought, I think we should keep things simple and only support standard HTML output if the built-in restructuredtext filter.

I don't see the point of supporting LaTeX or ODF in Django's built-in template filters. And it isn't difficult to write a custom filter if you have specialized needs.