Java error with FO

[LynnHales]

I'm playing with some changes to the 40051 FO that we're working for LOGSA. Trying to get an output from Epic.

I've had it work previously, but now I am getting the following error.

"Java method endDocument has thrown and exception."

Does anyone have an idea what may be causing this?

I don't get past the 'transforming document...' in the message bar.

Many thanks.

Lynn

[ptc-3050150]

That sounds familiar - expecially the typo.

How big is the document?

Can you post the composer log?

Which version of Arbortext?

Which version of the FO? I assume since it is you that you are working on v1.7.

V1.7 works best with 5.4...the older ones throw errors with the new Saxon version in 5.4 - some variables not defined well enough, very specific with regards to ancestry references, etc.

Been a few months...need something to trigger the right connections in this old brain and I'm not seeing it in what few notes I have from then.

John T. Jarrett CDT
Sr. Tech Writer, Tech Pubs, ILS,Land & Armaments/Global Tactical Systems

T832.673.2147 | ext 1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

[LynnHales]

John,

Sorry for the delay, other work priorities.

I'm attaching the compose error log. One thing I found interesting as I went through it looking for an 'fatal errors' is that one of them is for PDF. I was not doing a PDF output, just trying to get a print preview first.

I've seen the table cell error previously and it did not seem to stop processing before.

I'm using Epic 5.4 basic (no updates) (and I seem to have forgotten all the things I used to ask posters for when I did a lot of posting).

The version of the FO I am using are the V1.6, and a couple of modified versions. It is one of the modified versions that is giving me the Java errors. I get a similar report from the basic V1.6.

I have not tried V1.7 yet. There are business reasons for that.

Thanks.

Lynn

[PaulGrosso]

We have seen many problems with those V1.x xsl-fo stylesheets.
(Who is responsible for their development?) Every time I
look into a customer call about them, I find invalid XSLT
in those stylesheets.

One thing to try is to do a File -> Compose -> Using XSL
and tell it to use the .xsl for the stylesheet. (By
default, the compose dialog will try to put the result
into a .htm file which doesn't really make sense; I usually
change the output file name from XXX.htm to XXX-fo.xml,
but that doesn't really matter.)

This will just do an XSLT run on your input document using
the XSL-FO stylesheets. If you get errors at this stage,
you know there is something wrong with the supplied XSL-FO
stylesheets.

If you still get nothing more informative than the java
endDocument error, that usually means that your XSL stylesheet
either is referencing a namespace prefix that is undeclared
or it is ill-formed in some other way. Hopefully, you'll
get some other message with a line number on it and you can
narrow down where the problem lies.

paul

[ebenton]

I wonder if this has anything to do with some of the basic XSL-FO-using-Java problems that have been mentioned by others. See attached Adepters post from Todd Nowlan.

[ptc-3050150]

This is a new book so I'm not working changes...yet.

It definitely sounds like the ancestry issues I have run into with the 5.4 version of the Saxon parser - we apparently were the first good 5.4 testers with v1.5. v1.7 should have most of my changes, but since it hasn't officially been release, guess that leaves you in a pickle...and like I said, I haven't touched chgwp stylesheet yet.

Here is an example of something that worked in 5.3 but not 5.4 in pmcswp-v1.7:

<xsl:when test="../@use-manhours='yes">

Changed to...

<xsl:when test="ancestor:mcstable/@use-manhours='yes">

Note: I'm no XSL-FO expert and freely admit the line above is a quick hack, but at least it works.

Another issue with tables was references to variables for attributes. If I recall this correctly, rowsep!=0 and colsep!=0 did not work. I hacked it with a colsep!='0', PTC assigned a 0 to empty rowsep and colsep, and LOGSA went with my '0'. This group mentioned that that would make Sax out of spec, but either way, that had to be fixed in table for 5.4.

Two things about 5.4:

1. Try it with 5.3 if you can - the stylesheets were not written to work with 5.4's Saxon parser.

2. Don't use 5.4 F000

And about v1.6:

LOGSA admitted their upgrades from v1.5 in v1.6 broke so much functionality they went on to v1.7 without making sure v1.6 worked.

John T. Jarrett CDT
Sr. Tech Writer, Tech Pubs, ILS,Land & Armaments/Global Tactical Systems

T832.673.2147 | ext 1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

[ptc-3050150]

Yes now that you mention it that was why I asked how big his book was. We still have not got even the 10,000 page chapter of the 38,000 page book I was trying to run back then to complete. Java heap error. Going to send it to PTC here shortly for them to give it a go, but so far the only real solution is to wait for Arbortext 6.0 and install it on Windows Server 2008 with lots of RAM...I'm not sure the Army will wait that long.

Considering the Army's XSL-FO does not use 99% of the features that make upgrading to XSL-FO necessary, it sure appears from our end they should have stayed with FOSI and ignored the fact that they would probably never get the formatting 100% perfect.

John T. Jarrett CDT
Sr. Tech Writer, Tech Pubs, ILS,Land & Armaments/Global Tactical Systems

T832.673.2147 | ext 1147 | -
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

[LynnHales]

Paul,

The 40051 XSL-FO is being developed for LOGSA by a company named Jacobs.

The work BTAS (company I'm working for) is doing is upgrading those style sheets to the current ongoing revision to 40051-1/-2.

Thanks for the other information. I'll pass it on to the lady doing most of the grunt work on the FO for us.

Lynn

[LynnHales]

Ed,

No, we're using a relatively small test file, around 200 pages. So sheer size isn't the killer here.

Thanks

Lynn