On Nov 7, 3:56 pm, "Edward K. Ream" <[email protected]> wrote:
> On Mon, Nov 7, 2011 at 3:30 PM, Josef <[email protected]> wrote:
> > Sorry, but trying anything newer will have to wait - no time at the
> > moment.
>
> No rush. leo_pdf probably works as well now as it ever has. Not sure
> how many people actually use it.
Leo should do more to make it easy to generate PDF files from Leo
outlines.
Last night and earlier this morning I spent several hours running
Leo's tutorial chapter through leo_pdf.py. I uncovered several
problems, some of which I fixed. The new code is on the trunk.
The question arises: "what is the best way for Leo to support PDF?"
There seem to be two paths:
1. Fix leo_pdf.py. I am having my doubts about this.
For starters, I don't even know who wrote the original version.
Engelbert Gruber's may, or may not, have written the initial version
of leo_pdf.py. What *might* have happened is that I took some of his
code and turned it into a Leo plugin. Then again, he might have
written the plugin. I just don't know.
In any case, reportlab and platypus are not that easy to use. I'm
looking for another way.
2. Use Leo's rst3 command to create an intermediate rST file, and send
that file to rst2pdf. It is trivial to generate the intermediate rST
file: just set the following in the @rst node for x.pdf::
@ @rst-options
call_docutils=False
generate_rst=True
rst2pdf *also* uses reportlab, but there is a big difference: unlike
leo_pdf.py, rst2pdf is under active development. That is, it doesn't
rely on me to move forward ;-)
Of course, using rst2pdf adds another step to the tool chain, but it
would be straightforward to automate the toolchain use external
processes.
Your comments please.
Edward
P.S. Last night, as a "hobby" I downloaded the specs for pdf and
postscript:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
http://www.adobe.com/products/postscript/pdfs/PLRM.pdf
The former is 748 pages; the latter is 912 pages. Obviously, I did
little more than scan these documents.
The relation between Postscript and PDF is surprising. From section
1.4.4 of the Postscript doc:
QQQ
PDF and the PostScript language share the same underlying Adobe
imaging model. A document can be converted straightforwardly between
PDF and the PostScript language; the two representations produce the
same output when
printed. However, PDF lacks the general-purpose programming language
framework of the PostScript language. A PDF document is a static data
structure that is designed for efficient random access and includes
navigational information suitable for interactive viewing.
QQQ
Opening a PDF in Scite is a very different experience from opening a
PostScript file. The former is (mostly) a binary file with
interspersed text headers; the latter is mostly text.
I was (am) astounded that the two may be "straightforwardly"
converted. I have no idea how.
Anyway, the point is that all this good technology is much too good to
ignore.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
