You be the judge

[ptc-1908075]

- 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!"

[GarethOakes]

Hi Suzanne,

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

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

[ptc-5681790]

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

[GregoryMackenzi]

My first thought, APP is proprietary isn’t it, and FOSI not?

[ptc-5681790]

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.

[GregoryMackenzi]

One might say we’re moving further away from open standards when they are captured and effectively made proprietary.

[ClayHelberg]

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

[ptc-5681790]

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?

[ClayHelberg]

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

[DavidS.Taylor]

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>

[GarethOakes]

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

[ChrisWestern]

What is it with the APP smears on here?!

Styler+APP can and has been suitable for many applications to date.

If you want to go a little or alot further and access every controll available beyond the Styler GUI/Source ... my suggestion would be just go strait to APP native in the first place with support from one of the APP knowledgeable VARs!

Yes you have to know what your doing to get the best out of it like anything, but once you have the basics it is packed with a toolbox of features and supports many standards and scripting languages.

From recent first hand experience i have seen raw DL Pager is barely still in the same league. If we are putting APP up against open/free TeX and FO, should XPP & Quark not be in the mix also to balance out the arguments with other commericial applications?

Acurately comparing all these with experts in each one is a massive task. And then where do you start, comparison by raw feature strength, by type of document, type of data input/output, GUI, API, what pre-prosessing needs, inline-formating conditional/logic options, etc etc. Every one will have its own strengths, I think it is 'always' best chosen by what the requirements are.

Advance to Mayfair, if you pass GO collect £200! 😉

Have a nice coding day

Regards
Chris

tformat.com/technologies/app-3b2/

[GarethOakes]

Hi David,

To the best of my knowledge, yes, Print Composer 6.0 and 6.1 include the APP engine and the capability to use it.

A handy way to verify that your version supports APP is by looking for an "app" folder in the application folder (alongside "application", "adapters", "bin", etc.). Inside the "app" folder should be a bunch of DLLs and 3AD files.

Alternatively you can do a recursive file search for a file named "lib3b2core.dll" in your install folder. This is the main APP DLL (remembering that APP used to be called 3B2).

BTW, I thought this information was useful to the wider community so I have CC'd the Adepters list. (Your message below was sent directly to myself)

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

[ChrisWestern]

In addition if anyone is interested in training on the Advanced Print Publisher product to get a full and detailed picture, then we offer courses and tailored training packages at all levels, remote, hard-copy and on-site worldwide.

http://www.tformat.com/services/training/

Best Regards
Chris

[JurgenSchnurr]

Hi Suzanne,

I understand your deep mourning about FOSI.

I spend several years in creating editing and publishing style sheets
for Abortext Editor (or Adept or Epic) and Adobe FrameMaker. I also have
a fairly good understanding how MS Word is working. So I'm really sad
that FOSI has no future. It is a technology that met my abilities nearly
perfect. I do not like the alternatives.

But the end of FOSI is no news. We don't use FOSI for new customer
projects since several years. Only for internal projects we still use
FOSI. Why?

The PE is to expensive. When I talked about PE and mentioned the price,
one of my customers laughed shortly and said "That's insane". Other
customers were not that open, but no one was interested to discuss PE,
even if they had dozens of technical writers. On the other side, you
can't provide client side publishing solutions nowadays. So we was
forced to abandon Arbortext for publication projects.

By that time I switched back to work as technical writer, so I'm not
involved as deep as ten years ago.

Fighting for the future of FOSI is IMHO doomed to failure. What I would
have wished was a Code Freeze statement with the
commitment of PTC to support FOSI for the next releases for Windows.
Thats means only incompatibility bugs would be fixed.

Open Standards
##############

An open standard is only open if there exists several implementations.
If there iis only one implementation of the standard alive, than this
implementation is in fact proprietary.

In that sense FOSI is proprietary since many years.

Styler
######

I spent some time trying Styler, but I never used it in projects.

The best style sheet editor I know is the FOSI style sheet editor
included in Arbortext Architect. At the first glance it might look old
fashioned and some times the user interface get caught. But the more I
understood it, the more I liked it.

When I saw the Styler I understood, it was created to address some
"weaknesses" of the FOSI style sheet editor.

But the weakness "too many windows open" is a great feature, when you
finally understand how to use it. In FOSI style sheet editor I can
simply put several style- or e-i-c-windows side by side. Then I can
easily compare the properties of these styles and e-i-cs. Styler forces
me to switch between them, which makes comparing properties just annoying.

