On Mon, 2001-09-10 at 05:48, Dieter Maurer wrote: Excellent help thank you Dieter.
Object ids can have '.' in them. However, you cannot directly use such ids as names in Python expressions, you need to use "_.getitem('name.with.dot')".
Done.
.... thefile=open('aaa123','w') thefile.write(inputdoc.data) thefile.close This is a bit dangerous, although probably not your problem...
"OFS.Image.File.data" is a string, as long has the file is sufficiently small. It becomes an object for larger files. Use "str(inputdoc.data)" instead.
Done. The line now reads thefile.write(str(inputdoc.data))
# Run wvPDF on the document os.system('wvPDF aaa123 aaa123.pdf')
return If you call the external method directly (from the Web) and you do not return a value, some browsers do not recognize the end of the request. Return, e.g. "Done".
Done. It reads Return 'Doc2PDF Completed'
aaa123 is a word document. Can anyone see what has gone wrong? Not yet...
... Before the external command wvPDF is run I can confirm that the word document (named aaa123) is sitting in the directory /var/tmp/xxxxxxxxx/. I can manually run wvPDF as user www-data. On the file created by the external method?
Exactly. I can su - www-data (to hopefully emulate the zope environment) and then manually run "wvPDF aaa123.doc aaa123.pdf". It takes about 5 seconds for the conversion to complete. I have checked that the created file is exactly the same as the original (using cmp). Here is some info about what goes wrong (snapshot of the disk while the command is churning): ls -l -a: total 57 drwxr-xr-x 2 www-data www-data 157 Sep 10 12:10 . drwxrwxrwt 3 root root 60 Sep 10 12:08 .. -rw-r--r-- 1 www-data www-data 24576 Sep 10 12:08 aaa123.doc -rw-r--r-- 1 www-data www-data 39 Sep 10 12:08 aaa123.pdf.ps.dvi.tex What is fascinating here is: (1) the file size of aaa123.doc is wrong! It should be 27136. (2) the right file of 27136 does occur when commenting out the wvPDF system command! (3) the right file size appears after wvWare is killed (this is the Word View Ware, not VMWare). (4) wvWare grows very quickly to consuming 500MB of memory and upwards. (5) I can killall wvWare and then stop and restart zope without having to restart the computer. (6) The script returns this message at the console when killall wvWare: "Could not convert into PS". While the script is runing I tried manually running wvPDF on the file. The same churning loop occurred. Once I had killed wvWare I was able to run the same command fine. My poor deduction at this stage: the file doesn't appear to close properly before wvWare is run. There may be a bug in the version of Zope or Python I am using [Zope 2.3.3 (source release, python 1.5.2, linux2)]. I'd love to be able to upgrade to see if that solves the problem but the maintainer of Zope and Python for Debian unstable has been busy for a long while: http://lists.debian.org/debian-python/2001/debian-python-200109/msg00003.htm... And it looks like a difficult upgrade. Regards, Adam