Skip to main content
A
Anonymous
October 31, 2012
Question

PE/Local composer performance with large PDFs

  • October 31, 2012
  • 21 replies
  • 3956 views
Hello all,

I'm using Editor and PE 5.4 M100, and I'm having difficulty publishing a large doc to PDF.

Ok, so the document itself is XML, ATA-style markup, and uses FOSI. It's roughly 2.2MB in size, contains references to about 200 bi-level TIFF graphic ents, and also contains several hundred instances of ID/IDREF pairs.

By turning off graphic display and gentext, I was able to get the document to load pretty quickly into the Editor (about 15 seconds). No completeness errors or anything.

Either sending this to PE or by using the local Print Composer (using distiller for PDF), I cannot get this document to render. I had my maxBusyInterval set to 30 minutes, and it considered the subprocess for this composition hung and restarted it. Other than that, I can get no indication of errors or issues that I can address. My PC for local composition is XP, with a dual-core Intel and 3Gb RAM.

The development server I'm using for PE has 4 quad-core CPUs and 48Gb of RAM.

Anyone have any ideas? I tried searching the adepters a few times, but for some reason the filtering isn't working on the site (selecting just Adepters for searching pulls in results for Windchill, ProE, ect).

Thanks,

-Jason

    21 replies

    Show previous replies
    P
    ptc-19080751-Visitor
    1-Visitor
    November 1, 2012
    You can create a .dvi file using format allpasses forceat the command line or in a startup file. Then use pubview.exe to preview the .dvi file. The format command is a little faster than the preview command because the preview contents don't have to be rendered.


    Good luck!
    Suzanne Napoleon
    www.FOSIexpert.com
    "WYSIWYG is last-century technology!"


    P
    ptc-19080751-Visitor
    1-Visitor
    November 1, 2012
    Bob,

    Table markup, whether authored or FOSI-generated, takes longer to format than flowing text. If you don't need formatting available only with tables, you may want to consider using algroup, indent, ruling, and possibly boxinginstead of gentables in order to speed up the formatting process.

    If you decide to test this, please let us know your results:-)

    Thanks!
    Suzanne


    P
    ptc-9539261-Visitor
    1-Visitor
    November 1, 2012
    That's interesting as an Arbortext consultant once told me that the first thing that happens is that the Styler stylesheet is converted to a FOSI (just as if you exported the stylesheet as a FOSI), so it never actually processes with a Styler stylesheet. Anyone else heard that one?

    Dave
    B
    bibach1-Visitor
    1-Visitor
    November 1, 2012
    That is true. There is no "Styler engine" that can run a Styler sheet
    directly without first compiling it to an XSL-FO, FOSI or APP template.

    However, unlike languages like C, for which compiler technology is very
    mature and even a highly-skilled programmer would be hard-pressed to write
    more efficient assembler code than what's produced by the compiler,
    Styler's "compilers" for the various formatter backends don't necessarily
    produce the most efficient results compared to a hand-built FOSI or APP
    template.

    There are a variety of reasons for this, but one that comes to mind for
    FOSI is numbering. Automatic numbering is usually best handled using
    FOSI's built-in counters. More sophisticated numbering may require calls
    to ACL functions, which can involve a performance hit. There are cases
    where a Styler-generated FOSI makes calls to ACL for numbering, in order to
    support the full range of numbering features that the Styler UI offers,
    even if the Styler sheet in question hasn't used any features beyond what
    could have been handled with counters. More sophisticated or aggressive
    optimization strategies within Styler's "compiler" for FOSI might catch
    this. A well-tuned hand-built FOSI almost certainly would.

    -Brandon 🙂


    B
    BobSpangenburg1-Visitor
    1-Visitor
    November 1, 2012

    Suzanne,


    Ok, to get a little deeper... I am involved with DOD spec doctypes and to make matters worse, use PTC's CPD product.Though I can do all kinds of FOSI-related trickery with both style, as well as ACL, I have a limit to what I can change and still have a viable document for change packages.


    On another note about the speed of FOSI... It's direct and to the point, so it's quite fast. If I had nothing but tables/rows/entries, the formatter would do its thing relatively fast. However, as you know Suzanne, psuedo tables are built one piece at a time. Then when enough pieces are put together for the entries within a row, the row is stored while the next row is built, and so on. Goes like that through the whole table. Because of the complexity of the data and how it's built, it is far easier to build the SGML structure using the data types then to biuld the rows/entries and all their attributes based on what type of entry they are.


    I have nothing against FOSI whatsoever. Being DOD-oriented, it never has to change as far as I'm concerned. There's not much I can't do with it for paper output. When I mix in ACL, the sky's the limit.


    Have a great day,


    Bob

    P
    ptc-19080751-Visitor
    1-Visitor
    November 1, 2012
    Bob,

    I'm with you -- FOSI (plus ACL if needed) is great for techdocs, especially because of its speed compared to XSL-FO and APP. XSL-FO would probably be out of the question in your case.


    Good luck!
    Suzanne


    G
    GarethOakes16-Pearl
    16-Pearl
    November 1, 2012
    I object! My native APP could beat your native FOSI! 😉

    Suzanne Napoleon <suzannenapoleon@fosiexpert.com> wrote:



    Bob,

    I'm with you -- FOSI (plus ACL if needed) is great for techdocs, especially because of its speed compared to XSL-FO and APP. XSL-FO would probably be out of the question in your case.

    Good luck!
    Suzanne
    P
    ptc-19080751-Visitor
    1-Visitor
    November 1, 2012
    Hi Gareth!

    Ya think? 🙂

    My understanding is that APP is slower than FOSI. The Help info for Print Engine Comparison sez to consider FOSI if you "require the fastest possible performance." I've heard there is an effort to speed up APP. Has that happened?

    Thanks!
    Suzanne

    G
    GarethOakes16-Pearl
    16-Pearl
    November 5, 2012
    Glad I managed to get someone fired up with my response 🙂

    What you're referring to is true in the context of Styler. It comes down to what Brandon referred to earlier. Styler is basically a high-level description of a stylesheet which is then "compiled" into a native stylesheet language such as XSL-FO, FOSI or APP.

    It turns out the design of Styler stylesheets is very close to FOSI and XSL-FO but not as close to native APP templates. Therefore Styler's APP compiler is not as mature as the FOSI compiler and produces less optimal code. PTC are actively working to improve the APP compiler and it is certainly getting better/faster with each release.

    Native APP templates that have not come from Styler can be very fast indeed; showdown at high noon? 🙂

    -G
    P
    ptc-19080751-Visitor
    1-Visitor
    November 5, 2012
    Thanks for the clarification 🙂

    I tested the formatting speed for my bookon my laptop with Print Composer.The DTD is based on docbook. The stylesheet is a custom native FOSI. The book currentlyhas 888 pages without the index. It has a lot of tables, most of which are not very long, and there are a lot of graphics throughout. The flowing text is ragged right, no hyphenation, and there are margin notes.There is a fair amount of as-is, line-for-line text.A few ACL functions are used. Two formatting passes are needed because of the TOC and xrefs. With no pre-existing cache files, the doc formatted in less than 34 seconds. With pre-existing cache files, the doc formatted in less than 28 seconds. When the index bug is fixed, I'll test again with the index.
    Show more replies
    Terms & ConditionsAccessibility statement