Re: FOP producing BLANK PDFs on 1 of 4 servers

2005-11-23 Thread Simon Burton
We are using J2SE 1.4.1_04, Tomcat 3.3.1 and mod_jk (not sure what version)

I have as of yet been unable to download on the command line using wget or lynx 
as our system requires username/password logon/authentication and does html 
redirects so have not yet found a way to actually download the PDF using these 
methods (just get the redirect page downloaded).

If I download and save the PDF's from acrobat the correct one is 45kb and the 
incorrect one is 78kb, however I did spot a small clue which is Acrobat 
displays a dialog for a split second when the blank one is loading which is 
entitled Rebuild with the text This file is damaged but is being repaired. 
(had to record the screen as an AVI and play back in slo-mo to read it!)

Thanks for the help so far, I will write some java to save the 
correct/incorrect PDF's in their raw form as served up (rather than after 
saving from acrobat which is what I have now) - maybe this will give me some 
clues.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FOP producing BLANK PDFs on 1 of 4 servers

2005-11-22 Thread Jeremias Maerki
You don't say what JDK you're using. Maybe changing that will help. Or
changing the webcontainer. As you figured out yourself, this could be a
platform problem. To rule out that it's a FOP problem you could try to
deploy the FOP sample servlet (in the examples/servlet directory in the
0.20.5 distribution).

You could also try to download a PDF to the file system using wget and
then compare the file that is returned by the Suse system with the one
from the RedHat system. This can be used to rule out problems on the
client side.

You can of course configure additional log output. Please refer to the
Cocoon documentation for that.

Good luck!

On 22.11.2005 17:48:40 Simon Burton wrote:
 We are using the latest fop version (0.20.5) and have a working solution 
 (apache/cocoon/fop using xsl stylesheet and xml to create a PDF served up 
 directly in the browser) on 3 of our servers but when running against the 4th 
 server the PDF is always blank.
 A PDF is served in the browser via acrobat and it has the expected number of 
 pages but all the pages are completely blank.
 
 Server: Working ones: Suse 9 / Problem one: RedHat 9 (Server Kernels all 
 2.4.26)
 FOP: 0.20.5 + Cocoon
 Client: IE 6.0.2900 on Windows XP Pro SP2 AND Firefox 1.5 on Suse Linux 9.3
 Adobe Acrobat: 7.0.2 (Windows) / 7.0.1 (Linux)
 
 Obviously the main difference is that the problem server is using RedHat, but 
 so far we have been unable to figure out why this is happening.
 
 We have tried the following:
 - Copying all our jars from working server to problem server (just in case 
 there were differences)
 - Manually running fop on the command line using the same xsl stylesheet and 
 xml output as server - this generates the PDF correctly.
 - Turning on fop debug - no revealing info
 - Tried googling, searching the mail archives and bugzilla - no luck yet
 
 
 Is there anything we can do to trace the cause of this problem - addtional 
 debug on fop/cocoon or whatever?
 Thanks.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: FOP producing BLANK PDFs on 1 of 4 servers

2005-11-22 Thread J.Pietschmann

Simon Burton wrote:

We are using the latest fop version (0.20.5) and have a working
solution (apache/cocoon/fop using xsl stylesheet and xml to create a
PDF served up directly in the browser) on 3 of our servers but when
running against the 4th server the PDF is always blank. A PDF is
served in the browser via acrobat and it has the expected number of
pages but all the pages are completely blank.


First step: download the PDF with a command line utility and try
to open the downloaded PDF. If it is ok, the problem is probably
the client browser/Acrobat combo or the triple
webserver/browser/acrobat. You might need a HTTP header sniffer
in order to detect differences.
If the downloadad PDF from the forth server still has blank pages,
download one of the working PDFs and compare the files. If the
non-working PDF is shorter, check whether it has been truncated.
If so, you probably have a problem with the JVM on the server or the
servlet run time.
BTW the really interesting data are:
- Brand  version of the JDK/JRE
- Brand and version of the servlet container
- Version of the servlet container connector, if there is an Apache
 in front. There are versions in the wild which truncate output.
Anyway, you'll probably better ask further questions in a forum more
related to web applications.

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]