FOSI Retirement Notice

[ptc-953422]

I just read about PTC's plans for FOSI retirement-see below. The news came to me on Friday in "(Updated) - 2014 Arbortext Announcements" in my daily "PTC Technical Support Subscriptions" email

The announcement below says they will continue to include the FOSI composition engine in future releases, but will no longer have any maintenance releases or patches related to it.

So, I'm wondering, Should we start migrating our FOSI style sheets to Styler or should we continue to put all our eggs in the FOSI basket since the composition engine that works for us now will be available with future Arbortext products?



2014 Arbortext Announcements

July 2015: FOSI Retirement Notice

* Beginning July 1, 2015, PTC will change the level of support for the FOSI composition engine from Standard to Sustained.

* This includes the use of XSL-FO, the FOSI Editor and the Arbortext line numbering application.

* Customers with an active Global Support agreement may continue contact PTC Technical Support as well as have continued access to technical support web tools, the knowledgebase and prior maintenance releases.

* However, there will be no additional maintenance releases or patches related to the FOSI composition engine.

* The FOSI composition engine will continue to be included in the Arbortext suite of products, and customers may continue to use existing FOSI stylesheets.



--Jack
LSI, Inc.
Jacksonville, FL

[naglists]

My 12/5 PTC Technical Support Subscriptions email did not include this
notice.

And: Gah!



On Mon, Dec 8, 2014 at 9:42 AM, Kulas, Jack <->
wrote:

> I just read about PTC's plans for FOSI retirement--see below. The news
> came to me on Friday in "(Updated) - 2014 Arbortext Announcements" in my
> daily "PTC Technical Support Subscriptions" email
>
>
>
> The announcement below says they will continue to include the FOSI
> composition engine in future releases, but will no longer have any
> maintenance releases or patches related to it.
>
>
>
> So, I'm wondering, Should we start migrating our FOSI style sheets to
> Styler or should we continue to put all our eggs in the FOSI basket since
> the composition engine that works for us now will be available with future
> Arbortext products?
>
>
>
>
>
>
>
> 2014 Arbortext Announcements
>
>
>
> July 2015: FOSI Retirement Notice
>
> · Beginning July 1, 2015, PTC will change the level of support
> for the FOSI composition engine from Standard to Sustained.
>
> · This includes the use of XSL-FO, the FOSI Editor and the
> Arbortext line numbering application.
>
> · Customers with an active Global Support agreement may continue
> contact PTC Technical Support as well as have continued access to technical
> support web tools, the knowledgebase and prior maintenance releases.
>
> · However, there will be no additional maintenance releases or
> patches related to the FOSI composition engine.
>
> · The FOSI composition engine will continue to be included in the
> Arbortext suite of products, and customers may continue to use existing
> FOSI stylesheets.
>
>
>
>
>
>
>
> --Jack
>
> LSI, Inc.
>
> Jacksonville, FL

[jsillari]

"Surprise, surprise, surprise!"

John Sillari
Chief Technologist
Technical Services Division
Dayton T. Brown, Inc.

On Dec 8, 2014, at 11:51, "Paul Nagai" <-<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">>">mailto:->> wrote:



My 12/5 PTC Technical Support Subscriptions email did not include this notice.

And: Gah!



On Mon, Dec 8, 2014 at 9:42 AM, Kulas, Jack <-<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">>">mailto:->> wrote:
I just read about PTC’s plans for FOSI retirement—see below.  The news came to me on Friday in “(Updated) - 2014 Arbortext Announcements” in my daily “PTC Technical Support Subscriptions” email

The announcement below says they will continue to include the FOSI composition engine in future releases, but will no longer have any maintenance releases or patches related to it.

So, I’m wondering, Should we start migrating our FOSI style sheets to Styler or should we continue to put all our eggs in the FOSI basket since the composition engine that works for us now will be available with future Arbortext products?



2014 Arbortext Announcements

July 2015: FOSI Retirement Notice

•         Beginning July 1, 2015, PTC will change the level of support for the FOSI composition engine from Standard to Sustained.

•         This includes the use of XSL-FO, the FOSI Editor and the Arbortext line numbering application.

•         Customers with an active Global Support agreement may continue contact PTC Technical Support as well as have continued access to technical support web tools, the knowledgebase and prior maintenance releases.

