|
Benjamin Lorteau
Member since:
03 July 2008
Posts: 6
|
Tuesday 27 October 2009 3:35:54 am
Hello,
I'm having a problem with paradoxPDF juster after purging the cache with the CLI command
php bin/php/ezcache.php --clear-all --purge
If I request a PDF creation, the downloaded file is empty, thus unreadable. But if I request the same PDF creation (with PDFCache=enabled), the new downloaded file is correct.
I checked the paradoxpdf.log, but the conversion went well, which would explain the correct file on the second try.
I also tried without PDFCache enabled, it works fine every time, even after a cache purge.
Last but not least, I tried to clean the caches without purging, and again it works fine, even with PDFCache enabled.
The problem is pretty specific, but I thought it would be worth mentioning it, just in case.
|
|
|
Karnichi Mohamed
Member since:
11 February 2008
Posts: 72
|
Wednesday 28 October 2009 4:57:24 am
Hi Benjamin,
Do you encounter the same problem when clearing cache from admin interface ?
Thanks
|
|
|
Benjamin Lorteau
Member since:
03 July 2008
Posts: 6
|
Tuesday 10 November 2009 7:26:27 am
No, as I said, when clearing the cache without purging, everything works perfect. The problem arises only when clearing caches from command line with the --purge option.
It's not a really big deal, as I didn't heard from the client since he tested the PDF generation, however there is still a real bug in your extension. Very specific, but still present.
|
|
|
Rene Hrdina
Member since:
18 February 2009
Posts: 4
|
Thursday 21 January 2010 7:43:09 am
Hi,
i have the same problem.
Mohamed, did you already find out what causes the problem?
It only happens when pdfCache is enabled, by the way. My guess is that the files are not purged properly and therefore Paradoxpdf thinks the file has already been cached. Then it sends out the 0-Byte File to the Browser which causes an error.
regards
René Hrdina
|
|
|
Karnichi Mohamed
Member since:
11 February 2008
Posts: 72
|
Thursday 21 January 2010 3:19:31 pm
Hi Rene,
Could you please checkout code on the trunk. And tell me if the issue is fixed ?
Thanks
|
|
|
Rene Hrdina
Member since:
18 February 2009
Posts: 4
|
Tuesday 26 January 2010 6:49:19 am
Hi,
i'm using the latest version from trunk and when pdf caching is turned on it paradoxpdf.ini i have the following problem:
On first pdf creation i get a 0 byte-PDF File on MAC and PC. On a linux client it works fine (although this does not make sense to me, but it's a fact).
All future calls to the pdf file work fine (pdf file returned from cache then).
When caching is turned off in paradoxpdf.ini everything works fine. So that's why i think this issue is related to the one mentioned above.
regards
|
|
|
Gwenal Le Bihan
Member since:
09 January 2008
Posts: 3
|
Thursday 18 February 2010 9:27:03 am
Hello,
I'm having the same problems too. /var/paradoxpdf/ contains xhtml files and related pdf files with empty size. Second click gives you the right pdf files..
Regards
Gwen
|
|
|
Karnichi Mohamed
Member since:
11 February 2008
Posts: 72
|
Sunday 11 April 2010 6:13:00 am
Hi guys
Sorry for the delay. My work does not leave me much time...
I've fixed this bug is in 2.1.5 version
Enjoy
|
|
|
Thierry Clément
Member since:
05 January 2010
Posts: 1
|
Tuesday 11 May 2010 9:16:40 am
Hello,
I am a new user of the "paradoxPDF" extension and I experienced the same pb. as described :
In my case, the generation was working OK with PDFCache=disabled ; and - if set to "enabled", the first invocation of PDF generator would always provide an error like "format error : not a PDF or corrupted" in the browser
In fact, a good PDF file is generated in the var/sitename/log directory.
I think I found the cause of the problem, which still remains in 2.1.5 version of paradoxPDF :
in classes/paradoxpdf.php, the computed size of the document is not returned in $handler->size(); at line 117 and so the http result is 0 bytes.
I changed the value of $size in that case with strlen($data) which I set inside the block beginning with
if ($data instanceof eZClusterFileFailure || $handler->size() == 0) {
Could Mohamed Karnichi verify if this correction seems OK ? (I could send my modified source by email if necessary)
Thierry
|
|
