PE Question: Is 38,000 Pages Too Big?

A couple of possible next steps (although I'd definitely open a call
w/PTC-Arbortext support and get their input on the failures, log messages,
etc.):

Try running larger and larger fragments without graphics. We have had
failures (sorry, I can't remember the failure messages) where one "badly
formed" graphic failed the whole job. Typically they were larger than other
graphics from a filesize perspective. I think ultimately we found they had
accidentally been saved with an insanely high resolution.

Try working with just that chapter and chopping it down until it works. Try
to determine whether it is a size issue or whether some part of that chapter
is bad.

Try running the rest of the document BUT that chapter. (Or, turning on a
different chapter.)

How are your sub-docs included? Are they actual in-line XML content,
includes, chunks assembled by a CMS? Maybe flattening the document (in a
copy of course) would reduce some overhead that is tripping up PE if they
are somehow being assebled, especially if Editor/PE is doing that.


On Fri, Feb 26, 2010 at 5:01 AM, Jarrett, John T. (US SSA) <
-> wrote:

> Thanks there Paul and Dan. Should have thought of carving it up…guess it
> comes from being an "only one" in the shop and not having anyone else to
> bounce stuff off of to get the brain clicking again.
>
>
>
> I cut out almost all of the individual documents (to us, the work packages
> that make up the meat of the full doc, some 37,000 pages) and 593 pages
> printed, 79 MB PDF - but there were no graphics. That took about five
> minutes.
>
> I turned one chapter back on, some 900 sub-docs, and it crashed, again.
> Lots of graphics not found and then a non-fatal "subprocess terminated
> unexpectedly" combined with a graphic file not found and then after a few
> more missing graphics warnings, a "Java heap space" error.
>
> That's interesting because I'm running it from the PE's own editor.exe on
> the same machine as the PE…and the graphics appear in editor fine.
>
> I should note this is the same PE where Compose | PDF File doesn't show
> graphics but Print Composed to a PDF print driver does…so I'm using a PDF
> driver rather than the PE's PDF capabilities. We also are not using
> Distiller - I've seen that option about but is not something we've invested
> in.
>
> I'll see if I can do something about the graphics and fire it up again.
> Thanks again - and does that trigger any more suggestions?
>
> *John T. Jarrett CDT***
>
> Tech Writer II, Tech Pubs, ILS, Land & Armaments/Global Tactical Systems
>
>
>
> T 832.673.2147 ext 1147 | M 512.736.7031 | -
>
> BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
>
> www.baesystems.com
>
>
>
>
>
> *From:* Paul Nagai [
> operation."/>
> <data name="outputCode" value="500"/">
>
> This is only slightly better than getting the "General XPath error."
>
> In order to keep it from timing out (with Susan Fort's help - thanks!)
> I've set the subprocess pool as follows:
>
> <subprocesspool default="yes" id="pool-default" maxsubprocesses="2"&lt;br"/>> maxBusyInterval="0"
> minSubprocesses="1" maxLifetime="0">
>
> Quad core server, 4 GB RAM, 14 GB page file (the standard 2 min/4 max GB
> setting was not enough). Crashes after about 4 hours.
>
> I tried without the appendices to cut down on gentext - no change.
>
> I'm saving the temp files and they all appear to be complete - x2.xml as
> well as the intermediate and the outputdir with ati tags. The x2 is 40 GB
> and the intermediate/ouputdir file is 450 GB <-- can't even open it with
> Arbortext. I was hoping they were crashing and I could tell where, but each
> has an ending </production> or </fo:root> tag as appropriate.
>
> Other than rqbody.dat (which apparently I don't know how to open), I've
> looked at all the transaction files and find no help at all.
>
> We just did a test on a book that is half that size (still in the huge
> department) and are back to the General XPath Error even though our
> contractor has published it in the past with 5.3 and the older LOGSA v1.4
> stylesheets (which has badly formed jumbled up tables).
>
> Any ideas on what to try next? At 4 hours to a crash, this is turning into
> a really long process.
>
> John T. Jarrett
> BAE Systems | *Arbortext version 5.4 | *LOGSA XSL-FO v 1.6
>
>