"Easy to use by designers" is a misconception. Designers use tools like
Indesign, they don't use XML. To be "designer friendly" Arbortext made
the fatal mistake to imitate the bad handling of lists from MS Word. So
we have two properties for the beginning of the first line of a bulleted
paragraph. Framemaker and FOSI are far better in that use case.

To be fair, Styler has very nice features like easy creation of context
rules, which is very uncomfortable in FOSI style sheet editor. But there
are too many bad things like gentext handling.

All in all I see no benefit by creating print style sheets with Styler.
We had never tried the only potentially selling point, multiple output
for print and HTML, because we would have needed the PE, see above.

XSL-FO
######

I have studied the Spec several times, I have discussed layout problems
in some projects using XSL-FO, I have looked into the Antenna House
documentation, but I have never used XSL-FO.

I have mixed feelings about XSL-FO. All the needed properties are there.
And as far as I see Antenna House does a good job. But I don't like the
approach of XSL-FO. It defines an XML-Language to be feed into an
processor. Therefore a "style sheet" must be a transformation from a
XML-document into a XSL-FO-document.

This adds complexity in the process of creating XSL-FO style sheets,
because the style sheet creator must
1. match a context
2. program a transformation (not needed in FOSI)
3. set properties.

The only benefit of this approach would be the use of an
XSL-FO-WYSIWYG-Editor as debugging aid or finishing tool. But I'm not
aware of such an tool.

I hope CSS will become an alternative for print layouts.

APP
####

I didn't realized that APP was provided with Arbortext Editor until the
autumn of last year. PTC has hidden this feature very well.

I understand the need to concentrate the resources to the most advanced
style engine. The FOSI engine may be mature, but to be future proof
adding the support of right-to-left languages would be essential. I
understand why PTC decided not to expand the FOSI engine.

Switching to APP is understandable. But I'm also quite sure that this
move will fail, because it will oust many FOSI user by the way it is
done. (Not that I'm that good in predictions, but my negative
predictions fail a lot less than my positive ones)

3B2 (the base of APP) is a well praised print engine, but that is not
enough to be successful as a FOSI replacement. In fact 3B2 and the
Arbortext FOSI engine were never competitors, they acted within
different markets. Having more advances print capabilities is not enough.

If you don't need this advanced capabilities, speed may become an
essential criterion. Is APP fast enough?

If you don't need this advanced capabilities, ease of style sheet
creating may become an essential criterion. Has APP anything to offer
that can compete with the ease and expressiveness of the FOSI style
sheet editor?

Lack of documentation

[ptc-5681790]

Hi Juergen,

Antenna House does have a CSS for Print Engine. I haven’t used it but I hear it is very good and has some nice features that aren’t in the XSL-FO engine. CSS is nice, but there is no facility yet for sets (charsubsetref), which is a big limitation for non-HTML rendering. There seems to be a couple of proprietary implementations of the concept out there, so perhaps it will get folded into the standard.

Regarding the transform stage of XSL-FO, I see your point, but I find that much easier when I have to do document reorder. Using savetext and usetext is difficult in FOSI IMHO. The other interesting thing you can do with the transform layer is see the raw FO code that your transform produces which can make debugging easier in some instances and it also enables more manageable differencing because you can diff the two FO instances which are XML files which if much easier than trying to difference PDF files which usually results in many false positives when pages break differently.

All in all, you have a solid analysis.

Steve

[ptc-1908075]

How much does it cost?
Thanks!Suzanne Napoleonwww.FOSIexpert.com"WYSIWYG is last-century technology!"

[ptc-1908075]

Hi Juergen,
You raise some excellent points and questions. I expect others agree. My intent is to provide facts for users to use in objecting to PTC's decision, as the ex-Arbortext lurker advised. There is no reason to kill off FOSI. It is the best solution for what PTC Arbortext is selling: dynamic publishing to complement their PLM products.

[ChrisWestern]

Hi Suzanne,



I rarely recommend only standard scripted courses. Some element of agenda customisation is always necessary to best suit the user objectives, workflow, document types/data, languages, special requirements, future intent etc.

This would dictate the ideal content then the duration would be determined by prior experience, customer resource availability out of production and budget.



However as an example an intensive quick-start course for someone with prior technical/Arbortext experience and skillsets, could be achieved in 3-5 days, dependant on the above.



Day rates vary on a scale plus any T&S required. Full quotes are available direct.



And for FOSI courses?



Best Regards

Chris

[ptc-1908075]