•         However, there will be no additional maintenance releases or patches related to the FOSI composition engine.

•         The FOSI composition engine will continue to be included in the Arbortext suite of products, and customers may continue to use existing FOSI stylesheets.



--Jack
LSI, Inc.
Jacksonville, FL
----------

[GarethOakes]

We had heard rumours of this. Here is a link for anyone who hasn’t received the notice yet:

[SarahPrice]

So I read the notice and my question is how long will it before they stop remove it completely? Should we start looking at Styler or Print Publisher?

Any insight would be appreciated.

Sarah R. Price
Developer
Enterprise Information Services, Inc.
USCG ISD Bldg 63 ALC
Elizabeth City NC 27909

[JeffStevenson]

While PTC will no longer be actively developing FOSI, it doesn't benefit them to remove it just yet. There are still a lot of companies and government bodies that have FOSI as the standard. It would be difficult for them to move away from FOSI too quickly for cost and logistical reasons.

[LynnHales]

Logic is not a key trait to MBA’s concerned only with the bottom line. PTC has continually shown their disdain for Epic to the point I am not sure why they bought it in the first place.

I am glad I am getting close to retiring. Between the BS at CSC, with our contractor, and now this; it may be time to stop (or go part time somewhere).



Lynn

[GarethOakes]

Hi Sarah,

This is a good point. Personally speaking, I don’t think FOSI will be removed from Arbortext in the short- nor medium term. Remember that FOSI is deeply embedded in Arbortext for styling of markup for screen display. However as you say it never hurts to think of the future. Especially as deprecation of FOSI also affects the Arbortext XSL-FO support.

I’m interested in what options yourself and the Arbortext community are considering? Most of our clients are off of FOSI now, and we tend to use a mix of technologies depending on the circumstance: XSL-FO (non-Arbortext), APP (if complex), Styler (if DITA), and our “secret sauce” CompML (best blend of power vs usability, think XSL-FO for APP).

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

[ptc-953422]

Gareth,

Until last week my group had never seriously contemplated converting our huge FOSI, developed over 10 years, to Styler. We’ve always been able to do whatever print/PDF styling we needed using FOSI, thanks to a lot of help from the exceptionally amazing Adepters community and from Editor Help. And it seemed FOSI would go on forever, like COBOL ☺

But even though PTC says it will continue to provide the FOSI composition engine in future Arbortext products, it seems now to be prudent to explore conversion, given PTC’s track record with Arbortext products. I’m not the only one who thinks PTC could pull the plug on FOSI at any time, whenever they want, am I?

I’ve started to consider conversion, but already run into a number of obstacles and questions.

My first foray at conversion using the Editor 6.1 menu option Styler --> Convert Stylesheet… ended in immediate error message: “[A19348] fosi2styler: invalid or incomplete FOSI stylesheet.” When I looked at incompatibilities of FOSI with Styler, the list contained many FOSI features we use often, e.g., boxing , chgmark, floats and floatloc, fillval, highlt, test values (specval) that use #FOSI, system-var, etc. See Help 5803, Help 5808.

And not having a copy of the “full version” of Styler seems to be a serious limitation to exploring conversion. We only have the free version packaged with Editor, which is for editor-window formatting only, not print formatting. I just got a quote from our reseller for the full version: $6700 less a $700 (?) discount. Does it make sense for us now to pony up $6K to begin the conversion-development effort? [And it does seem that it would be a significant development effort, given our FOSI with over 500 EICs, 40 pagesets, over 4000 att-clauses, etc., etc.] I’m wondering what sort of PTC help or guidance would be available for conversion if we did get the full version. Would the only alternative be high-priced PTC consultation?

And one last question, about publishing Styler-styled documents. Can Print Composer be used for that, or does one need to step up to the next level of PE or APP?

The easy thing now is just to Stay Calm and Carry On with FOSI. But it’s hard not to be at least a little worried about what PTC might do next.

--Jack
LSI, Inc
Jacksonville, FL

[ptc-953343]

Some time ago I looked at converting a fairly basic Fosi with styler and ran into the same issues of some very basic functions not being supported in Styler.

I don't know if the basic composition engine changed when Styler was added
I thought it was a new guitar for doing style sheet development that when developed in Styler, you could output to Fosi or xsl. Maybe that evolved overtime.

What do it mean to stop support for Fosi engine? Seems to me that unless app is being brought in as the core engine that Fosi will still be supported but what you can't expect are new features or extensions to the language. Or does Fosi engine equate to print composer? I think the full version of Styler was the replacement for that product on a standalone machine at least.

If you have to switch to xsl then there are other options for composition tools that are better supported and are the companies primary products. See renderx or antenna house for example. So the real problem I think is in the conversion cost from Fosi to xsl. Long run converting to a more universal standard is a good thing although painful. For DoD contracts that specify Fosi you have the additional pain of educating the customer about the change and getting the approval and funding to change.

Sent on a Sprint Samsung Galaxy Note® II

[GregoryMackenzi]

If your considering converting a FOSI, you may well want to check out the PTC Styler Documentation, here’s an excerpt:

Converting a FOSI to a StylerSheet
Arbortext Styler provides a conversion utility that partially converts a FOSI to a
StylerSheet. Before converting a FOSI, refer to the following limitations of the
conversion program.
Limitations of converting FOSIs to StylerSheets
The FOSI to Arbortext Styler conversion process does not convert the following
FOSI features because Arbortext Styler does not provide corresponding capabilities:
Borders
Boxing
Change marks (chgmark)
Conditional post space (postsp:condit)
Element-in-contexts whose gitype is pi.
Environment (envdesc)
Floats and float locations (floatloc)
Font width (font:width)
Footnote description (ftndesc)
Highlighting (highlt), score weight (scorewt), score offset (scoreoff), and
foreground percent (forpct)
Hyphenation rule (hyphrule) characteristics other than language
Hyphenation zones (hyphen:zone)
Keep floats out (keeps:floatsout)
L-page column spans (span:pageflow)
Run-in titles
Security description (secdesc)
Sentence spacing (sentxsp)
Word spacing (wordsp)
Use values (fillval)
Test values (specval) that use #FOSI, system-var (other than editor-only,
print-only, html-only), system-func or the use of a textid in the
attval characteristic

The following generated text FOSI features are not converted during the conversion
process, but Arbortext Styler provides corresponding capabilities. Once you have
converted your FOSI, you can duplicate the formatting of these features using the
Gentext properties tab in Arbortext Styler:
Character fills (charfill)
Counters, reset, and enumerate (enumerat)
Generated graphics (putgraph)
Rules (ruling)
Run-in titles
Saved text (savetext)
Use text (usetext)
listitem gentext is converted to bullets, and indentation may need to be modified

Gregory B. MacKenzie, B.F.A.
Programmer II
L-3 Electronic System Services (L-3 ESS)
249 Aerotech Park Drive
Box 960 Enfield Postal Station
Enfield Nova Scotia, Canada, B2T 1K9

[ptc-953343]

I don't like GUIs so in my case with the lack of support in the import function, I decided to just write the Xsan directly. For me it wasn't worth the effort or the expense. We went with a standalone xsl engine and never looked back.


Sent on a Sprint Samsung Galaxy Note® II

[naglists]

And here I was putting off thinking about the little ole' withdrawal of the
Documentum/WDK adapter .... Now this? Yay!

Not.


