FOP producing BLANK PDFs on 1 of 4 servers

[Simon Burton <ap...@codlord.com>]

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: FOP producing BLANK PDFs on 1 of 4 servers

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: FOP producing BLANK PDFs on 1 of 4 servers

[Simon Burton <ap...@codlord.com>]

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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: FOP producing BLANK PDFs on 1 of 4 servers

[Simon Burton <ap...@codlord.com>]

Thanks for the advice and ideas people but we never did find a solution to this problem - we rebuilt the server with Suse in the end! (was meant to be done anyway) and now it works as do the others.

Just thought I would update/close the thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: FOP producing BLANK PDFs on 1 of 4 servers

["J.Pietschmann" <j3...@yahoo.de>]

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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org