cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

follow-up

ptc-1908075
1-Newbie

follow-up

1. Content from my emails can be found atFOSI and APP comparison. 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 aDataLogics print FOSIalong with anArbortext authoring FOSIto 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.1Styler Users Guidehad 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 personnelto 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 Arbortextauthored 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 byserendipity.

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 atH&J Examplesillustrate 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 orphanWordLengthproperty 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 Napoleonwww.FOSIexpert.com"WYSIWYG is last-century technology!"
5 REPLIES 5

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.
lfraley
5-Regular Member
(To:ptc-1908075)

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

Hi Liz—

You make a good point. Any time you use a vendor-specific extension you are giving up a certain amount of flexibility and freedom. However, I would say that in this case, “proprietary” is more of a continuum than a simple yes/no. For example, back when XSL-FO first came out, there was no provision for back-of-book indexing in the spec, so of course all the vendors came out with extensions for it, and they all differed a bit in syntax. So, if you wanted a back-of-book index, you had to use some vendor-specific code. Despite that, we were able to adapt XSL-FO stylesheets from RenderX to Arbortext with relatively little pain, since the scope of proprietary features was pretty constrained, and the vast bulk of the stylesheet was standard XSL-FO. (In fact, we even set up the stylesheet so it could automatically adapt to whatever processor was in use. It took a bit of work, but not a huge amount, and it was completely manageable.)

Comparing that kind of proprietary against APP and the effort required to convert something else to APP’s stylesheet language, it seems pretty clear that some things are more proprietary than others.

--Clay

Hi Liz,

You are right that as soon as you go down the extension path you are “proprietary,” but there is also a significant cost difference in moving from a proprietary via extension standards solution to another standards solution of the same standard than going from one language to another language. I would much rather be in a situation where I’ve got multiple choices of open source or vendor vs working with the only vendor supporting a language. But then I’ve been on the standards band wagon for 25 years, so I’m biased.

All that being said, FOSI is very powerful. Styler is a great product if you have basic print requirements that does make getting started easy for someone who knows the basics of composition. I don’t have any experience with APP, so I can’t weigh in there.

Steve

Yes, Steve, it’s unfortunate that Arbortext wasn’t able to get a more streamlined process for XSL-FO publishing implemented. I understand them wanting to leverage the existing FOSI infrastructure for it, but it did make for a pretty inefficient process.

The other thing about XSL-FO is that the XSLT layer has a lot of opportunities for completely ruining the efficiency of the transformation by writing bad XPath. If you don’t know what you’re doing, you can end up with a painfully slow transformation layer. I once took an XSLT stylesheet that took over an hour to publish, and with an adjustment to a single XPath expression made it run in a couple of minutes. XSLT transformations are extremely powerful, but with great power comes great responsibility. 🙂

You’re right about the advantage of being able to avoid license lock. As I indicated in my reply to Liz, adapting an XSL stylesheet from one rendering engine to another isn’t free, but it’s relatively cheap. It’s orders of magnitude cheaper than trying to migrate from FOSI to APP or vice versa.

--Clay
Announcements