I had hoped that my suggestion of defining a "subset" of reST markup via a form of a cheetsheet -- especially with regard to the problematic table translation -- which could be translated to both html and latex would minimize the maintainer's work as it involved defining what was supported and testing translation rather than coding.  The subset need not be complete but rather "certifiable"

This would be valuable for me and would help me provide instructions to users of my wiki as what could be used and printed.

As to other features I personally would request (i) optional inclusion of the latex wrapfigure environment when reST figure role includes the align parameter and (ii) optional supression of latex translation the docinfo metadata

Clearly this issue of translation to latex and ultimately to pdf has attracted increasing attention in the docutils user community. I base this assertion (i) on the number of comments collected in the thread so far and (ii) google hits on the subject of reST to pdf translation.  The rst2pdf approach is one example but as I noted none of this really works up to the level of wikimedia translation of its markup to pdf. 

I think that as it has evolved (regardless of original conception) reST is being used as both a text format document in and of itself and as a markup specification which can be translated into multiple other formats especially html for web display and pdf for printing.  I would submit as example the use of reST as the native source for sphinx and docutils as its apparent software kernel is the most prominent example.  This is a great success for reST though it puts a big burden on the maintainers.


On Thu, May 2, 2013 at 2:15 PM, engelbert gruber <engelbert.gruber@gmail.com> wrote:
On 2 May 2013 16:28, Michael Prisant <michael.prisant@gmail.com> wrote:

> So back to the cheatsheet -- perhaps using the cheatsheet to identify which
> markup subset works with both the latex and html writers would be a more
> user meaningful short term solution than indicating that cheetsheet should
> be read as text.  Bringing the non-html writers (especially the latex
> writer) up to the full range of markup translation of the html writer might
> be a longer term goal

two things:

a. contributions welcome (it helps a lot to clarify, even if not
perfect. or to file the bug report, feature request)
b. to me, reStructured text is not a markup, it is a document
   it is what you see is what you have and get, plus you can get more
with docutils.

   tables are complex, there are numerous table packages for latex,
this is not so
   because tables are simple.

   html escapes some of the complexity by literally stepping aside,
but printouts do not
   scroll easily sideways.

   how to put the required information into reSt without degrading it
to markup ?

just so me
all the best

Michael G. Prisant