On 3/02/2012 10:13 PM, Theresa Jayne Forster wrote:
The stacktraces were added to allow me to quickly debug without
trapesing through the mega log that log4J is spewing out from the
whole system (I know its wrong hell I cringe whenever I see some of
the code but it is based on the old system just upgraded for Fop 1.0
as the old system was 0.23 with a handful of custom addons like
accepting font-weight="bold" and z-index="2" to using a bare 1.0
OK, but either way you're still ignoring the exceptions. That was just
as wrong before the printStackTrace calls were added as it is now.
UPDATE: Tried on 0.95-1 and 0.95 (the latter needed the Avalon framework
adding manually to the pom)
Still does not work, any suggestions why I am getting a pdf that works in a
3rd party viewer and not in adobe.
Because you are getting an incomplete, damaged PDF. Some viewers manage
to cope with it, others do not. When I open the file in a hex editor (or
a decent text editor) I can see that it ends at an `endobj', not with a
proper xref dictionary and trailer.
What *should* be happening is that when fop hits whatever error prevents
it from finishing generating the PDF it throws an exception. Your app
should catch that exception, delete the temporary file, and rethrow the
exception or handle it within your app's error handling and reporting
framework. Logging and ignoring the exception is *incorrect*.
You have still not confirmed whether or not fop is throwing an exception
when generating this file. Please confirm whether fop actually throws an
exception when generating this file.
If fop *does not *throw an exception, there is a fop bug.
If fop *does *throw an exception, there is a bug in your code.
--
Craig Ringer
