Appy

Strange string replacement issue

Asked by Arnaud

Hello

In my odt model I wrote this :
"do section- for p in listePages"

listePages is a python indexed array containing the values to insert into each page.

each page has a "SOCLOGO" value that is strictly the same for every page : "logo_groupe_defaut_fr.jpg"

I use this code to insert a picture on top of each page :
do text if len(p['SOCLOGO'])>0
from document(at='/netapp/mixte/python/publipostage/compta/relances/media/%s' % p['SOCLOGO'], anchor='as-char')

This works well for the first pages, but with large document rendering, after several tests I always face an issue starting page 232:
Error while evaluating the expression "document(at='/netapp/mixte/python/publipostage/compta/relances/media/%s' % p['SOCLOGO'], anchor='as-char')" defined in the "from" part of a statement.
File "<string>", line 1, in <module>
File "/usr/lib/python2.6/dist-packages/appy/pod/renderer.py", line 285, in importDocument
imp = importer(content, at, format, self.tempFolder, ns)
File "/usr/lib/python2.6/dist-packages/appy/pod/doc_importers.py", line 56, in __init__
self.importPath = self.moveFile(self.at)
File "/usr/lib/python2.6/dist-packages/appy/pod/doc_importers.py", line 206, in moveFile
shutil.copy(at, res)
File "/usr/lib/python2.6/shutil.py", line 88, in copy
copyfile(src, dst)
File "/usr/lib/python2.6/shutil.py", line 53, in copyfile
fdst = open(dst, 'wb')
<type 'exceptions.IOError'>: [Errno 36] File name too long: u'/netapp/mixte/python/publipostage/compta/relances/tmp/ag.doc.temp/unzip/Pictures/logo_groupe_defaut_frggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg.jpg'

That's strange because if I temporarily display the p['SOCLOGO'] value as-is in the pages it is OK, "logo_groupe_defaut_fr.jpg" and not "logo_groupe_defaut_frggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg.jpg".

Where can it come from ? Looks like a memory issue.

You can get the generated file here : http://ageslin.free.fr/divers/ag2.doc
(I remove the logos on first pages for confidentiality and removed the first pages, left some of the good ones then firsts of the wrong ones).

Any help would be much appreciated, we face this issue on a production system for many employees.

Thank you
Arnaud

Question information

Language:
English Edit question
Status:
Solved
For:
Appy Edit question
Assignee:
No assignee Edit question
Solved by:
Arnaud
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Marc Dubrowski (marc-dubrowski) said : 		#2

Hello Arnaud,

Froml what I see, your image file is copied in the temporary document for each page. And to avoid confusion with the name, it adds a "g" at each new file. The error you get comes from python because there is a limit of 256 chracters for a file name on your filesystem. And the error appears at page 232 because logo_groupe_defaut_fr.jpg is already 25 characters long. 232+25=257. Bam! File name too long!

My guess, but it must be confirmed, is that you should create a header in your template wher you would add the file. It would be up to Openoffice to repeat the header on each page, not to appy.pod.

Revision history for this message
Arnaud (arnaudgeslin) said : 		#3

Hello Mark

Thank you for your explanation. Your "header" workaround does not suit our need because the image is not necessarily the same on all pages.

But Gaëtan told me this bug is fixed in the newest release of Appy. Pod, I installed it on a test server and will tell you asap if we face again this issue or not.

Revision history for this message
Arnaud (arnaudgeslin) said : 		#4

After some tests I confirm this issue is fixed when installing the latest Pod release.

Thanks