Skip to main content
P
ptc-9534221-Visitor
1-Visitor
December 8, 2014
Question

FOSI Retirement Notice

  • December 8, 2014
  • 24 replies
  • 6219 views
I just read about PTC's plans for FOSI retirement-see below. The news came to me on Friday in "(Updated) - 2014 Arbortext Announcements" in my daily "PTC Technical Support Subscriptions" email

The announcement below says they will continue to include the FOSI composition engine in future releases, but will no longer have any maintenance releases or patches related to it.

So, I'm wondering, Should we start migrating our FOSI style sheets to Styler or should we continue to put all our eggs in the FOSI basket since the composition engine that works for us now will be available with future Arbortext products?



2014 Arbortext Announcements

July 2015: FOSI Retirement Notice

* Beginning July 1, 2015, PTC will change the level of support for the FOSI composition engine from Standard to Sustained.

* This includes the use of XSL-FO, the FOSI Editor and the Arbortext line numbering application.

* Customers with an active Global Support agreement may continue contact PTC Technical Support as well as have continued access to technical support web tools, the knowledgebase and prior maintenance releases.

* However, there will be no additional maintenance releases or patches related to the FOSI composition engine.

* The FOSI composition engine will continue to be included in the Arbortext suite of products, and customers may continue to use existing FOSI stylesheets.



--Jack
LSI, Inc.
Jacksonville, FL

    24 replies

    Show previous replies
    C
    ClayHelberg18-Opal
    18-Opal
    December 11, 2014
    Exactly, Steve. I was going to write a very similar response, but you beat me to it. 🙂

    At SPSS, several years ago, we had a similar system, though--somewhat ironically--our "external" print engine was actually Print Composer. (We did the transformations externally because they did a lot of hairy document aggregation and fixup before generating the actual FO instance. We basically invented something a lot like DITA before DITA was widely available, so we had code to handle our custom equivalent of bookmap files, resolve cross-references, etc.)

    --Clay
    L
    LynnHales1-Visitor
    1-Visitor
    December 11, 2014
    Actually I know you can use XSL/FO (even the trash that LOGSA is putting out
    for 40051 production) with Epic’s Print Composer to get PDF. I’ve done it
    (when the FO DID NOT FAIL). If the FO is good, then nothing else was needed.



    Lynn


    P
    ptc-56817901-Visitor
    1-Visitor
    December 11, 2014
    I should probably clarify that the technical details of the actual implementation of Saxon + FOP is easy. Converting your FOSI to XSL-FO is not. I've tried automating the conversion of FOSI to other languages and it's not a simple task if you make use of nested charsubsets. You could get a head start by converting all your e-i-c's to templates and the contents mapped to basic fo constructs. Your charsubsets could also be mapped to named templates as a start. Then it would be a manual slog fine tuning it all together. One of our limitations is that we are using an industry standard variant, so to gain the benefits of the shared html and fo code, we needed to do the whole thing manually.

    Steve
    G
    GarethOakes16-Pearl
    16-Pearl
    December 12, 2014
    Hi Paul,

    Others have indicated that using non-Arbortext XSL-FO is possible. I wanted to chip in with a real life example and some details.

    We have recently replaced the composition function for a large (~50 user) Arbortext customer. They were using pretty much the whole shooting match (Editor, PE, Styler, Architect, DLM) hooked up to Documentum. PDFs were produced by the FOSI engine based on heavily source-edited Styler stylesheets. The customer made the strategic decision to switch away from FOSI (with some wisdom, it would seem), which they aligned with a business requirement to update/refresh the style of their PDF deliverables.

    We worked with the customer to design, implement, test and document an updated system with all FOSI print dependencies removed. The new system state still includes Editor, DLM and PE but PE is only really used for DLM and some ancillary services. The Arbortext composition pipeline is no more, that function now resides within a set of XProc pipelines (running on Calabash). The XML->PDF transformation steps in each pipeline are implemented using a callout to Antenna House via web services. Saxon is used for XSLT transformations.

    We have patched up all the relevant Arbortext server and desktop composition functions to call out to XProc pipelines instead of the built-in composition functions. That means from a user perspective, and even a server perspective, the composition works seamlessly. It just so happens that the PDF is now produced by the Antenna House XSL-FO engine rather than Arbortext FOSI engine.

    As Steve mentioned, the process of porting the FOSI stylesheets to XSL-FO was non-trivial and in fact probably the largest part of the project in terms of cost, effort, time, risk. There is a long tail of testing and fixing with stylesheets. XProc is easy to work with, as are web services and Saxon, and we know the Arbortext code packages well enough that hooking up to Calabash wasn't too hairy.

    BTW, the customer in question already had a separate set of screen stylesheets for authoring/editing purposes. These FOSI stylesheets were retained for screen use only.

    // Gareth Oakes
    // Chief Architect, GPSL
    // www.gpsl.co
    Terms & ConditionsCookie settingsAccessibility statement