gmane.text.docutils.user

Ben Finney | 28 Mar 00:19

Alternatives for reST -> PDF

Howdy all,

reStructuredText is wonderful; a simple, unambiguous, unobtrusive
markup that gives a lot of expressive power.

Conversion to XHTML or XML is simple. Conversion to PDF isn't so great.

That's because (La)TeX is *not* simple, nor unobtrusive. It refuses to
work as a simple pipeline. It sprays files I don't care about all over
the directory. It requires running multiple times to get a single
result. It fails to deal with the Unicode character set cleanly. And
so on.

Now, if I want to fix the problems with (La)TeX, I should go to a
group dealing with that topic. They will instruct me on how to fix the
documents and run the programs in different ways.

But I'm not writing the stuff; I'm just trying to deal with it as an
intermediary document format. I don't care about (La)TeX, except as
part of a pipeline from reST to PDF. And that part of the pipeline is
too awkward; I don't want to increase my knowledge of it.

What alternatives are there? Can I render from reST to PDF via some
other, more reliable route, avoiding (La)TeX and all its annoyances?

--

-- 
 \        "The number of UNIX installations has grown to 10, with more |
  `\     expected."  -- Unix Programmer's Manual, 2nd Ed., 12-Jun-1972 |
_o__)                                                                  |
Ben Finney

(Continue reading)

grubert | 28 Mar 10:17

Re: Alternatives for reST -> PDF

On Tue, 28 Mar 2006, Ben Finney wrote:

> Howdy all,
>
> reStructuredText is wonderful; a simple, unambiguous, unobtrusive
> markup that gives a lot of expressive power.
>
> Conversion to XHTML or XML is simple. Conversion to PDF isn't so great.

the difference is. you convert to xhtml and the rendering is done in the 
browser. you convert to latex-code and the rendering is done by latex.

> That's because (La)TeX is *not* simple, nor unobtrusive. It refuses to
> work as a simple pipeline. It sprays files I don't care about all over
> the directory. It requires running multiple times to get a single
> result. It fails to deal with the Unicode character set cleanly. And
> so on.

latex is dead simple too me, how easy can one get::

   pdflatex abc.tex

> Now, if I want to fix the problems with (La)TeX, I should go to a
> group dealing with that topic. They will instruct me on how to fix the
> documents and run the programs in different ways.

which problems do you have ?

> But I'm not writing the stuff; I'm just trying to deal with it as an
> intermediary document format. I don't care about (La)TeX, except as

(Continue reading)

G. Milde | 28 Mar 14:08

Re: Alternatives for reST -> PDF

On 28.03.06, Ben Finney wrote:
> Howdy all,
> 
> reStructuredText is wonderful; a simple, unambiguous, unobtrusive
> markup that gives a lot of expressive power.
> 
> Conversion to XHTML or XML is simple. Conversion to PDF isn't so great.
> 
> That's because (La)TeX is *not* simple, nor unobtrusive. It refuses to
> work as a simple pipeline. It sprays files I don't care about all over
> the directory. It requires running multiple times to get a single
> result. It fails to deal with the Unicode character set cleanly. And
> so on.

The task of converting RsT to PDF is more complex, so is the tool. To be
simple, you would need a wrapper around the pdflatex command that does
the housekeeping. (Set up a temp-dir, Do Unicode conversion, Re-run until
ready, remove aux files). For example LyX has such scripts and you can
convert to PDF with a single button press (if all goes well). 

It should be possible to write a similar script for rst2pdf that would
fit nicely into the rst2html, rst2latex, ... family.

The price you have to pay comes when something does not go well. Finding
an error out of the (then normally hidden and) sometimes cryptic messages
and fixing might prove a challenge.

> What alternatives are there? Can I render from reST to PDF via some
> other, more reliable route, avoiding (La)TeX and all its annoyances?

(Continue reading)

Nick Moffitt | 28 Mar 18:14

Re: Alternatives for reST -> PDF

G. Milde:
> > What alternatives are there? Can I render from reST to PDF via some
> > other, more reliable route, avoiding (La)TeX and all its annoyances?
> 
> If you care for best layout quality, LaTeX might still be the
> ultimative choice. 

With respect, LaTeX hasn't been the king of layout in a long time.  It
works most of the time, true, and ten years ago it was a jewel in the
Free Software crown, but it has shown its age since then.  It's pretty
warty.  I'm kind of irritated at the person who thought that simply
suggesting pdflatex or whatever would solve all of LaTeX's warts and
misfeatures.

One thing that might turn out useful would be a Scribus-writer.  Scribus
also uses an XML format, so it may even be possible to play goofy XSLT
games on the docutils internal XML format stuff.  

One drawback seems to be that Scribus currently doesn't operate
headless.  I thought it did, and just checked now, but I may have been
thinking of Inkscape (which I've used to render script-generated SVG
into PNG).  But Scribus is scriptable in python, so who knows.

--

-- 
Support your droogs!                        Nick Moffitt
                                           nick <at> zork.net

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast

(Continue reading)

grubert | 28 Mar 20:59

Re: Alternatives for reST -> PDF

On Tue, 28 Mar 2006, Nick Moffitt wrote:

> G. Milde:
>>> What alternatives are there? Can I render from reST to PDF via some
>>> other, more reliable route, avoiding (La)TeX and all its annoyances?
>>
>> If you care for best layout quality, LaTeX might still be the
>> ultimative choice.
>
> With respect, LaTeX hasn't been the king of layout in a long time.

that is a typo "LaTeX has been the king of layout in a long time."

what else groff, lout,

> It
> works most of the time, true, and ten years ago it was a jewel in the
> Free Software crown, but it has shown its age since then.  It's pretty
> warty.  I'm kind of irritated at the person who thought that simply
> suggesting pdflatex or whatever would solve all of LaTeX's warts and
> misfeatures.
>
> One thing that might turn out useful would be a Scribus-writer.  Scribus
> also uses an XML format, so it may even be possible to play goofy XSLT
> games on the docutils internal XML format stuff.

the XSL-FO does this already.

> One drawback seems to be that Scribus currently doesn't operate
> headless.  I thought it did, and just checked now, but I may have been

(Continue reading)

Alan G Isaac | 29 Mar 01:14

Re[2]: Alternatives for reST -> PDF

> G. Milde: 
>> If you care for best layout quality, LaTeX might still be 
>> the ultimative choice. 

On Tue, 28 Mar 2006, Nick Moffitt apparently wrote: 
> With respect, LaTeX hasn't been the king of layout in a long time.  It 
> works most of the time, true, and ten years ago it was a jewel in the 
> Free Software crown, but it has shown its age since then. 

I would say that this is not an argument over anything 
except the meaning of 'layout'.  LaTeX was never a "page 
layout" program, but it is still excellent for its core 
typesetting purposes.  As far as I have seen, it remains 
unrivaled for typesetting math.  And for simple but 
featureful PDF production it is hard to beat too.
Indeed I would say that for these purposes it has aged 
almost not at all, and the TeX underpinnings perhaps even 
less.

To each task a tool.

Cheers,
Alan Isaac

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

(Continue reading)

G. Milde | 29 Mar 16:14

Re: Alternatives for reST -> PDF

On 28.03.06, Nick Moffitt wrote:
> G. Milde:

Wanted: Alternatives for reST -> PDF

> > > What alternatives are there? Can I render from reST to PDF via some
> > > other, more reliable route, avoiding (La)TeX and all its annoyances?

What I would like to see is a script that does the reST2PDF conversion
with one command, similar to rst2html or rst2latex.

pdflatex
--------

My first suggestion was a wrapper script around pdflatex that would
care for the necessary preparation, run as many times as needed and
clean up afterwards thus bypassing the most obvious annoyances of LaTeX.

There is a script to facilitate pdf creation at
http://developer.berlios.de/projects/tex2pdf/
that could serve as a base.

> > If you care for best layout quality, LaTeX might still be the
> > ultimative choice. 
> 
> With respect, LaTeX hasn't been the king of layout in a long time.  It
> works most of the time, true, and ten years ago it was a jewel in the
> Free Software crown, but it has shown its age since then.  It's pretty
> warty.  I'm kind of irritated at the person who thought that simply
> suggesting pdflatex or whatever would solve all of LaTeX's warts and

(Continue reading)

grubert | 29 Mar 21:37

Re: Alternatives for reST -> PDF

On Wed, 29 Mar 2006, G. Milde wrote:

> On 28.03.06, Nick Moffitt wrote:
>> G. Milde:

> Wanted: Alternatives for reST -> PDF

in general check the sandbox 
http://docutils.sourceforge.net/docs/user/links.html

>>>> What alternatives are there? Can I render from reST to PDF via some
>>>> other, more reliable route, avoiding (La)TeX and all its annoyances?
>
> What I would like to see is a script that does the reST2PDF conversion
> with one command, similar to rst2html or rst2latex.
>
> pdflatex
> --------
>
> My first suggestion was a wrapper script around pdflatex that would
> care for the necessary preparation, run as many times as needed and
> clean up afterwards thus bypassing the most obvious annoyances of LaTeX.
>
> There is a script to facilitate pdf creation at
> http://developer.berlios.de/projects/tex2pdf/
> that could serve as a base.

in the sandbox

   Beni Cherniavsky maintains a Makefile for driving Docutils, hoping to

(Continue reading)

Ben Finney | 30 Mar 00:18

Re: Alternatives for reST -> PDF

"G. Milde" <g.milde <at> web.de> writes:

> Wanted: Alternatives for reST -> PDF

Thanks for this collation of the options discussed so far.

> What I would like to see is a script that does the reST2PDF
> conversion with one command, similar to rst2html or rst2latex.

Yes, that's my need as well. In my processes, LaTeX is useful only to
the extent that it helps get to that goal.

> pdflatex
> --------
>
> My first suggestion was a wrapper script around pdflatex that would
> care for the necessary preparation, run as many times as needed and
> clean up afterwards thus bypassing the most obvious annoyances of LaTeX.

Something that can:

  - run as a pipeline (LaTeX on stdin, PDF on stdout) by default

  - allow any specified path for input file and/or output file

  - hide all the cruft that LaTeX processing creates, leaving no extra
    files unless asked

  - properly handle Unicode, standard fonts, standard filenames and
    locations, and other conventions that seem poorly supported by

(Continue reading)

Roberto Alsina | 30 Mar 00:37

Re: Re: Alternatives for reST -> PDF

El Miércoles, 29 de Marzo de 2006 19:18, Ben Finney escribió:
> "G. Milde" <g.milde <at> web.de> writes:
> > Wanted: Alternatives for reST -> PDF
>
> Thanks for this collation of the options discussed so far.
>
> > What I would like to see is a script that does the reST2PDF
> > conversion with one command, similar to rst2html or rst2latex.
>
> Yes, that's my need as well. In my processes, LaTeX is useful only to
> the extent that it helps get to that goal.
>
> > pdflatex
> > --------
> >
> > My first suggestion was a wrapper script around pdflatex that would
> > care for the necessary preparation, run as many times as needed and
> > clean up afterwards thus bypassing the most obvious annoyances of LaTeX.
>
> Something that can:
>
>   - run as a pipeline (LaTeX on stdin, PDF on stdout) by default
>
>   - allow any specified path for input file and/or output file
>
>   - hide all the cruft that LaTeX processing creates, leaving no extra
>     files unless asked
>
>   - properly handle Unicode, standard fonts, standard filenames and
>     locations, and other conventions that seem poorly supported by

(Continue reading)

Martin Blais | 30 Mar 08:07

Re: Re: Alternatives for reST -> PDF

On 3/29/06, Ben Finney <bignose+hates-spam <at> benfinney.id.au> wrote:
> "G. Milde" <g.milde <at> web.de> writes:
>
> Something that can:
>
>   - run as a pipeline (LaTeX on stdin, PDF on stdout) by default
>
>   - allow any specified path for input file and/or output file
>
>   - hide all the cruft that LaTeX processing creates, leaving no extra
>     files unless asked
>
>   - properly handle Unicode, standard fonts, standard filenames and
>     locations, and other conventions that seem poorly supported by
>     LaTeX
>
>   - ensure that the process ends with either an unambiguous error
>     state, or a complete PDF rendering of the input
>
> Currently pdflatex does *none* of these, and is thus a bad tool
> (largely because it fails to sufficiently abstract the underlying bad
> tools).

I totally agree.  I even started writing such a tool, I just want to
be able to say rst2pdf.py <myfile.tex> and only see <myfile.pdf> as
output.  That's it, no crap, nothing else generated.

I wrote the tool, copying my file to a temporary directory, and its
dependent files.  I ran into a bunch of issues with file
inputs/includes from LaTeX, and then I got derailed onto some other

(Continue reading)

David Goodger | 30 Mar 15:27

Re: Re: Alternatives for reST -> PDF

[Martin Blais]
> Another issue: I talked to Dave about it, multiple times, and he's
> quite hung-up on not including this tool in the standard docutils
> tools, for some reason (I can't remember which).  Dave?

I can't remember either.  I have no memory of such conversations.
Are you sure your memory is accurate?  Which tool are you talking
about?

Perhaps you're thinking of a LaTeX math directive, which I won't
include in the Docutils core until it supports arbitrary output (not
just LaTeX output).

--

-- 
David Goodger <http://python.net/~goodger>

Felix Wiemann | 14 May 16:10

Re: Alternatives for reST -> PDF

David Goodger wrote:

> Martin Blais wrote:
>
>> Another issue: I talked to Dave about it, multiple times, and he's
>> quite hung-up on not including this tool [rst2pdf.py] in the standard
>> docutils tools, for some reason (I can't remember which).  Dave?
>
> I can't remember either.

Well, I think it was me who objected.  The problem is that such a tool
is too fragile.  I don't dare committing to making this tool work for
all kinds of edge-cases (dependent files, etc.).

Anyway, people will still have to know what they're doing (having
pdflatex in the $PATH [often not the case on Windows, I guess], and
deciding whether to run pdflatex one, two, or three times).  So the
promise of "just converting reST to PDF" won't work anyway, people still
have to understand how to use pdflatex.

--

-- 
For private mail please ensure that the header contains 'Felix Wiemann'.

"the number of contributors [...] is strongly and inversely correlated with the
number of hoops each project makes a contributing user go through."      -- ESR

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

(Continue reading)

Diego Essaya | 19 May 19:17

Re: Re: Alternatives for reST -> PDF

Hi all,

I just wanted to add my thoughts about this subject. I recently
subscribed to the list; this is why I am replying to Felix's mail and
not the first one in the thread.

I totally agree, pdflatex has lots of drawbacks. Right now it may be
the best tool available for PDF conversion, but it would be great if
there was a more convenient way.

The funny thing is that I realized this situation on my own some days
ago. I started to do some research and came to the same conclusions
that were expressed in this thread. Today I found the thread in the
archives, and I was surprised when I saw Ben's mail, since he
expressed the very same issues that I have with (La)TeX.

I have a feeling that "The Right Thing (TM)" would be to rely on CSS
Print Profile[1], or better yet, on CSS3 Paged Media Module[2].
Unfortunately, I don't think there is any free tool implementing this
(Prince[3] is a non-free alternative).

[1] http://www.w3.org/TR/css-print/
[2] http://www.w3.org/TR/css3-page/
[3] http://www.princexml.com/

Using this approach, rst2pdf could just produce an XML or XHTML and
then convert it to PDF using a standard or custom CSS stylesheet. Or,
one could just generate a single XHTML and use separate stylesheets
for showing on screen and printing.

(Continue reading)

Felix Wiemann | 20 May 13:42

Re: Alternatives for reST -> PDF

Diego Essaya wrote:

> I have a feeling that "The Right Thing (TM)" would be to rely on CSS
> Print Profile[1], or better yet, on CSS3 Paged Media Module[2].
> Unfortunately, I don't think there is any free tool implementing this
> (Prince[3] is a non-free alternative).

The tool support is the problem indeed.

(La)TeX code looks really ugly IMO, but LaTeX is the only free system
that does actual typesetting, not just text rendering.  We aren't using
LaTeX because we like it, but because it's the only tool out there.
(Well, there may be other TeX-derivatives, but LaTeX seems to be the
most powerful one for general-purpose typesetting.)

Prince's samples look better than Firefox's print output for sure, but
it doesn't even come close to the quality of LaTeX's output.  Not in
math, not in anything else -- hyphenation, margins, font combinations,
kerning, ligatures, etc.

> Using this approach, rst2pdf could just produce an XML or XHTML and
> then convert it to PDF using a standard or custom CSS stylesheet.

Yes, but why wouldn't you want to go via LaTeX instead of via XHTML?
Especially if LaTeX's quality is so much better?

--

-- 
For private mail please ensure that the header contains 'Felix Wiemann'.

"the number of contributors [...] is strongly and inversely correlated with the

(Continue reading)

Beni Cherniavsky | 20 May 20:02

Re: Re: Alternatives for reST -> PDF

On 5/20/06, Felix Wiemann <Felix.Wiemann <at> gmx.net> wrote:
> (La)TeX code looks really ugly IMO, but LaTeX is the only free system
> that does actual typesetting, not just text rendering.  We aren't using
> LaTeX because we like it, but because it's the only tool out there.
> (Well, there may be other TeX-derivatives, but LaTeX seems to be the
> most powerful one for general-purpose typesetting.)
>
How about Lout?  I've read the design paper with fascination but I
didn't try to actually typeset anything with it.  Can anybody comment
on its output quality?

There is already a lot of code in  sandbox/lalo/lout_writer.py.
What's the status?

--

-- 
Beni Cherniavsky <cben <at> users.sf.net>, who can only read email on weekends.
Governments are like kernels - everything possible should be done in user space.

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Marcelo G Huerta | 21 May 00:06

Re: Re: Alternatives for reST -> PDF

El 20/05/2006 a las 15:02, Beni Cherniavsky <cben <at> users.sf.net> dijo,
en su mensaje "[Docutils-users] Re: Alternatives for reST -> PDF":

> How about Lout? I've read the design paper with fascination but I
> didn't try to actually typeset anything with it. Can anybody comment
> on its output quality?

Lout's output is PostScript (the PDF backend is officially declared
broken by its author), so you would have to use a different tool to
convert PS to PDF.

Also, the crossreferences normally require several runs, as I read is
the case for (La)TeX, until they all coalesce in a complete document.
And some references can be always in state of flux if, for example, a
figure doesn't fit completely in a page and it has to be moved to a
different page to do it.

The quality seemed pretty much ok for me.

> There is already a lot of code in  sandbox/lalo/lout_writer.py.
> What's the status?

I tried it a while ago. If nothing has changed since then, supposedly
you could create a basic document with it, but whenever I tried it I
failed to achieve a syntactically correct Lout document. I've been
thinking about doing something about that, but being a personal
sandbox I never wanted to meddle with it.

Also, I'm the biggest procrastinator ever

(Continue reading)

Diego Essaya | 20 May 22:53

Re: Re: Alternatives for reST -> PDF

On 5/20/06, Felix Wiemann <Felix.Wiemann <at> gmx.net> wrote:
> > Using this approach, rst2pdf could just produce an XML or XHTML and
> > then convert it to PDF using a standard or custom CSS stylesheet.
>
> Yes, but why wouldn't you want to go via LaTeX instead of via XHTML?
> Especially if LaTeX's quality is so much better?

Suppose there was a tool that provided the same quality LaTeX does.
IMO, a CSS stylesheet is a much easier and cleaner way to specify
formatting. Also, I think there are more people with experience in CSS
(applied to web pages) than people really experienced in LaTeX. I am
not one of them, in fact I have almost no knowledge in CSS, but as far
as I have seen, if it works so well on screen formatting, I think it
would be great applied to printed pages.

Of course, since pdflatex is unmatched in quality, it is the 'least
bad' choice right now.

Regards,
Diego

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642

grubert | 20 May 19:02

Re: Re: Alternatives for reST -> PDF

On Fri, 19 May 2006, Diego Essaya wrote:

> I just wanted to add my thoughts about this subject. I recently
> subscribed to the list; this is why I am replying to Felix's mail and
> not the first one in the thread.
>
> I totally agree, pdflatex has lots of drawbacks. Right now it may be
> the best tool available for PDF conversion, but it would be great if
> there was a more convenient way.

aside from the fact that latex just plain works for me, anyone else maybe 
should try to get happy with sandbox/dpriest/XSL-FO

cheers
--

-- 

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

ranky | 30 Mar 10:03

Re: Re: Alternatives for reST -> PDF

on 30.03.2006 00:18 Ben Finney said the following:
> "G. Milde" <g.milde <at> web.de> writes:
>> Wanted: Alternatives for reST -> PDF
> 
> Thanks for this collation of the options discussed so far.
> 
>> What I would like to see is a script that does the reST2PDF
>> conversion with one command, similar to rst2html or rst2latex.
> 
> Yes, that's my need as well. In my processes, LaTeX is useful only to
> the extent that it helps get to that goal.
> 
>> pdflatex
>> --------
>>
>> My first suggestion was a wrapper script around pdflatex that would
>> care for the necessary preparation, run as many times as needed and
>> clean up afterwards thus bypassing the most obvious annoyances of LaTeX.
> 
> Something that can:
> 
>   - run as a pipeline (LaTeX on stdin, PDF on stdout) by default
> 
>   - allow any specified path for input file and/or output file
> 
>   - hide all the cruft that LaTeX processing creates, leaving no extra
>     files unless asked
> 
>   - properly handle Unicode, standard fonts, standard filenames and
>     locations, and other conventions that seem poorly supported by

(Continue reading)

Dave Kuhlman | 30 Mar 19:10

Re: Alternatives for reST -> PDF

On Tue, Mar 28, 2006 at 08:19:52AM +1000, Ben Finney wrote:
> Howdy all,
> 
> reStructuredText is wonderful; a simple, unambiguous, unobtrusive
> markup that gives a lot of expressive power.
> 
> Conversion to XHTML or XML is simple. Conversion to PDF isn't so great.
> 
> That's because (La)TeX is *not* simple, nor unobtrusive. It refuses to
> work as a simple pipeline. It sprays files I don't care about all over
> the directory. It requires running multiple times to get a single
> result. It fails to deal with the Unicode character set cleanly. And
> so on.
> 
> Now, if I want to fix the problems with (La)TeX, I should go to a
> group dealing with that topic. They will instruct me on how to fix the
> documents and run the programs in different ways.
> 
> But I'm not writing the stuff; I'm just trying to deal with it as an
> intermediary document format. I don't care about (La)TeX, except as
> part of a pipeline from reST to PDF. And that part of the pipeline is
> too awkward; I don't want to increase my knowledge of it.
> 
> What alternatives are there? Can I render from reST to PDF via some
> other, more reliable route, avoiding (La)TeX and all its annoyances?
> 

I do not know about other (non-LaTeX) routes, but ...

I've written a Python script that processes reST files in a set of

(Continue reading)

Martin Blais | 30 Mar 19:59

Re: Alternatives for reST -> PDF

On 3/30/06, Dave Kuhlman <dkuhlman <at> rexx.com> wrote:
> On Tue, Mar 28, 2006 at 08:19:52AM +1000, Ben Finney wrote:
> > Howdy all,
> >
> > reStructuredText is wonderful; a simple, unambiguous, unobtrusive
> > markup that gives a lot of expressive power.
> >
> > Conversion to XHTML or XML is simple. Conversion to PDF isn't so great.
> >
> > That's because (La)TeX is *not* simple, nor unobtrusive. It refuses to
> > work as a simple pipeline. It sprays files I don't care about all over
> > the directory. It requires running multiple times to get a single
> > result. It fails to deal with the Unicode character set cleanly. And
> > so on.
> >
> > Now, if I want to fix the problems with (La)TeX, I should go to a
> > group dealing with that topic. They will instruct me on how to fix the
> > documents and run the programs in different ways.
> >
> > But I'm not writing the stuff; I'm just trying to deal with it as an
> > intermediary document format. I don't care about (La)TeX, except as
> > part of a pipeline from reST to PDF. And that part of the pipeline is
> > too awkward; I don't want to increase my knowledge of it.
> >
> > What alternatives are there? Can I render from reST to PDF via some
> > other, more reliable route, avoiding (La)TeX and all its annoyances?
> >
>
> I do not know about other (non-LaTeX) routes, but ...
>

(Continue reading)

Return

Return to gmane.text.docutils.user.

Advertisement

Project Web Page

User discussion for the docutils project.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane