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