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

FOSI Retirement Notice

FOSI Retirement Notice

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 (spanSmiley Tongueageflow)
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

FOSI Retirement Notice

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

FOSI Retirement Notice

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

FOSI Retirement Notice

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.

FOSI Retirement Notice

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

FOSI Retirement Notice

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

FOSI Retirement Notice

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

FOSI Retirement Notice

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
Highlighted

RE: FOSI Retirement Notice

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

FOSI Retirement Notice

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
>