FOSI to Styler: Philosophical changes?

naglists · ‎Dec 06, 2006

I'm diving into Styler for the first time with an actual production
requirement (I've only dabbled, previously). Can anyone who has made
the transition from FOSI to Styler (or even just added Styler to their
skillset) give any pointers for how Styler is different from FOSI?

I'm not looking for interface, underlying code (program or
stylesheet), or anything of the technical sort. More just a heads up
for anything Styler approaches differently, any assumptions that are
different, etc.

--
Paul Nagai

jdreystadt · ‎Dec 06, 2006

Given that I work for PTC-Arbortext, I often don't respond to questions
like Paul's because I want the community to respond not give an official
position statement which might cut off other people. But I will make an
exception here just to mention two things that suddenly became much much
easier. So easy that someone coming from a FOSI background might avoid
just because of bad memories.

The first is page sets. For those of us who learned FOSIs just by
messing around with other people's, page sets were always hard to
understand and even harder to create new. These have become much easier,
so doing fancy pages for front matter, back matter or even just special
tables or graphics is much more approachable.

The second is complicated gentext. I have a Styler example (it will be
in the install tree of 5.3) that gentexts multiple full page tables to
do some fancy layout for the cover page, inside front cover, and back
cover. The problem with FOSI was trying to get all of the markup for a
table buried into the attribute value. Now you can just use the gentext
authoring area.

John Dreystadt
Software Development Director
Arbortext - PTC
734-327-6079
-

naglists · ‎Dec 06, 2006

> I offered my impressions of Styler in an Adepters posting sometime during
> late summer of 2005 (possibly August). Not sure if that's more than you
> wanted or something else completely.

Thanks for the pointer. I found your August 16, 2005 note. I had saved
it, actually, into a special folder for just such posts. A good thing
since I can't search the adepters archives (it's a long tortured
story) and my "personal" gmail archives only go back to March of this
year. (Now if I had only remembered I'd saved it ...)

> There was also a few presentations on Styler at last year's PTC User
> conference. If you attended that, I recommend looking at Janet Erickson's
> presentation titled "Getting the Most Out of Styler". It's only 25 slides
> and should help.

Another excellent idea. I'll dig up my CD (or see if I can find it on
ptcuser.org).

Has inheritance changed at all? I think I'm seeing para's inherit
formatting from titles which are simply siblings, but it is entirely
possible this is output specfic (HTML Help) or I only think I'm seeing
that and something else is wrong (like maybe I've got chapter defined
incorrectly).

--
Paul Nagai

ptc-1787870 · ‎Dec 06, 2006

Hi Paul,

> Has inheritance changed at all? I think I'm seeing
> para's inherit formatting from titles which are simply
> siblings

Is Styler's formatting element for title listed before the one for the
misbehaving para?

It's been a while since I've used Styler regularly, but I believe that the
structure *and* order of formatting objects can be important. This order
means something a little different than the term occurrence from
FOSI-speak.

This is probably an XSL-ism, part of the new DITA support, or both. I
believe more details can be found in help 7716 (5.2M020, scroll to the
"Priority" topic). In short, there's a relatively new "eicorderispriority"
setting available in FOSI to help parse situations where multiple
formatting constructs may apply.

My old-school FOSI background led me to believe that turning
"eicorderispriority" off was a good idea (at least for our data set).
Despite the "less flexible" approach of FOSI, I find a certain peace in
the limitations of formatting by default, by inheritance, by explicit
context (including attribute tests), or by occurrence. That is, insofar as
FOSI developers are allowed to know peace, but that's another story.

Philosophically yours,
Jason

"Paul Nagai" <->
12/06/2006 12:33 PM
Please respond to
-

To
adepters@arbortext.com
cc

Subject
Re: FOSI to Styler: Philosophical changes?

> I offered my impressions of Styler in an Adepters posting sometime
during
> late summer of 2005 (possibly August). Not sure if that's more than you
> wanted or something else completely.

Thanks for the pointer. I found your August 16, 2005 note. I had saved
it, actually, into a special folder for just such posts. A good thing
since I can't search the adepters archives (it's a long tortured
story) and my "personal" gmail archives only go back to March of this
year. (Now if I had only remembered I'd saved it ...)

> There was also a few presentations on Styler at last year's PTC User
> conference. If you attended that, I recommend looking at Janet
Erickson's
> presentation titled "Getting the Most Out of Styler". It's only 25
slides
> and should help.

Another excellent idea. I'll dig up my CD (or see if I can find it on
ptcuser.org).

Has inheritance changed at all? I think I'm seeing para's inherit
formatting from titles which are simply siblings, but it is entirely
possible this is output specfic (HTML Help) or I only think I'm seeing
that and something else is wrong (like maybe I've got chapter defined
incorrectly).

--
Paul Nagai

naglists · ‎Dec 06, 2006

I've gained 'a little' experience in
Styler over the last year or so ... and there has been some significant
improvements in that time ... a key one is xpathing capability. .. we did
what 'ptc' kindly termed as 'load testing' of xpathing capabilities,..
and as a result Styler M030 has some major improvements in xpath handling
built in.

Thanks for your efforts. We've "load tested" parts of other products, so I know what you mean 😉

Be wary if you're going to multiple
outputs ... we've hit some size limitations (mind you our spec is over
600 pages) ... similar to your specval limits in fosi ...we're still digging
in that direction, but just best to start with design economy in mind.

By size, are you talking about the .style itself? I think you're saying
that your requirements across multiple outputs are complex enough to
require enough output-specific coding that the .style has bloated and
causes problems? Or am I off-road there ... I'm not sure I've run into specval limits in FOSI. Would that some maximum number allowed within a single e-i-c?

Can anyone say anything about relative performance between FOSI and Styler? I know there was a huge discussion about the comparison between FOSI and XSL-FO processing speed (FOSI seemed to be 3x faster according to those who volunteered their experiences). I have found a handful of conversations about Styler, but people (Jason again, for one) thought FOSI vs. Styler was approximately equal (at least in comparison to XSL-FO).

One of our applications in development with Styler seems to be processing extremely slowly. I haven't done any actual metrics yet to compare a comparably sized FOSI job, but Styler processing is seeming several X slower than FOSI.

--
Paul Nagai

naglists · ‎Dec 06, 2006

> One of our applications in development with Styler seems to be processing
> extremely slowly. I haven't done any actual metrics yet to compare a
> comparably sized FOSI job, but Styler processing is seeming several X slower
> than FOSI.

This may have been because the formatting engine was set to XSL-FO in
the stylesheet. Help says that the composition engine choices (XSL-FO
and FOSI) produce "nearly" identical results and FOSI is faster (and
more pageset flexible). Edit source will use the language appropriate
for the formatting engine.

--
Paul Nagai