From: Ben F. <big...@be...> - 2006-03-27 22:50:23
|
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 |
From: <gr...@us...> - 2006-03-28 08:20:07
|
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 > 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? sandbox/dpriest/XSL-FO is a posibility the rlpdf-writer is rather minimal, but if it suffices for you ... cheers -- |
From: G. M. <mi...@if...> - 2006-03-28 12:02:25
|
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? If you care for best layout quality, LaTeX might still be the ultimative choice. If your demands are more limited, you might try the way via Html. Either print from your browser, or try html2ps and ps2pdf. Guenter -- Milde ife.et.tu-dresden.de |
From: Nick M. <ni...@zo...> - 2006-03-28 16:14:18
|
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 ni...@zo... |
From: <gr...@us...> - 2006-03-28 18:59:10
|
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 > thinking of Inkscape (which I've used to render script-generated SVG > into PNG). But Scribus is scriptable in python, so who knows. openoffice comes with python included. but i cant say oos layout is better than latexs. cheers -- |
From: Alan G I. <ai...@am...> - 2006-03-28 23:08:27
|
> 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 |
From: G. M. <g....@we...> - 2006-03-29 14:08:51
|
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 > misfeatures. I do not suggest that LaTeX is up to date or has a well designed user interface. But I still consider the output of LaTeX of excellent quality, especially in the field of science and math. Scribus ------- > 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. Inkscape -------- > I may have been thinking of Inkscape (which I've used to render > script-generated SVG into PNG). Inkskape could be an option too, as it can convert SVG to ps (and ps to pdf is easy with Ghostscripts ps2pdf). (You do not really want to produce PDF from PNG, will you?) You still need some script to convert reST (or XML) to SVG. Prince ------ An interesting alternative is http://www.princexml.com/, converting HTML + CSS to PDF. It is not free. The site offers a trial version for download. CSSToXSLFO and FOP ------------------ CSSToXSLFO (http://www.re.be/css2xslfo/) is a utility which can convert an XML document, together with a CSS2 style sheet, into an XSL-FO document, which can then be converted into PDF, PostScript, etc. with an XSL-FO-processor. It has special support for the XHTML vocabulary, because that is the most obvious language it would be used for. The tool has a number of page-related extensions. It also comes with an API in the form of an XML filter. The XSL-FO to PDF conversion could be done with the free tool FOP from Apache http://xml.apache.org/fop/. ReportLab --------- The ReportLab Open Source PDF library (http://www.reportlab.org/) is a Python library which could be used to produce a "native" PDF writer. Günter -- Milde ife.et.tu-dresden.de |
From: <gr...@us...> - 2006-03-29 19:37:53
|
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 handle everything one might do with Docutils. >>> 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. > > I do not suggest that LaTeX is up to date or has a well designed user > interface. But I still consider the output of LaTeX of excellent > quality, especially in the field of science and math. > Scribus > ------- > >> 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. > > Inkscape > -------- > >> I may have been thinking of Inkscape (which I've used to render >> script-generated SVG into PNG). > > Inkskape could be an option too, as it can convert SVG to ps (and ps to > pdf is easy with Ghostscripts ps2pdf). (You do not really want to > produce PDF from PNG, will you?) > > You still need some script to convert reST (or XML) to SVG. > > > Prince > ------ > > An interesting alternative is http://www.princexml.com/, converting HTML > + CSS to PDF. It is not free. The site offers a trial version for > download. > > > CSSToXSLFO and FOP > ------------------ > > CSSToXSLFO (http://www.re.be/css2xslfo/) is a utility which can convert an > XML document, together with a CSS2 style sheet, into an XSL-FO document, > which can then be converted into PDF, PostScript, etc. with an > XSL-FO-processor. It has special support for the XHTML vocabulary, > because that is the most obvious language it would be used for. The tool > has a number of page-related extensions. It also comes with an API in the > form of an XML filter. > > The XSL-FO to PDF conversion could be done with the free tool FOP > from Apache http://xml.apache.org/fop/. the sandbox of d.priest contains to my knowledge this piece. > ReportLab > --------- > > The ReportLab Open Source PDF library (http://www.reportlab.org/) is a Python > library which could be used to produce a "native" PDF writer. but reportlab isnt latex, so on emight have to add some whistles. cheers -- |
From: Ben F. <big...@be...> - 2006-03-29 22:19:39
|
"G. Milde" <g....@we...> 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 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 don't understand enough about LaTeX and associated tools to do this myself, nor am I interested in learning about it, which is why I'm looking for alternatives to avoid LaTeX altogether. > There is a script to facilitate pdf creation at > http://developer.berlios.de/projects/tex2pdf/ > that could serve as a base. Thanks, I'll see how far that gets me. > I do not suggest that LaTeX is up to date or has a well designed > user interface. But I still consider the output of LaTeX of > excellent quality, especially in the field of science and math. I'm bemused at the default selection of fonts, and the seeming inability to just use the far-better-supported TrueType fonts on my system. But that aside, the quality of a completed LaTeX rendering is good; getting there is the painful part. I also agree with others that good-quality PDF generation is hardly the exclusive domain of LaTeX any more. Not that this is necessarily the purpose of LaTeX; but if that's all I want from it, that's how I'll judge it as a tool in this process. > [enumeration of other possibilities] Thanks again for putting these in one post. Hopefully this discussion can lead to alternatives being better developed. -- \ "Experience is that marvelous thing that enables you to | `\ recognize a mistake when you make it again." -- Franklin P. | _o__) Jones | Ben Finney |
From: Roberto A. <ra...@kd...> - 2006-03-29 22:38:15
|
El Mi=E9rcoles, 29 de Marzo de 2006 19:18, Ben Finney escribi=F3: > "G. Milde" <g....@we...> 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 > 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 don't understand enough about LaTeX and associated tools to do this > myself, nor am I interested in learning about it, which is why I'm > looking for alternatives to avoid LaTeX altogether. Ok, this is **not** what you want. However, it may be a starting point: #!/bin/sh rst2latex --tab-width=3D2 --use-verbatim-when-possible --table-style=3Dbook= tabs=20 =2D-language=3Des \ =2D-stylesheet=3Dstyle.tex \ --graphicx-option=3Dpdftex --use-latex-toc --documentoptions=3D10pt,a4pape= r=20 =2D-output-encoding-error-handler ignor e docs.txt >docs.latex sed 's/\[gray\]{0.80}/{bg}/' docs.latex > docs.tmp && mv docs.tmp docs.latex # I have never seen pdflatex require more than 4 passes pdflatex docs.latex pdflatex docs.latex pdflatex docs.latex pdflatex docs.latex The style.tex mentioned is this: % donot indent first line. \setlength{\parskip}{5pt plus 2pt minus 1pt} %\documentclass[spanish]{article} %\usepackage[T1]{fontenc} %\usepackage[latin1]{inputenc} \usepackage{a4wide} \usepackage{fancyhdr} \pagestyle{fancy} %\usepackage{babel} \setlength\parskip{\bigskipamount} \setlength\parindent{0pt} %\usepackage{graphics} \def\thetitle{Manual Servidor de Correo - Intramed} \definecolor{bg}{rgb}{1,.98,.7} \setlength{\admonitionwidth}{0.5\textwidth} % sloppy % ------ % Less strict (opposite to default fussy) space size between words. Therefo= re % less hyphenation. % \sloppy % fonts % ----- % times for pdf generation, gives smaller pdf files. % % But in standard postscript fonts: courier and times/helvetica do not fit. % Maybe use pslatex. % \usepackage{times} % pagestyle %\pagestyle{headings} \lhead{\thetitle} %\rhead{Page \thepage} \rhead{Section \thesubsection} The bad side: Doesn't work as a pipe, assumes everything is in spanish, you can't change= =20 the name of the files, and it doesn't delete the temporary files. However, those are not rst or latex problems, those are script programming= =20 problems. So you may find a solution. =A0 =2D-=20 =A0("\''/").__..-''"`-. . =A0 =A0 =A0 =A0 Roberto Alsina =A0`9_ 9 =A0) =A0 `-. ( =A0 =A0).`-._.`) =A0r...@kd... =A0(_Y_.)' ._ =A0 ) `._`. =A0" -.-' =A0 KDE Developer (MFCH) =A0 _..`-'_..-_/ /-'_.' (l)-'' ((i).' ((!.' =A0 Buenos Aires - Argentina Imminentizing the eschaton since 1971. |
From: Martin B. <bl...@fu...> - 2006-03-30 06:07:28
|
On 3/29/06, Ben Finney <big...@be...> wrote: > "G. Milde" <g....@we...> 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 open source stuff, and never finished it. When I finish it, I will simply delete the temporary files in the source location. Also, the tool must be able to plop some custom input into the generated LaTeX file. I always find myself editing it by hand when I want to make a "nice" document. Another avenue that is on my todo list is a nroff writer. That would do the job for a lot of simple documents, and produce a different-looking output from that of LaTeX. 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? |
From: David G. <go...@py...> - 2006-03-30 14:30:22
Attachments:
signature.asc
|
[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). --=20 David Goodger <http://python.net/~goodger> |
From: <ra...@gm...> - 2006-03-30 08:04:05
|
on 30.03.2006 00:18 Ben Finney said the following: > "G. Milde" <g....@we...> 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 > 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). A number of latex distribution include a command called 'texify', at least miktex on windows does, I thought tetex had it too, but the (admittedly old) version I can see from here doesnt... 'texify --pdf --batch --clean --quiet' fulfils requirements 1, 3, and 5. 2 is trivial, I dare say. 4 is a real problem. a problem of the latex installation/configuration that is. A first idea: require the 'ucs' package to be installed and put:: \usepackage{ucs} \usepackage[utf8x]{inputenc} %this is an utf8 encoded file in the preamble (with a different encoding if you want) cheers, stefan |
From: Felix W. <Fel...@gm...> - 2006-05-14 14:10:37
|
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 |
From: Diego E. <de...@gm...> - 2006-05-19 17:17:50
|
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. The drawbacks are: 1. These CSS extensions are W3C Candidate Recommendations. They are not standard yet, and I don't know if they will ever be. 2. As I have said, support for CSSPP is very basic in browsers, and nonexistant in other free tools. 3. It is very hard to get the same quality that LaTeX provides, especially for math. Prince provides a sample PDF[4] with math expressions described in XML. Compare it with any LaTeX article. [4] http://www.princexml.com/samples/math.pdf Just my two cents. I've been using LaTeX for a while, I recently discovered ReST and I think that a simple and functional rst2pdf would just kick ass ;) Regards, Diego Essaya On 5/14/06, Felix Wiemann <Fel...@gm...> wrote: > 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. |
From: <gr...@us...> - 2006-05-20 17:33:02
|
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 -- |
From: Felix W. <Fel...@gm...> - 2006-05-20 11:43:24
|
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 number of hoops each project makes a contributing user go through." -- ESR |
From: Diego E. <de...@gm...> - 2006-05-20 20:53:11
|
On 5/20/06, Felix Wiemann <Fel...@gm...> 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 |
From: Beni C. <cb...@us...> - 2006-05-20 18:02:43
|
On 5/20/06, Felix Wiemann <Fel...@gm...> 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 <cb...@us...>, who can only read email on weekends. Governments are like kernels - everything possible should be done in user space. |
From: Marcelo G H. <mar...@gm...> - 2006-05-20 22:06:48
|
El 20/05/2006 a las 15:02, Beni Cherniavsky <cb...@us...> 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 :-( Also, the only time I tried (years ago) I had a problem with the nesting of structures required to enclose the different parts of a Lout document and how to ascertain which document level a certain title is in from inside the docutils machinery. -- o-=< Marcelo >=-o |