Skip to main content
P
ptc-19080751-Visitor
1-Visitor
January 30, 2015
Question

You be the judge

  • January 30, 2015
  • 20 replies
  • 4129 views

- Just a few years ago, APP was an interactive, template-based product that utilized processing instructions. By comparison, FOSI/TeX's successful track record of top speed, top quality, database-driven, "lights-out"batch publishing of SGML/XML documents in multiple languages is entering itsthird decade.


- SPR Fixes for Arbortext Editor 6.1 (through M040) lists 10 bugfixes related to FOSI/TeX, none of them involving software crashes. On the other hand, approximately 135publishing bugfixes specifically related to APP are listed.In addition, the release notesfor APP 11.0 (through M070) list approximately 250 bugfixes. It is not clear how much overlap exists between the two documents. In any case, at least 250 APP-related bugfixes were reported, with many involving unexpected termination of the software. That's >250 compared to 10. The numbers speak for themselves. FOSI/TeX has the reliability and stability that organizations require. APP does not.


- SPR Fixesfor 6.1 Styler (through M040) list 42 bugfixes, 6 of which involved software crashes.


- APP documentation is acknowledged to be neither complete nor up to date. FOSI documentation is both, and includes step-by-step instructions for developing a FOSI stylesheet from scratch as well as a development methodology and F1 Help for every formatting property. Also, there are my book and tutorials.

- APP has high-hurdle prerequisites. FOSI requires only experience with paged output.


- APP has a steep learning curve. FOSI's learning curve is reasonable.


- APP training courses do not currently exist. My FOSI tutorials have been available for years, and PTC Arbortext has FOSI training courses that could be offered again.


- APP development requires outside consulting; DIY is out of the question. In-house FOSI development is perfectly feasible and is done all the time.


- TheFOSI development environmentis vastly superior to using the Styler UI with possibly hundreds of property sets andthousands of lines of potentiallyconfliciting source edits in JavaScript. Especially considering that an element with a source edit can no longer be modified with Styler.


- Styler has gotten to the point where it is more complicated than FOSI. The Styler Users Guide has 1,094 pages, even though Styler formatting capabilities are limited. By comparison, the FOSI Reference Manual is less than half that long, with 437 pages.


- Imperative JavaScripted APP is a poor fit for declarative Styler, which is a structured markup application very like FOSI.


- PTC Arbortext acknowlegesthe TeX engine has the fastest formatting speed. AndAPP Styler source edits have the potential to decrease its formatting speed even more. Plus, the Styler Users Guide has a 17-page chapter about performance issues with Styler.


- TeX H&J is by design better than APP H&J.