One of the first questions I have had is not technical. Rather it has to do
with trust. Is it worth risking the effort of converting all my FOSI
stylesheets to Styler or APP/3B2 stylesheets when PTC has shown such a lack
of commitment to non-engineering customers? I trust that if I limit my
capabilities to those required by their engineering customers, Arbortext is
probably a safe bet (at least until I retire However, if I need
authoring and/or publishing capabilities outside of the needs of their
engineering customers, there is much greater risk.


To my technical understanding of the FOSI, APP/3B2, Architect, Styler, text
editor, [3B2 editor?], Print Composer, Publishing Engine equation and some
of the questions that arise there ...

There are two composition engines: FOSI and APP/3B2. PTC just announced
they are no longer updating the FOSI engine. We are worried about how long
it will continue to be available (if not "supported/enhanced").

Both the FOSI and APP/3B2 composition engines are available in Styler and
Publishing Engine (enterprise and developer versions ... not the names they
use, but the logic is right). The FOSI engine is available in Print
Composer ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell
us.

FOSIs can be maintained with Architect and any text editor you love or hate.

APP/3B2 stylesheets can be maintained with _______ [Gareth again!]

Styler can be used to author stylersheets (a term PTC moved away from but
that I always liked) that are de-generalized (compiled?) on the fly to
directly feed the FOSI or APP/3B2 composition engine depending on the
request. Styler can import (some) of some stylesheets. Even if features are
not supported in Styler and stylersheets, you can code for and support them
in source edits. FOSI source edits have the same risk a standalone FOSI
does ... meaning if the FOSI engine is ever fully withdrawn, those source
edits will be unusable.

Whether converting to stylersheets, moving as much of your code into Styler
language as possible while supporting the rest as source edits, reduces
your overall risk or not is an individual exercise.

I don't fully understand how/why XSL/FO is based on FOSI but apparently it
is. I don't know whether there is some non-FOSI way to use XSL/FO but in a
less extended / enhanced / customized fashion or not.

I don't think XSL itself is threatened by the potential withdrawal of FOSI
so XSL/XSLT transformations (whether to XML or HTML) are no part of this
conversation at all. Same with export to RTF. Same with DMP.


Hopefully you all will clear up anything I have wrong and fill in anything
I have overlooked.



On Wed, Dec 10, 2014 at 10:27 AM, Dan Vint <->

[ptc-5681790]

The original implementation of XSL, which may no longer be the case, was that you would apply your xslt to your xml to get an xsl-fo intermediate file. This xsl-fo file was then published with a FOSI for the xsl-fo doctype. So, if FOSI is at risk, XSL is at risk within any composition products that PTC deigns to sell. I've never worked with APP/3B2, so it may have some abilities that I'm not aware of.

[ClayHelberg]

You're right, Steve, and PTC did note this dependency in their original announcement.

There's no reason in principle that you couldn't make an XSL-FO renderer that runs on the APP engine, but I don't know of one that exists currently. PTC may or may not be working on such a thing. (I know at one point they were considering the possibility, but I have no idea if it's gone anywhere since then.) Theoretically, a user could even develop such a thing, if they are desperate enough to leverage an existing investment in XSL-FO stylesheets and Arbortext software-though I would think that for the cost of such an effort, it would be cheaper to just get an Antenna House server or something similar.

That is the good news for XSL-FO users: unlike FOSI, if you are publishing via XSL-FO there are a number of alternatives to Arbortext software for generating your rendered output.

--Clay

[ptc-953343]

In today's publishing world there are only two reasons why I would undoubtedly recommend Arbortext. Those reasons being:
- need to work with SGML
- need to use FOSI

This is killing one of those reasons. When Arbortext started they were a publishing oriented company and they had one of the two SGML editors that were available. Softquad was thee other. Both companies had one focus and that was to promote the use of SGML and support general publishing.

That drive no longer exists here and the only concern is to bolt on to a larger product suite where the driver is to have integration with the design tools and process. All other uses of Arbortext are secondary. I'm surprised they support DITA as much as they do.

For the last almost 2 years I've worked at a company where Arbortext is not in the mix. Sure I miss the familiarity of the tool and some of its capabilities, but what I have gained is the old focus of a tool vendor that is focused on publishing and making XML work. That has been a welcome change. Who is the vendor? Synchro Soft and the oxygen editor. I feel loved as a tech pubs professional by this company, just like in the days of SGML.


Sent on a Sprint Samsung Galaxy Note® II

[GarethOakes]

Hi guys,

Conversion from FOSI is going to be difficult no matter which way you turn. Each composition system has its own peculiarities and idiosyncrasies in the way it works, so be necessity any conversion will be lossy. I like the idea of a FOSI-to-XSLFO converter, there is certainly a good amount of overlap in the design of those two composition systems. FOSI-to-CompML is an intriguing thought too, for those wishing to leverage existing Arbortext licenses.

Personally, I don't believe Styler itself will be suitable replacement for most FOSI users on this list. My basis for that judgment is that Styler is only suited to basic document types and output styles e.g. Straight-up techdocs with DITA. If you have a custom doctype or "complex" styling (floats, boxing, etc.) then Styler is going to be trouble. I hope PTC comes up with a better Styler than Styler, but even if they do you can bet its features will be tailored to the manufacturing sector.

BTW, there are a number of organisations besides PTC who can assist with FOSI conversions and so on. GPSL is one of those.

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

[GarethOakes]

Hi Paul,

I can contribute a few answers, hope this helps yourself (and the group).

> Both the FOSI and APP/3B2 composition engines are available in Styler and
> Publishing Engine (enterprise and developer versions ... not the names they
> use, but the logic is right). The FOSI engine is available in Print Composer
> ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell us.

Every Arbortext print-capable product ships with both print engines: FOSI and
APP. These engines can accept Styler stylesheets or their "native" stylesheets.

> FOSIs can be maintained with Architect and any text editor you love or hate.
>
> APP/3B2 stylesheets can be maintained with _______ [Gareth again!]

Styler can create FOSI or APP stylesheets, although the Styler GUI only
exposes/leverages a fraction of the power of each engine.

Native APP stylesheets (called templates) are usually worked on via APP
Desktop. Also most modern APP templates are Javascript so you can use
Javascript editors and so on (Sublime Text Editor, Eclipse, etc.). BTW, APP
Desktop also includes a lot of developer features such as stepwise debugger,
logging, tracing, profiling, etc.

The key point of difference here is that FOSI is a declarative language
whereas APP code is imperative. This doesn't imply one is better than the
other, but the way you work with each language is slightly different.

> I don't fully understand how/why XSL/FO is based on FOSI but apparently it
> is. I don't know whether there is some non-FOSI way to use XSL/FO but in a
> less extended / enhanced / customized fashion or not.

Only the Arbortext implementation of XSL-FO is based on FOSI. Just for
clarity, XSL-FO is a W3C recommendation (a standard). There are a number of
competing XSL-FO implementations, none of which involve FOSI.

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

[ptoor]

Hello all-

In reading some of the responses in this discussion thread, it is apparent there are some misconceptions which we'd like to address.

• 
  
• The announcement to move the FOSI engine from standard to sustained support only applies to print/PDF output, not the use of FOSI for the Edit view.
• 
  
• We currently have no plans to remove FOSI from Publishing Engine,Styler or Print Composer.
• 
  
• FOSI stylesheets will continue to work on all three platforms
• 
  
• FOSI source edits will continue to work in Styler stylesheets on those platforms
• 
  
• There are no plans to remove XSL processing from PE, it is fundamental to how PE produces other output
• 
  

[naglists]

Thanks, Gareth. I knew you would have additional information re: APP.

I should have been clearer with respect to my question about XSL/FO and
FOSI. I know that XSL/FO is a standard and supported by other
companies/technology outside of Arbortext's environment. What I am not
totally clear about is whether it is possible to use Editor and XSL/FO and
some other engine than FOSI to generate a PDF (less the Arbortext
extensions to XSL/FO). And I guess the answer is sort of ... you can author
in Editor if you wish, but to make a PDF via XSL/FO without FOSI, you would
have to use another tool to both create and respond to a "composition
request."



On Wed, Dec 10, 2014 at 5:51 PM, Gareth Oakes <->
wrote:

> Hi Paul,
>
> I can contribute a few answers, hope this helps yourself (and the group).
>
> > Both the FOSI and APP/3B2 composition engines are available in Styler
> and
> > Publishing Engine (enterprise and developer versions ... not the names
> they
> > use, but the logic is right). The FOSI engine is available in Print
> Composer
> > ... I'm not sure whether APP/3B2 is. Someone [Gareth?] will tell us.
>
> Every Arbortext print-capable product ships with both print engines:
> FOSI and
> APP. These engines can accept Styler stylesheets or their "native"
> stylesheets.
>
> > FOSIs can be maintained with Architect and any text editor you love or
> hate.
> >
> > APP/3B2 stylesheets can be maintained with _______ [Gareth again!]
>
> Styler can create FOSI or APP stylesheets, although the Styler GUI only
> exposes/leverages a fraction of the power of each engine.
>
> Native APP stylesheets (called templates) are usually worked on via APP
> Desktop. Also most modern APP templates are Javascript so you can use
> Javascript editors and so on (Sublime Text Editor, Eclipse, etc.). BTW, APP
> Desktop also includes a lot of developer features such as stepwise
> debugger,
> logging, tracing, profiling, etc.
>
> The key point of difference here is that FOSI is a declarative language
> whereas APP code is imperative. This doesn't imply one is better than the
> other, but the way you work with each language is slightly different.
>
> > I don't fully understand how/why XSL/FO is based on FOSI but
> apparently it
> > is. I don't know whether there is some non-FOSI way to use XSL/FO but in
> a
> > less extended / enhanced / customized fashion or not.
>
> Only the Arbortext implementation of XSL-FO is based on FOSI. Just for
> clarity, XSL-FO is a W3C recommendation (a standard). There are a number of
> competing XSL-FO implementations, none of which involve FOSI.
>
> // Gareth Oakes
> // Chief Architect, GPSL
> // www.gpsl.co
>

