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

    Show previous replies
    C
    ChrisWestern12-Amethyst
    12-Amethyst
    February 3, 2015


    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/


    G
    GarethOakes16-Pearl
    16-Pearl
    February 4, 2015
    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
    C
    ChrisWestern12-Amethyst
    12-Amethyst
    February 4, 2015

    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


    J
    JurgenSchnurr1-Visitor
    1-Visitor
    February 4, 2015
    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
    P
    ptc-56817901-Visitor
    1-Visitor
    February 4, 2015
    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
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    February 4, 2015
    How much does it cost?
    Thanks!Suzanne Napoleonwww.FOSIexpert.com"WYSIWYG is last-century technology!"
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    February 5, 2015
    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.
    C
    ChrisWestern12-Amethyst
    12-Amethyst
    February 5, 2015
    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


    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    February 9, 2015
    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
    C
    ChrisWestern12-Amethyst
    12-Amethyst
    February 10, 2015

    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

    Terms & ConditionsAccessibility statement