- APP-only formatting capabilities are generally not used in technical documentation and service information. On the other hand, FOSI has built-in featuresespeciallydesigned for technical documentation and service information.
Suzanne Napoleon
www.FOSIexpert.com"WYSIWYG is last-century technology!"

    20 replies

    G
    GarethOakes16-Pearl
    16-Pearl
    February 2, 2015
    Hi Suzanne,

    In the interests of completeness, I've added some facts to your statements below.

    // Gareth Oakes
    // Chief Architect, GPSL
    // www.gpsl.co
    P
    ptc-56817901-Visitor
    1-Visitor
    February 2, 2015
    I’d love to see a comprehensive methodology for benchmarking 2+ composition systems. It’s a bit easier when comparing two engines that use the same source (FOP vs Antenna House Formatter), but when the language is different (FOSI vs APP JavaScript vs XSLT + XSL-FO) how do you come up with fair comparisons? Features in one may not exist in another, H&J will be different and better is partly subjective.

    Steve
    G
    GregoryMackenzi1-Visitor
    1-Visitor
    February 2, 2015
    My first thought, APP is proprietary isn’t it, and FOSI not?
    P
    ptc-56817901-Visitor
    1-Visitor
    February 2, 2015
    FOSI as a specification isn’t proprietary, but PTCs implementation in part is so it’s not a binary data point. There were always differences between how Arbortext and Data Logics interpreted things and Arbortext/PTC has certainly extended the product to add proprietary features.
    G
    GregoryMackenzi1-Visitor
    1-Visitor
    February 2, 2015
    One might say we’re moving further away from open standards when they are captured and effectively made proprietary.
    C
    ClayHelberg18-Opal
    18-Opal
    February 2, 2015
    Well, it’s not as simple as that, Greg. Ideally, the open standard would provide everything that anyone could ever need, and there would never be a need for extensions. But we all know that never happens in real life. Standards are incomplete, and contain ambiguities, despite the best efforts of the committees drafting them.

    If you are an implementation vendor, and you know most of your customers need feature X which isn’t included in the standard, you’re going to have to add extensions. I don’t think that’s a bad thing. For one thing, it helps standards orgs see where the gaps are in their specs, so they can fix those issues in the next revision of the spec (hopefully). Once a feature that was previously extension-only gets incorporated into the spec, vendors are usually quite good about using the new spec’s implementation and deprecating their old extensions for the same thing.

    Also, w.r.t. FOSI specifically, while it may be theoretically an “open standard”, in reality there are only a couple of vendors that support it (and I’m not sure if DataLogics even still exists or supports FOSI publishing?), and there are few if any sources for documentation, training, etc on the standard apart from the vendors. (And PTC doesn’t even offer FOSI training any more, the last time I checked.) So, whatever advantages one usually expects for an open standard are noticeably absent from the FOSI world—in that sense it might as well be proprietary.

    --Clay
    P
    ptc-56817901-Visitor
    1-Visitor
    February 2, 2015
    I know DLPager was being supported up to about three years ago, but I’m not sure as of today. But that still means that there are only two vendors who support FOSI and that support seems to be waning. XSLT/XSL-FO isn’t all that much better with three xslt engines (are there more than Xalan, Saxon, and Spy?) and something like 4 XSL-FO engines).

    I accept that extensions are a necessary part of the process and I used them grudgingly when necessary, but that still leaves the question of how to create a fair benchmark for performance. You will never get pixel for pixel or line for line equality, so what is a reasonable level of difference when comparing (total page count +/- some amount?) What standard features are to be included (tables, TOC, LEP, Indices, change bars, floats?) Once you have that list you can then compare times. Of course, if LEP processing takes 25% longer on one platform but I don’t care about LEP, does it really matter?
    C
    ClayHelberg18-Opal
    18-Opal
    February 2, 2015
    Right, Steve, that’s exactly what I was thinking of in terms of some of the difficulties in making a comprehensive benchmark. The evaluation one person makes based on their use case will most likely be different from someone else’s evaluation.

    Regarding XSLT and XSL-FO as standards:

    · The availability of at least two solid library implementations (Xalan and Saxon) with friendly licensing means that XSLT has permeated the world of XML processing. It is very rare to find an XML-based application (especially a document-based application) that doesn’t make at least some use of XSLT processing.

    · Xalan, at least, is open-source, so it is not controlled by a vendor. If you want an extension that doesn’t exist, you can write it yourself. The same goes for FOP on the rendering side.

    · There are other implementations of XSLT processors as well, including libraries from Microsoft and Oracle

    · For XSL-FO rendering, there are FOP (open source), Antenna House, RenderX, XMLMind, and of course Arbortext, and probably a few others. It may not be a huge list, but having a few vendors with decent implementations is a huge advantage of open standards, and one that FOSI doesn’t really have. If I have invested in a custom XSL-FO stylesheet for publishing my documents, and I have some kind of issue with Antenna House for some reason, I can switch to RenderX or another implementation with relatively little pain (depending on how much I’m relying on Antenna House extensions—which, if I’ve done things right, is as little as possible). What do I do if I’ve invested in a FOSI stylesheet and I have an issue with PTC? Datalogics’ web page says DL Composer is still offered as a product, so maybe I could switch to that, but I suspect there would be more involved there than just swapping out the composition engine at the end of the pipeline.

    · The relatively low costs of XSLT processors and XSL-FO rendering engines makes it easier to experiment, and swap out if conditions warrant it. But swapping out Publishing Engine for Datalogics or vice versa would be a much bigger deal than swapping out FOP for RenderX, just from a financial perspective, let alone the configuration and implementation issues. If you want to test whether switching to RenderX will work, you can download a trial version and pump your XSL-FO test instances through it in an afternoon. I doubt it would be so easy with testing Datalogics vs. PE.

    · Go to any computer bookstore (or browse Amazon.com) and you will find several books to choose from on XSLT and XSL-FO, and the web offers plenty of tutorials, FAQs, examples, and Stack Overflow threads on solving XSL problems. Try to find a source of information on FOSI anywhere other than Suzanne’s web site. (This is why we like Suzanne’s FOSI content so much—it’s good content, but also it’s basically the only game in town.)

    Not that APP does any better than FOSI on the “open standard” criterion—it’s proprietary, and information about it can be hard to come by as well. But I don’t see that FOSI has a great deal of advantage on that score, despite nominally being an open standard.

    --Clay
    D
    DavidS.Taylor1-Visitor
    1-Visitor
    February 2, 2015
    Speed, capabilities, automation and standards all aside, a basic issue for many of us in the FOSI vs. APP debate is cost.

    I don’t know enough about APP to comment on it , pro or con, but I do know that our shop has used FOSI/Print Composer successfully for 20 years now. I know that we don’t need a ‘bigger’ solution to fulfill our composing requirements. I know that converting from FOSI to some other formatting specification would be very hard to justify in our current environment, we don’t have the resources, time or money to make the change. We’ve invested significant time and effort over the last ten years integrating Arbortext into a workflow-based CMS environment for authors, editors and translators, publishing output for print, web and electronic products.

    For our environment APP’s expense (purchase and yearly maintenance) could not be justified. We publish on average 6-8 documents a year, major releases (every 5 years) such as this year will see that number jump to 12-15 documents. We have 14 authors, 4 editors and 2 translators, plus two of us who develop and maintain various custom doctypes as needed and do all the composition and publishing tasks.

    One of the strengths of Arbortext, the company, was their connection with their customers. They asked for input on Arbortext/Epic/Editor and listened to what customers had to say. Small customers had the same opportunity to be heard as the large customers.

    Since PTC bought Arbortext, its users have almost no voice, no input and certainly PTC has made it clear they don’t want to listen to Arbortext customers’ needs. It reminds me of what happened when Stilo bought Omnimark, they too made it clear they weren’t interested in what the user community had to say.

    My cynical side can’t help but wonder if PTC is trying to move customers who still need composed output for print to their more expensive solution, APP. Unfortunate for those who can’t afford it.

    David

    David S. Taylor

    Project Manager, Structured Information
    Production and Marketing | Building Regulations | NRC Construction
    Building M-23A, Room 114 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
    Telephone: 613-990-2731 | Fax: 613-952-4040
    David.S.Taylor@nrc-cnrc.gc.ca<">mailto:David.S.Taylor@nrc-cnrc.gc.ca>


    G
    GarethOakes16-Pearl
    16-Pearl
    February 2, 2015
    Just as a note on this discussion, it is worth pointing out that the APP technology is included with all current Arbortext print-capable products and is now the default print engine. So the incremental licensing costs of "moving to APP" for most businesses would be zero (if you are running a recent 6.0 or 6.1 build).

    The real concern is obviously migration from a FOSI (or source-edited Styler) stylesheet. A lot of effort goes into making stylesheets that work "just right". Automated (assisted?) stylesheet migration is an area of interest for us here at GPSL, I wonder if anyone has experiences to share.

    // Gareth Oakes
    // Chief Architect, GPSL
    // www.gpsl.co
    Show more replies
    Terms & ConditionsAccessibility statement