[ptc-5681790]

The short answer is yes, quite easily. We still use editor but have recently moved pdf production from FOSI with Print Composer to XSLT/XSL-FO with Saxon + FOP. It wasn't a big leap for us because we were already producing HTML via XSLT with Saxon. It's all integrated into our overall build system and ACL customizations to launch the process.

That, of course, is one of the selling points of structured markup; being able to plug and play the best components for your particular needs and not being bound to a single software vendor.

Steve

[ClayHelberg]

Exactly, Steve. I was going to write a very similar response, but you beat me to it. 🙂

At SPSS, several years ago, we had a similar system, though--somewhat ironically--our "external" print engine was actually Print Composer. (We did the transformations externally because they did a lot of hairy document aggregation and fixup before generating the actual FO instance. We basically invented something a lot like DITA before DITA was widely available, so we had code to handle our custom equivalent of bookmap files, resolve cross-references, etc.)

--Clay

[LynnHales]

Actually I know you can use XSL/FO (even the trash that LOGSA is putting out
for 40051 production) with Epic’s Print Composer to get PDF. I’ve done it
(when the FO DID NOT FAIL). If the FO is good, then nothing else was needed.



Lynn

[ptc-5681790]

I should probably clarify that the technical details of the actual implementation of Saxon + FOP is easy. Converting your FOSI to XSL-FO is not. I've tried automating the conversion of FOSI to other languages and it's not a simple task if you make use of nested charsubsets. You could get a head start by converting all your e-i-c's to templates and the contents mapped to basic fo constructs. Your charsubsets could also be mapped to named templates as a start. Then it would be a manual slog fine tuning it all together. One of our limitations is that we are using an industry standard variant, so to gain the benefits of the shared html and fo code, we needed to do the whole thing manually.

Steve

[GarethOakes]

Hi Paul,

Others have indicated that using non-Arbortext XSL-FO is possible. I wanted to chip in with a real life example and some details.

We have recently replaced the composition function for a large (~50 user) Arbortext customer. They were using pretty much the whole shooting match (Editor, PE, Styler, Architect, DLM) hooked up to Documentum. PDFs were produced by the FOSI engine based on heavily source-edited Styler stylesheets. The customer made the strategic decision to switch away from FOSI (with some wisdom, it would seem), which they aligned with a business requirement to update/refresh the style of their PDF deliverables.

We worked with the customer to design, implement, test and document an updated system with all FOSI print dependencies removed. The new system state still includes Editor, DLM and PE but PE is only really used for DLM and some ancillary services. The Arbortext composition pipeline is no more, that function now resides within a set of XProc pipelines (running on Calabash). The XML->PDF transformation steps in each pipeline are implemented using a callout to Antenna House via web services. Saxon is used for XSLT transformations.

We have patched up all the relevant Arbortext server and desktop composition functions to call out to XProc pipelines instead of the built-in composition functions. That means from a user perspective, and even a server perspective, the composition works seamlessly. It just so happens that the PDF is now produced by the Antenna House XSL-FO engine rather than Arbortext FOSI engine.

As Steve mentioned, the process of porting the FOSI stylesheets to XSL-FO was non-trivial and in fact probably the largest part of the project in terms of cost, effort, time, risk. There is a long tail of testing and fixing with stylesheets. XProc is easy to work with, as are web services and Saxon, and we know the Arbortext code packages well enough that hooking up to Calabash wasn't too hairy.

BTW, the customer in question already had a separate set of screen stylesheets for authoring/editing purposes. These FOSI stylesheets were retained for screen use only.

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