import error for leo_pdf
Josef
when I try to run the rst3 command on a line like: @rst foo.pdf I
get:
Traceback (most recent call last):
File "/home/dalcolmo/programs/Leo-4.9-final/leo/core/leoRst.py",
line 1891, in writeToDocutils
settings_overrides=overrides)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 398, in
publish_string
enable_exit_status=enable_exit_status)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 641, in
publish_programmatically
pub.set_components(reader_name, parser_name, writer_name)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 97, in
set_components
self.set_writer(writer_name)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 86, in
set_writer
writer_class = writers.get_writer_class(writer_name)
File "/usr/lib/pymodules/python2.6/docutils/writers/__init__.py",
line 132, in get_writer_class
module = __import__(writer_name, globals(), locals())
ImportError: No module named leo_pdf
This seems to have worked before - at least a few months ago. And I
have definitely a leo_pdf.py file in the plugins folder! Any quick
ideas what went wrong? - I don't have time for a long investigation
right now.
Edward K. Ream
> Warning, I am still using plain old Leo-4.9
>
> when I try to run the rst3 command on a line like: @rst foo.pdf I
> get:
Happens with the present code as well. I'll investigate soon.
Edward
Edward K. Ream
Fixed on the trunk at rev 4720. I had forgotten I was responsible
(2005) for the initial port of Engelbert Gruber's code for the rst3
plugin, presumably because I didn't spend much time on it. Six years
from now I may well have forgotten all about today's work...
I tested the code using Python 2.6, because that was all that was
available from the open source download page of reportlab:
http://www.reportlab.com/ftp/ As noted below, I copied code from
stylesheet.py, obtained from: #
http://docutils.sourceforge.net/sandbox/dreamcatcher/rlpdf/
Please read the checkin log in the Post Script carefully. There is
not now, nor has there ever been, a great deal of support for the
module. If you want enhancements you would be well advised to develop
them yourself.
Edward
P.S. Here is the checkin log:
QQQQQ
Updated leoRst code to handle revised leo_pdf.py module. Trivial test
passes, but there are no promises.
Here is the updated version history from leopdf.py:
1.0 EKR 2011/11/03:
- Various changes to come accomodate docutils changes.
- Added dummy Reporter class for use by get_language.
- I suspect this should be logger class, but I don't much care.
- Incorporate getStyleSheet from stylesheet.py, obtained from:
http://docutils.sourceforge.net/sandbox/dreamcatcher/rlpdf/
Note: passing writer_name = leo.plugins.leo_pdf to docutils does not work,
presumably because __import__('leo.plugins.leo_pdf') returns the *leo* module,
and docutils seems not to be aware of this fact.
As a workaround, the new rst3 code passes writer = Writer() (an
instance) instead.
QQQQQ
EKR
Josef
Unexpected docutils exception
1906, in writeToDocutils
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 398, in
publish_string
enable_exit_status=enable_exit_status)
publish_programmatically
output = pub.publish(enable_exit_status=enable_exit_status)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 205, in
publish
output = self.writer.write(self.document, self.destination)
File "/usr/lib/pymodules/python2.6/docutils/writers/__init__.py",
line 76, in write
self.translate()
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
line 680, in translate
visitor = PDFTranslator(self,self.document)
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
line 807, in __init__
self.language =
docutils.languages.get_language(doctree.settings.language_code,self.reporter)
TypeError: get_language() takes exactly 1 argument (2 given)
done
my file consists of:
+@rst foo.pdf
####
Foo
####
- heading1
blabla
- Josef
Edward K. Ream
>> Fixed on the trunk at rev 4720. I had forgotten I was responsible
>
> I just pulled rev 4739 and I get now:
> docutils.languages.get_language(doctree.settings.language_code,self.reporter)
> TypeError: get_language() takes exactly 1 argument (2 given)
Well, this is interesting. get_language takes 2 arguments in the
version of docutils I am using. I suppose the code is going to have
to try it both ways.
This is a docutils screw-up: imo the new api should have been upward
compatible with the old. It would have been easy to do: just make the
new second argument optional.
Oh well...I'll fix this soon.
Edward
Edward K. Ream
> get_language takes 2 arguments in the version of docutils I am using. I suppose the code is going to have to try it both ways...I'll fix this soon.
Done at rev 4744. The previous unit tests still passes, but of course
that doesn't mean much. Please let me know how the code works for
you.
Edward
Edward K. Ream
>
> > get_language takes 2 arguments in the version of docutils I am using. I suppose the code is going to have to try it both ways...I'll fix this soon.
>
> Done at rev 4744. The previous unit tests still passes, but of course
> that doesn't mean much. Please let me know how the code works for
but it only runs on Python 2.x. The test now warns when it actually
doesn't do anything, so this shouldn't happen again.
Edward
Josef
Unexpected docutils exception
Traceback (most recent call last):
File "/home/dalcolmo/programs/leo-editor/leo/core/leoRst.py", line
1906, in writeToDocutils
settings_overrides=overrides)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 398, in
publish_string
enable_exit_status=enable_exit_status)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 646, in
publish_programmatically
output = pub.publish(enable_exit_status=enable_exit_status)
File "/usr/lib/pymodules/python2.6/docutils/core.py", line 205, in
publish
output = self.writer.write(self.document, self.destination)
File "/usr/lib/pymodules/python2.6/docutils/writers/__init__.py",
line 76, in write
self.translate()
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
self.document.walkabout(visitor)
File "/usr/lib/pymodules/python2.6/docutils/nodes.py", line 173, in
walkabout
if child.walkabout(visitor):
File "/usr/lib/pymodules/python2.6/docutils/nodes.py", line 186, in
walkabout
visitor.dispatch_departure(self)
File "/usr/lib/pymodules/python2.6/docutils/nodes.py", line 1617, in
dispatch_departure
return method(node)
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
line 1044, in depart_title
self.putTail(b.start,style=b.style)
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
line 1265, in putTail
style=style,bulletText=bulletText)
File "/home/dalcolmo/programs/leo-editor/leo/plugins/leo_pdf.py",
line 1108, in createParagraph
style = self.styleSheet.get(style)
AttributeError: StyleSheet1 instance has no attribute 'get'
Edward K. Ream
> line 1108, in createParagraph
> style = self.styleSheet.get(style)
> AttributeError: StyleSheet1 instance has no attribute 'get'
Thanks for this report. I'll fix this today, and (presumably) add a unit test.
It may take a few more iterations before things settle down
completely, due to differing environments, but we'll get the job done
eventually.
Edward
Edward K. Ream
> On Mon, Nov 7, 2011 at 11:07 AM, Josef <joe...@gmx.net> wrote:
>> with rev 4747 I get:
> [snip]
>> line 1108, in createParagraph
>> style = self.styleSheet.get(style)
>> AttributeError: StyleSheet1 instance has no attribute 'get'
>
> Thanks for this report. I'll fix this today, and (presumably) add a unit test.
I'm not sure it would be wise to attempt a fix in leo_pdf.leo.
The code works with reportlab-daily.win32-py2.6.exe. What version of
reportlab are you using? What happens when you upgrade to a recent
version?
Edward
Josef
python 2.6.5
python-reportlab 2.4-1
python-reportlab-accel 2.4-1
- Josef
On Nov 7, 8:39 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
Josef
On Nov 7, 10:09 pm, Josef <joe...@gmx.net> wrote:
> My system is Ubuntu 10.04 LTS:
> python 2.6.5
> python-reportlab 2.4-1
> python-reportlab-accel 2.4-1
>
moment.
- Josef
Edward K. Ream
> 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.
EKR
Edward K. Ream
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
mdb
I vote for using rst2pdf
This looks similar to using latexpdf
and the option to convert rst to latex as
another step remains possible
(to leverage latex's abilities)
Edward K. Ream
>> Your comments please.
>
> I vote for using rst2pdf
Thanks for your vote. I'm leaning the same way. I think using
standard tools wherever possible is a big improvements over hacks like
leo_pdf.py.
> This looks similar to using latexpdf
> and the option to convert rst to latex as
> another step remains possible
> (to leverage latex's abilities)
That option is always possible, regardless of whether leo_pdf.py exists or not.
Edward
Josef
On Nov 8, 3:00 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
> 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.
in more recent versions much of it is compressed, hence looking like
binary data. There may also be embedded pixel images etc.
Some features of PDF simply do not map well to Postscript: for
example, while links or bookmarks make sense in an electronic
document, Postscript is intended for print only and does not have
these features.
- Josef
Offray Vladimir Luna Cárdenas
I second this vote also. My toolchain previously include converting leo
trees to rst using @auto-rst (for some reason rst command never worked
for me properly on my version of Leo), then use rs2pdf to convert the
file properly. Now I'm using rst2latex and pdflatex to get more control
on the pdf output. Leo is a great tool for the creation of your
personalized toolchain for working with data and having a lot of
developments in pythons liks rst2pdt helps with this greatly.
Cheers,
Offray
HansBKK
let me know and I'll try to refrain in future. . .
> On Tue, Nov 8, 2011 at 9:49 AM, mdb <mdbol...@gmail.com> wrote:
> > I vote for using rst2pdf
>
> Thanks for your vote. I'm leaning the same way. I think using
> standard tools wherever possible is a big improvements over hacks like
> leo_pdf.py.
I'm also looking to build this type of toolchain: Leo as the container/
generator and meta-organizer for a tree of plaintext docs. I was
thinking of Leo as just outputting the alternative select/sequencing
paths of output, but now see that it can also manage the external
tools that will be converting the single-source files to their target
(in some case intermediate) filetypes. Although I'm no coder, Leo's
tremendous value may spur me to dip my toes in that water with a bit
of Python scripting if that becomes necessary, although I'm hoping to
stick with batch files/bash scripts if at all possible.
I assume the basics are doc'd on triggering such scripts and external
CLI utility tools to run against individual files, so I'll ask the
higher-value question:
In the case where files are as likely to be modified outside of Leo as
in, is there a way to have Leo check for their modified status in a
whole branch of subdirs, triggering the external executable to run
against any files that been modified? I'd rather not have to re-
generate a whole tree when just a few files are getting changed at any
time.
Or alternatively, does anyone know of a generalized helper utility for
this that would work outside of Leo to:
- watch a dirstruc hierarchy
- track the timestamps of the source files
- run an arbitrary script/executable against and any new or changed
files
Could be windoze or linux, the file trees are getting sync'd around
anyway via unison
Thanks in advance. . .
Terry Brown
> From: HansBKK <han...@gmail.com>
> Or alternatively, does anyone know of a generalized helper utility for
> this that would work outside of Leo to:
>
> - watch a dirstruc hierarchy
> - track the timestamps of the source files
> - run an arbitrary script/executable against and any new or changed
> files
`make`? Or `scons`, if you want to use python. Either would need to be able to see the output of the script to see notice that the input was fresher than the output.
Cheers -Terry
HansBKK
I've only heard of make in relation to compiling program code from source, but I'll checking it out for this type of usage - links to starting-point howtos for non-programmers would be greatly appreciated.
Does it have the "watch a dirtree for new / changed-since-last-run" functionality built in, or does that require somethings else, say running in cron?
Terry Brown
Terry Brown
From: HansBKK <han...@gmail.com>
To: leo-e...@googlegroups.com
Cc: Terry Brown <terry_...@yahoo.com>
Sent: Monday, December 5, 2011 9:16 PM
Subject: Re: import error for leo_pdf
**wow** that was quick! I'll start googling, below only for those with extra time on their hands 8-)
I've only heard of make in relation to compiling program code from source, but I'll checking it out for this type of usage - links to starting-point howtos for non-programmers would be greatly appreciated.
Does it have the "watch a dirtree for new / changed-since-last-run" functionality built in, or does that require somethings else, say running in cron?
--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/j6bQIbLIzqoJ.
To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
HansBKK
Make looks like the tool for what I want, just a bit of an overly steep learning curve for what I'm trying to do, but that'll come in handy next time I'm looking to avoid getting real work done 8-) If I haven't come across a user-friendlier tool in the meantime I'll dig into the below when the time comes. Thanks for the pointer. . .
---------------------------
FFR by future googlers, here are some notes I've made on learning more about make ("GNU make" is a more useful search term than the plain-English word by itself)
any process that involves transforming a source file to a target result (by executing arbitrary commands) is applicable to Make
tracks changed files, make updates a target if it depends on prerequisite files that have been modified since the target was last modified, or if the target does not exist.
decides whether a target needs to be regenerated by comparing file modification times. This solves the problem of avoiding the building of files which are already up to date, but it fails when a file changes but its modification time stays in the past - can force rebuild of all if in doubt
example: detect a change made to an image file (the source) and the transformation actions might be to convert the file to some specific format, copy the result into a content management system, and then send e-mail to a predefined set of users that the above actions were performed.
-j and -l for regulating load utilitization, parallel processing
generated files should never be put under version control
Ideally, all of the source files should be in a directory called 'src' in the project directory, with all of the other files (such as Makefiles, configure scripts, and READMEs) separate at the top.
Makefile
non-recursive Makefile rules makes things simpler and allows faster builds
http://www.elitecoders.de/mags/cscene/CS2/CS2-10.html
http://www.gnu.org/software/make/manual/make.html
http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
http://www.robots.ox.ac.uk/~tgtjr/makefiles.html
ebook available for: OReilly Practical Development Environments Sep 2005
also check out makeinfo, part of Texinfo package
http://www.linuxjournal.com/article/2840
Matt Wilkie
> My apologies if resurrecting old threads is frowned upon here, if so
> let me know and I'll try to refrain in future. . .
For what it's worth, I've seen more resurrections on this mailing list
than any other I participate in. It's part of why I stick around,
good ideas don't lie fallow forever. :)
cheers,
--
-matt