Hi Chris,
I think it's an apples and oranges comparison.APP has issues that FOSI does not. FOSI is built into Arbortext Editor, sointegrationtraining is not needed. FOSI is batch by design, so no training isneeded for automation. Configuration is an issue for Publishing Engine, not FOSI. So FOSI training is focused on developing stylesheets andmaking the most of the development environment.
I became involved with FOSI training when Arbortext Editor released an Editor-only (no composition) version of Adept for PC, and customers wanted a course covering just Edit window display. So I developed Arbortext's FOSI Stylesheet Design courses, whichconsisted of Part 1 for Edit window display (taught by the Training Department), and Part 2 for composed output (taught by a FOSI consultant).Note that before taking Part 2, students had to take Part 1.The courses, whichincluded the FOSI interfaces,took a hands-on, learn-by-doing approach, whichworks very well with FOSI. Youcode something, compile, and immediately see the result in the Edit window. This provides great positive feedback right from the start.
I knew from own training in FOSI and having trained new FOSI developers that a scripted approach was the way to go. Scriptingcovers everything necessary and arranges topics for best effect. Developinga FOSI stylesheet is essentially a one-person job, so aself-paced tutorial is a good fit. Also, self-paced tutorials arethe only kind of training that is feasible for some folks.
My recollection is that Part 1 was 4 days and Part 2 was 5 days.At that end of Part 1, students could develop an authoring FOSI. At the end of Part 2, students could develop a publishing FOSI. Of course, F1 help and FOSI documentation helped.The coursebooks could be purchased alone for $200 or $300 each. I cannot recall the price for instructor-led training.

Note that I have non-Arbortext training experience as well. Back in the day,before WYSIWYG and DTP, I was a trainer for what was then a high-tech interactive publishing system that utilized what is now called generic markup (h1, h2, p, etc.). The first part of the training course covered opening and editing documents, and was pretty much the same for all customers. The second part covered defining the formatting for h1, h2, etc., and was tailored to the customer's documents. A tailored approach was necessary because everyone was computer-shy in those days, and these students were often GS3- and GS4-level employees, to use government jargon.

A customized appoach never proved necessary for FOSI, so ny FOSI QuickStart Tutorials are also scripted,hands-on,learn-by-doing,and self-paced. As with my Arbortext tutorials, theyare divided into two parts (129 and 150 pages), andinclude the FOSI interfaces.The QuickStart tutorials cover more ground than my Arbortext tutorials, including how preference settings and environment variables affect FOSI formatting.Tutorial TOC's and excerpts are at

[ChrisWestern]

Hi Suzanne, et al.

For balance FOSI also has it's own limitations that APP does not. From my limited FOSI knowledge if it was everything to everyone, there would not have been a need for the tech boffins to offer the APP alternative. APP is not as channelled outside of the Styler GUI for specific areas as FOSI, but this is one of its strengths and APP standalone can apply itself in many arenas and has done for decades.

The training mentioned was for APP Desktop standalone. Likewise the basics on how it works, how documents are made and the core toolsets will apply to everyone (i.e. our scripted foundation content + other modules). As APP is more of a toolbox, with a number of ways to approach a problem and a large array of tools to use. You can leave out any non applicable areas*, and focus on only what a customer will need.

(* non applicable areas might include for example; heavy financial tables/EDGAR if you are not doing financial reporting templates, or synoptic column alignment if youy are not doing dual language/revision legislative work, or anything to do with customising the GUI if you are running 100% automated black-box). As well as things like what data you are using, i.e. if you do not have XML data you will not use the xtools (xpath, xslt, DOM etc). An additional training part may include the best template architecture to suit the use requirement.

The desktop version is used to develop templates to run on the desktop, server and enterprise version as well as (with some basic modification) within Styler and PE. However if you have good JavaScript APP FOM API knowledge, you can develop fully automated templates in a JS development environment (like Eclipse) without the desktop version, to then run in the automated applications. Or of course just get 'someone' to develop the template for you and self learn what’s under the bonnet/hood while using it!

We also offer hard copy for self learning with the generic scripted courses (full training library overview/ToC available on request), which will get you going with all the core areas of APP.
My feeling is that no written course or video can ever beat instructor lead training for the trainee unless its followed up with some Q&A/mentoring time afterwards. It depends on how much the knowledge is worth to the customer, single desktop user vs large enterprise user.

I don't wish to split more hairs, they are what they are, but just a few points 😉

Best Regards
Chris

--------------------------------

Chris Western

tformat.com