Just pointing one very critical thing Steve said out:
> However, Antenna House has developed extensions that make the n of m
floats that Arbortext can do with FOSI possible.
This tracks with something else I happen to have come across: The DL
Composer FOSIs that are going around make HEAVY use of DL Composer
extensions which has resulted in a proprietary FOSI that can only be
published with DL Composer.
If you use extensions -- and almost always extensions get used -- you've
entered the proprietary zone.
This means, in essence, really, the last publishing step really is
proprietary no matter what your using. So why argue about it?
Cheers,
Liz
On Wed, Feb 4, 2015 at 12:03 PM, Steve Cuzner <->
wrote:
> I think it's fair to say that XSL-FO is significantly slower when using
> Arbortext. XSL-FO with other products is much, much faster. This is because
> of the way Arbortext tried to implement FO: Use XSLT to transform your XML
> to and XSL-FO temp file, read the temp file, dynamically create a temp FOSI
> file, then apply the temp FOSI to the FO file. It is only at that point
> that you get to the same point as FOSI on XML so it is obviously slower. In
> and XSL environment you are always going to have the dual process of
> transform and format, but it is much faster with other engines. I think
> Arbortext also slowed down the XSLT portion of the process by forcing it
> into the pipeline architecture.
>
>
>
> The big advantage I have seen in using FO over FOSI is the issue of
> license lock. You have a fixed number of licenses with Arbortext so you can
> only parallel publish up to the number of licenses you have. Moving to FO
> with FOP you have unlimited numbers of parallel publishing you can use and
> even with paid products, the price for multiple licenses is much less than
> PE.
>
>
>
> Floats are the one big are where FOSI trumps FO that I have seen. However,
> Antenna House has developed extensions that make the n of m floats that
> Arbortext can do with FOSI possible.
>
>
>
> *From:* Suzanne Napoleon [
>
>
>
> *2. *I am not saying FOSI is non-proprietary or open source. I am saying
> it was ahead of its time. Markup languages that came later were able to
> achieve more in that regard.
>
>
>
> BTW: The Air Force gives a DataLogics print FOSI along with an Arbortext
> authoring FOSI to subcontractors.
>
>
>
> *3.* If PTC Arbortext offered FOSI training courses as in the past and
> included FOSI stylesheets and samples with the product as in the past, and
> if PTC User held annual user conferences for Arbortext Editor as in the
> past, FOSI would have a much higher profile.
>
>
>
> *4.* My information about formatting speeds and performance issues comes
> directly from PTC Arbortext's documentation. Specifically, the Help Center
> had this to say about formatting speeds in 6.0 (released in February 2011):
>
>
>
> "In version 6.0 the FOSI engine is somewhat faster than APP, though
> we expect to close that gap over time. XSL-FO is significantly slower, and
> that is unlikely to change."
>
>
>
> Three-and-a-half years later, in August 2014, the 6.1 *Styler Users Guide* had
> this to say about formatting speeds:
>
>
>
> "In version 6.1 the FOSI engine is somewhat faster than APP, though
> we expect to close that gap over time. XSL-FO is significantly slower, and
> that is unlikely to change."
>
>
>
> Is it really such a big deal? Yes, because time is money. Slower speed
> means an organization may need to acquire additional hardware, software,
> and possibly personnel to produce the same output in the same amount of
> time as before. No business wants to do that.
>
>
>
> *5.* As long as the engines format the same document, it's a fair fight.
> I chose DocBook for my testing because it uses document-based markup. PTC
> Arbortext authored the document content and developed the stylesheet.
>
>
>
> *6.* No first-fit H&J, however configured, can be as good as total-fit
> H&J, because total-fit is designed to find the best fit every time, whereas
> first-fit achieves the best fit only by serendipity.
>
>
>
> I have many years of experience with first-fit H&J. Usually, the following
> settings are specified:
>
>
>
> - maximum number of successive lines of hyphenation is specified
> (typically 3)
>
> - minimum number of characters in a word to be hyphenated (typically 5)
>
> - minimum number of characters before a hyphen (typically 2)
>
> - minimum number of characters after a hyphen (typically 2)
>
>
>
> There may be additional settings. In any case, configuration is not the
> solution to the challenge of first-fit H&J, it is part of the problem. Each
> constraint limits the number of possible break points. Put another way, the
> best line breaks with the best word spacing occurs when there are no
> constraints. For example, setting a maximum of 1 successive hyphenated line
> entirely avoids the ladder effect at the ends of lines, but that may result
> in a loose or short line after a hyphenated line. It's a trade-off, which
> is as good as it gets with first-fit H&J.
>
>
>
> Note that the first-fit approach is acceptable when formatting is stored
> with content. In that case, formatting is proofread along with content, and
> bad breaks and incorrect hyphenations are fixed when content errors are
> corrected. In other words, the first-fit formatter's problematic H&J is
> corrected by someone who manually figures out better line breaking for the
> paragraph.
>
>
>
> With dynamic publishing of structured markup content, however, there is no
> review process to find and fix bad breaks and incorrect hyphenation before
> the final version is published.
>
>
>
> This is not an issue with TeX H&J, which is one of the reasons why TeX is
> the best fit for dynamic publishing.
>
>
>
> *7.* The examples at H&J Examples
> <
">http://fosiexpert.com/FOSIvAPP-quality.html> illustrate how first-fit
> "paints itself into a corner," leaving short last and next-to-last lines.
>
>
>
> Regarding short last lines, my understanding is that APP has an
> orphanWordLength property that can be used to specify the minimum number of
> characters that must appear in the last line of every paragraph. If
> necessary, the last word of the next-to-last line is moved to the beginning
> of the last line. But this fixes a short last line by creating a short
> next-to-last line. It's a trade-off.
>
>
>
> *8.* It is unfortunate that TeX's superior H&J is not better known. I am
> trying to do my part to change that.
>
>
>
> *9.* Bugfixes are related to reliability and stability, or lack thereof.
> Skimming available release notes starting with Epic 4.1, which was released
> 15 years ago, my guessestimate is the total number of bugfixes related to
> FOSI/TeX is less than the 250 or more fixes for APP in less than 4 years.
>
>
>
> *10.* Some folks may recall that at one time Arbortext tried to push
> XSL-FO in place of FOSI. However, XSL-FO is slow -- too slow for the Edit
> window -- and Arbortext's support for XSL-FO does not include everything
> possible with a FOSI stylesheet. In addition, XSL-FO does not work with
> very long documents in Arbortext.
>
>
>
> Arbortext assured users they would find a way to speed up XSL-FO (just as
> they are now "expecting" to speed up APP), but eventually they had to give
> up. So they couldn't promote XSL-FO as the only formatting language.
> Unfortunately, some folks found out the hard way that, although FOSI and
> XSL-FO feed the same TeX engine, it runs significantly faster with FOSI.
>
>
>
> After that, Arbortext started pushing APP in place of FOSI, even though
> APP is also slower than FOSI/TeX, and is too difficult and expensive to
> work with except via Styler -- which doesn't support everything possible
> with a FOSI stylesheet.
>
>
>
> Meanwhile, FOSI/TeX continues to be as capable as ever, delivering top
> speed and top quality. FOSI/TeX has only improved with age. Its development
> years are well behind it, and it is in its prime. It is reliable, stable,
> and well-documented.
>
>
>
> *11.* When I was at Arbortext, the product line was marketed to anyone
> who wanted to author and publish SGML/XML content, which included documents
> with layout-based formatting. I helped out Sales by developing
> proof-of-concept FOSIs to show that sales prospects' formatting could be
> supported. Since FOSI was designed for technical documents with consistent
> page layouts, I wasn't always able to find a solution, in which case I
> contacted Engineering. They were often able to advise me on what coding
> would work. When that was not possible, they sometimes found a way to add
> support to the formatting engine in order to sell licenses. Otherwise,
> sales prospects were advised to contact Xyvision about publishing content
> authored in Arbortext Editor.
>
>
>
> The reason Arbortext acquired 3B2 was to eliminate the need to refer sales
> prospects to Xyvision and instead sell an Arbortext product. 3B2 was never
> intended to replace FOSI, which is why 3B2 was renamed * Advanced *Print
> Publisher, not * Arbortext *Print Publisher. APP was a supplementary
> product, Plan B. Back then, Arbortext was pushing XSL (with the TeX
> engine), not APP. Arbortext only started pushing APP after they had to give
> up on XSL.
>
>
>
> But APP is so difficult to learn, with such high-hurdle prerequisites,
> that Arbortext is recommending Styler with the APP engine and source edits.
> This is just bait and switch. An associated APP template is needed if you
> want ligatures (who doesn't?), and a native APP template is needed for
> other formatting. Before you know it, outside consulting turns out to be
> required to develop a native APP application.
>
>
>
> Is there any guarantee that all of APP functionality can be access via
> Styler? Is that even feasible? If not, then what?
>
>
>
> In the meantime, those using APP Styler get to live through the shakedown
> period as more APP functionality is added to Styler. We have seen that
> bugfixes can number in the hundreds. However, to take advantage of them,
> users must continually migrate to each new release.
>
>
>
> Clearly, it's way too soon for APP Styler to be Arbortext's main
> formatting solution.
>
>
>
> Suzanne Napoleon
>
>
www.FOSIexpert.com
>
>
