le 03.02.2009 03:26 Jim Steil a écrit:
> Remi Jolin - SysGroup wrote:
>> Hello,
>>
>> le 02.02.2009 17:27 Jim Steil a écrit:
>>   
>>> Hi
>>>
>>> I use the following code to display PDF files.  This has worked for me 
>>> for a couple years.  All of a sudden, this stopped working for some of 
>>> our PDFs.  Some display correctly, but some do not.  This happens only 
>>> on my production box (Win 2003), but works fine on my test/dvlp 
>>> environment (WinXP).  I don't even know where to begin trying to debug 
>>> this.  No errors are thrown.  In the browser, it's as if the document 
>>> displayed, but it really didn't.  The title has changed to the one that 
>>> should be displayed, but the page never changes.  It is not still 
>>> processing, but just seems to have forgotten to display the PDF.  This 
>>> is happening on all clients trying to connect, whether using IE or 
>>> Firefox. 
>>>
>>>     def documentDisplay(self, *args, **kw):
>>>         documentId = args[0]
>>>         doc = Document.get(documentId)
>>>        
>>>         pdfFile = StringIO.StringIO()
>>>         resourceDir = cherrypy.config.get('motion.resourcedir')
>>>         f = open('%sdocuments/%s' % (resourceDir, doc.documentName), 'rb')
>>>        
>>>         while 1:
>>>             data = f.read(1024*8)
>>>             if not data:break
>>>             pdfFile.write(data)
>>>         f.close()
>>>        
>>>         pdf = pdfFile.getvalue()
>>>         pdfFile.close()
>>>        
>>>         return(pdf)
>>>
>>>   
>>>     
>> You could first check the length of the 'pdf' variable... Is it coherent 
>> with the actual length of the file ?
>>
>> Are you PDFs static or generated dynamically on the fly just before 
>> displaying them. In that case it could be a "flush" issue of the 
>> generated file not closed (so not flushed) to the disk while you try to 
>> read it.
>>
>> And I was just wondering why you use a StringIO and not directly
>> pdf = f.read()
>>
>>
>>
>>   
> Remi, thanks for your reply.
>
> The short answer is because that is what I copied from someone else's 
> code.  I implemented the change you suggested, but it made no 
> difference. 
I did not meant it would change anything...
>
> I should have mentioned that this is happening when I display PDFs 
> from a number of different creation methods.  I use this method to 
> display PDFs from a library of documents that we have but I also 
> generate PDFs on the fly using ReportLab.  Again, it is an 
> inconsistent problem. After more digging, it appears as though it is 
> related to the size of the document that I'm trying to display.  I 
> have successfully displayed all documents 976 KB or smaller but cannot 
> display any files that are 1050 KB or larger.  Anyone have any idea 
> where I can begin debugging this issue?
Ok, but again, can you trace the length of 'ftp' (it should give the 
size of the file) to check if it comes from the file or the transmission.

And can you tell us a bit more about the expose decorator you use and 
anything you use to modify the http header...
>
> After my first post I noticed I didn't have the same TG environment on 
> both systems.  I've upgrade both systems to TG 1.0.8 and still have 
> the same behavior, works in my dvlp environment, but not production.  
> Again, this has worked in production for a over a year and all of a 
> sudden quit working.  No changes were made to the box except for 
> Windows patches.
>
>     -Jim
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to