Basic workflow questions for Styler/PE

[ptc-953343]

Can anyone provide insight on a good workflow for dealing with stylesheets
and PE? I'm used to the old publisher environment where I could do
everything locally, it appears that to test a stylesheet I have to install
that stylesheet on PE and to at least add a new stylesheet I have to
restart Tomcat.

My first clarification is that I've been provided a FOSI and I'm just
trying to test it to see how complete it is. When I did put this doctype
and stylesheet into the PE custom directory it seems to have broke even
the sample documents and stylesheets. The FOSI has an error these errors
when I just bring up a document in the editor:
+++++++++++++
[A12670] ERROR: Pagedesc counter variable "folioct" is reset in the
styldesc in an e-i-c that does not start a new page.

[A12670] ERROR: Pagedesc counter variable "nfolioct" is reset in the
styldesc in an e-i-c that does not start a new page.
++++++++++++++

I'm surprised that this or anything else I would have done would affect
the working stylesheets and this is leading to the following workflow
questions:

1) Shouldn't I be able to use Styler on a local machine with a local copy
of the stylesheet/FOSI and test my changes?

When I do this (with the doctype and stylesheet NO longer in PE custom
directory) I get an error that the stylesheet is not there.

2) What's the best way to setup a sandbox area for making stylesheet
changes so I don't affect the production system?

3) What controls the association of a FOSI/Stylesheet to a given DTD?

It seems like there is some link that is making only one FOSI/Stylesheet
avaiable for my test document. In the Editor I'm allowed to go out and
select any stylesheet to try and format with, PE seems to be limited to
the one sitting with the DTD.

Note that I have a DTD that exists in several variations, I have different
FOSI's for these DTDs, what I wanted to do was to test the various FOSIs
with the same document and DTD. If nothing else to get away from the one
with errors and use one of the other FOSIs. I don't expect perfect
results, but I would like to see what happens. Ultimately these are all
variations on the CALS DTD, so I would like to just run my document with
the Arbortext CALS FOSI if nothing else.

Any tips and suggestions on getting the initial environment setup for
efficient use and safe production would be greatly appreciated.

..dan

[naglists]

>
> 1) Shouldn't I be able to use Styler on a local machine with a local copy
> of the stylesheet/FOSI and test my changes?

> When I do this (with the doctype and stylesheet NO longer in PE custom
> directory) I get an error that the stylesheet is not there.

I'm not totally sure I understand the distinction you're making here. I do
development with a local copy of my stylersheet. I maintain a different
screen FOSI, so I flip back and forth renaming whichever stylesheet I'm not
working with at the time to application.fos.current or something like that
so Editor/Styler will ignore it. When I'm testing locally, I have to issue
set peservices=no at the start of each Styler session in order to use the
local composition process.



> 2) What's the best way to setup a sandbox area for making stylesheet
> changes so I don't affect the production system?


If you truly want to isolate yourself from the prod system ... it means
having another PE license (your accountant will love you for that) and a
separate server (or VM image or whatever your virtualization strategy is).
What I have done, however, which doesn't isolate me system-wise, isolates my
development, test/qa, and production stylesheets.

I always distribute three stylesheets when releasing an application for the
first time:
application.style (could be .fos, depends on the app)
z_dev.style
z_test.style

(The z-naming ensures that the "correct" stylesheet is the default selected
in the compose dialog. Recent versions of Editor may be able to
programmatically specify the default voiding this naming scheme.)

One PE restart and all of those are available. Then I develop locally. I
post a "draft" to PE as z_dev.style. (No PE restart required for this to get
picked up.) When I'm satisfied, I "advance" z_dev.style to z_test.style and
my lead authors do test and qa against z_test.style. Now I can move on to
the next feature set in z_dev.style. Once z_test.style is approved, I
advance it to application.style, my lead authors do a quick smoke test, and
then announce it to the rest of the authors.



> 3) What controls the association of a FOSI/Stylesheet to a given DTD?

It seems like there is some link that is making only one FOSI/Stylesheet
> avaiable for my test document. In the Editor I'm allowed to go out and
> select any stylesheet to try and format with, PE seems to be limited to
> the one sitting with the DTD.
> Note that I have a DTD that exists in several variations, I have different
> FOSI's for these DTDs, what I wanted to do was to test the various FOSIs
> with the same document and DTD. If nothing else to get away from the one
> with errors and use one of the other FOSIs. I don't expect perfect
> results, but I would like to see what happens. Ultimately these are all
> variations on the CALS DTD, so I would like to just run my document with
> the Arbortext CALS FOSI if nothing else.


There is a whole series of "rules" and priority and whatnot for making that
choice. Normally if your doctype and stylesheet have the same name, they are
associated. There is also a processing instruction you can use to force an
association. Our doctype/stylesheet associations are static, so I don't do a
lot here ... take what I said with a grain of salt. Hopefully someone who
changes things around more will reply with more authority/detail. Or at
least good pointers for what to search for in Help.

--
Paul Nagai

[naglists]

>
> One PE restart and all of those are available. Then I develop locally. I
> post a "draft" to PE as z_dev.style. (No PE restart required for this to get
> picked up.)
>

I should add that every once in a great while, PE clutches a stylesheet and
won't let go and a restart *is* required. It's very rare, though, and
inevitably I spend an hour or two scratching fruitlessly at the dirt before
thinking, hmmm, this is one of those times.

--
Paul Nagai

[ptc-953926]

My experience is that we always have to restart the server. The only time I don't is if it's a FOSI that isn't used very often (Japanese, for example). But then, we're doing 30-100 compositions per hour, so PE rarely lets go of a FOSI.

Dave Hintz

[naglists]

Do you think PE would hold onto z_dev.fos if you were the only one using it?

[ptc-953926]

I'm not the one who maintains PE, so I don't know what z_dev.fos is. But I do maintain the FOSIs and I know that even if PE is not running any compositions, the two instances of Epic.exe running keep a copy of the FOSI and I need to restart the server so that it reads a new version.

[steve.thompson4]

When you say "restart the server", do you mean a literal restart, or just a 'toggle' of Tomcat?

Curious,
Steve Thompson
TAD Technical
Boeing-IDS Technical Publications
+1(316)977-0515
MC K83-08
The truth is the truth even if nobody believes it, and a lie is a lie even if everyone believes it.

NOTICE: This communication may contain proprietary or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this e-mail in error, and delete the copy you received. Any and all views expressed are the current understanding of the sender and should not be interpreted as an expression of official Boeing Company policy or position.

Les renseignements contenus dans ce message peuvent être confidentiels. Si vous n'êtes pas le destinataire visé ou une personne autorisée à lui remettre ce courriel, vous êtes par la présente avisé qu'il est strictement interdit d'utiliser, de copier ou de distribuer ce courriel, de dévoiler la teneur de ce message ou de prendre quelque mesure fondée sur l'information contenue. Vous êtes donc prié d'aviser immédiatement l'expéditeur de cette erreur et de détruire ce message sans garder de copie.

[ptc-953926]

I meant that I restart Tomcat.

[naglists]

I have occasionally heard from other people that they *must* restart PE any
time they update a stylesheet. I do not know why this is sometimes the case.
I have great "luck" deploying the three versions of my stylesheet, updating
them, and using them without Tomcat restarts.

Saying it another way, I deploy these three stylesheets and restart Tomcat:
app.fos
z_dev.fos
z_test.fos

At initial deployment, they are all the same.

During development, I constantly update z_dev.fos (it could be z_dev.style,
too). Without a Tomcat restart, PE re-reads z_dev.fos picking up my latest
changes and then composes. When I'm done, I delete z_test.fos. Copy
z_dev.fos and rename it to z_test.fos. Now, when my test/qa authors check my
work, they use z_test.fos and PE again re-reads z_test.fos and uses it for
composition without a Tomcat restart. When they approve, I delete app.fos,
copy z_test.fos, and rename it as app.fos.

I can't remember exactly, but I have this vague recollection that John
Dreystadt or John Lloyd explained some of the subtleties of how/when a
stylesheet gets re-read.

[ptc-953343]

>>
>> 1) Shouldn't I be able to use Styler on a local machine with a local
>> copy
>> of the stylesheet/FOSI and test my changes?
>
>> When I do this (with the doctype and stylesheet NO longer in PE custom
>> directory) I get an error that the stylesheet is not there.
>
> I'm not totally sure I understand the distinction you're making here. I do
> development with a local copy of my stylersheet. I maintain a different
> screen FOSI, so I flip back and forth renaming whichever stylesheet I'm
> not
> working with at the time to application.fos.current or something like that
> so Editor/Styler will ignore it. When I'm testing locally, I have to issue
> set peservices=no at the start of each Styler session in order to use the
> local composition process.


<drv>I think the issue is the peservices variable, I think that will fix
my Styler issues.


>
>
>
>> 2) What's the best way to setup a sandbox area for making stylesheet
>> changes so I don't affect the production system?
>
>
> If you truly want to isolate yourself from the prod system ... it means
> having another PE license (your accountant will love you for that) and a

<drv>No PTC will love me, the accountant will run me out of the company
😉 I missed the relationship of the peservices setting and what that
would cause Styler to do, I would have expected it to switch off PE as its
a development tool.


> separate server (or VM image or whatever your virtualization strategy is).
> What I have done, however, which doesn't isolate me system-wise, isolates
> my
> development, test/qa, and production stylesheets.
>
> I always distribute three stylesheets when releasing an application for
> the
> first time:
> application.style (could be .fos, depends on the app)
> z_dev.style
> z_test.style
>
> (The z-naming ensures that the "correct" stylesheet is the default
> selected
> in the compose dialog. Recent versions of Editor may be able to
> programmatically specify the default voiding this naming scheme.)
>
> One PE restart and all of those are available. Then I develop locally. I
> post a "draft" to PE as z_dev.style. (No PE restart required for this to
> get
> picked up.) When I'm satisfied, I "advance" z_dev.style to z_test.style
> and
> my lead authors do test and qa against z_test.style. Now I can move on to
> the next feature set in z_dev.style. Once z_test.style is approved, I
> advance it to application.style, my lead authors do a quick smoke test,
> and
> then announce it to the rest of the authors.

So this sounds like you keep your development efforts all in the same
directory. Or do you develop and test elsewhere and switch peservices off
and on? Is there an advantage to leaving everything in the PE
environment/directories? I'm leaning towards keeping the pure development
and sandbox area in a different location. I can see using your convention
for testing by others.

This switching between stylesheets at compose time is related to the next
question. When PE comes up and shows me the sytlesheet its going to use,
there is only one in the list. I do have the association PI in my
document, maybe that is limiting my choices rather than just specifying
the default selection.


>
>
>
>> 3) What controls the association of a FOSI/Stylesheet to a given DTD?
>
> It seems like there is some link that is making only one FOSI/Stylesheet
>> avaiable for my test document. In the Editor I'm allowed to go out and
>> select any stylesheet to try and format with, PE seems to be limited to
>> the one sitting with the DTD.
>> Note that I have a DTD that exists in several variations, I have
>> different
>> FOSI's for these DTDs, what I wanted to do was to test the various FOSIs
>> with the same document and DTD. If nothing else to get away from the one
>> with errors and use one of the other FOSIs. I don't expect perfect
>> results, but I would like to see what happens. Ultimately these are all
>> variations on the CALS DTD, so I would like to just run my document with
>> the Arbortext CALS FOSI if nothing else.
>
>
> There is a whole series of "rules" and priority and whatnot for making
> that
> choice. Normally if your doctype and stylesheet have the same name, they
> are
> associated. There is also a processing instruction you can use to force an
> association. Our doctype/stylesheet associations are static, so I don't do
> a
> lot here ... take what I said with a grain of salt. Hopefully someone who
> changes things around more will reply with more authority/detail. Or at
> least good pointers for what to search for in Help.

<drv>What I was expecting was the flexibility that the Editor option of
Format - Select Stylesheets allows me when it came time to print.

thanks for the ideas

..dan


>
> --
> Paul Nagai
>

[byork]

An easy way to reload your style sheets if you are using PE 5.3.











Brian York

-

Exmark Mfg. Co.

[steve.thompson4]

It may be dependent on the version of PE, or even of Tomcat within a given PE version. Our oldest PE server, therefore our oldest install of PE, is much more forgiving than our newer or newest. So much more so, that our folks who've been using Arbortext the longest have had a little trouble believing that the newer installs need a Tomcat 'toggle' as often as they do.

And that's not necessarily a difference like PE 5.2 to PE 5.3, but appears to be from a very early 5.2 install to a very late (nearly time for 5.3) install, even though the same Mxxx. The Tomcat versions are different (5.0.28 to 5.5.12), even though the PE version is the same.

Just two cents,
Steve Thompson
+1(316)977-0515

[naglists]

>
> <drv>I think the issue is the peservices variable, I think that will fix
> my Styler issues.
> <drv>No PTC will love me, the accountant will run me out of the company
> 😉 I missed the relationship of the peservices setting and what that
> would cause Styler to do, I would have expected it to switch off PE as its
> a development tool.


Yes, well, ahem. Love/hate it's all just different parts of the spectrum,
right?

Changing peservices changes what Editor does for composition. PE is not
affected. On, Editor retrieves stylesheet options from PE and sends
composition to PE. Off, Editor displays stylesheet options from its own
custom directory and performs composition itself (assuming a Print Composer
license).


So this sounds like you keep your development efforts all in the same
> directory. Or do you develop and test elsewhere and switch peservices off
> and on? Is there an advantage to leaving everything in the PE
> environment/directories? I'm leaning towards keeping the pure development
> and sandbox area in a different location. I can see using your convention
> for testing by others.


If it is a FOSI application, I develop/test my code myself on PE, working in
z_dev.fos. QA on PE with z_test.fos.
If it is a Styler application, I develop/test my code 90% locally, with
peservices=off. Finaly 10% on PE in z_dev.style. QA on PE with z_test.style.

I edit print FOSIs (z_dev.fos) with Textpad across the network.

I edit stylersheets with Styler and it's much, much easier to work locally
because of the tighter integration. Locally, I edit app.style (where app =
the doctype name). When I'm ready to post to prod for my dev testing, I
rename it to z_dev.style before copying it over.

I edit screen FOSIs with Textpad locally. When done, I distribute them to
the network custom folder authors use.


This switching between stylesheets at compose time is related to the next
> question. When PE comes up and shows me the sytlesheet its going to use,
> there is only one in the list. I do have the association PI in my
> document, maybe that is limiting my choices rather than just specifying
> the default selection.

<drv>What I was expecting was the flexibility that the Editor option of
> Format - Select Stylesheets allows me when it came time to print.


Yeah, not much experience with the stylesheet PI so I can't comment on
whether it preferences or limits which stylesheet is selected/shown at all.


thanks for the ideas

Good luck. Let us know what you find out / choose to do.

--
Paul Nagai

[ptc-1908075]

Dan,

The FOSI error messages are valid. The FOSI standard says you can
change a page counter in an e-i-c only when the e-i-c forces a new page (B.3.4.10.9. String and counter variables). If not, Arbortext reports the error message you received.

It's my guess that the FOSI developer did not have Preferences set to see the error messages.
To avoid this sort of situation, I recommend putting the following in instance.acl or other acl file in order to see all errors, warnings, and informational messages during FOSI development:

set gentextwarnings=3;
set formatwarnings=on;
set fosiwarnings=on;


Good luck!
Suzanne
"WYSIWYG is last-century technology!"
www.FOSIexpert.com

[ptc-953343]

thanks. I was surprised at the errors as it was given to me as a
"working FOSI". I mainly put the errors in the message to see if
there was something major that was causing troubles for PE. I put 3
different DTDs and FOSIs in at the same time with a catalog in the
custom directory. These DTDs and sample files work in my local
environment, but not in PE. I was surprised that problems in a new
catalog/DTD/FOSI would cause problems for the standard environment.
My task for Monday will be to try install these one at a time and see
where the problem is coming from.

I was also trying to test print with the Styler print function and
FOSI works and produces a document. I get the errors but it doesn't
fail. So this might be harder to track down than I expect.

thanks everyone for the suggestions on the work flow, next week may
generate additional FOSI questions once I get things configured correctly.

..dan

[ebenton]

When they said "working FOSI", maybe they meant "work in process".

[steve.thompson4]

OTOH, that error message about page counters and new pages doesn't
necessarily prevent the FOSI from functioning. We have had instances of
that message caused by our purposeful arrangement of a FOSI in just that
way. Never mind the 'why'. Doesn't bear discussion (ever received a
requirement that wasn't 'common-sensical'?).

Anyway, the FOSI still functioned, didn't cause our PE to fail, etc. My
point is, this error message is not necessarily the source of a PE
failure, so don't be too disappointed if eliminating it doesn't fix your
problem. Just one more ambiguity in a not-so-black-and-white reality.

Regards,
Steve Thompson
+1(316)977-0515

[ptc-953343]

Yes I agree, especially since Styler will run to completion. I still
havn't got my DTD/FOSI into PE yet, but I have been able to test the FOSI
variations locally. So that is the only error that I'm aware of with what
I tried to install. time to read the manual and be a little more
methodical in the approach. 😉 There are days when you just wished things
would work.

thanks

..dan

> OTOH, that error message about page counters and new pages doesn't
> necessarily prevent the FOSI from functioning. We have had instances of
> that message caused by our purposeful arrangement of a FOSI in just that
> way. Never mind the 'why'. Doesn't bear discussion (ever received a
> requirement that wasn't 'common-sensical'?).
>
> Anyway, the FOSI still functioned, didn't cause our PE to fail, etc. My
> point is, this error message is not necessarily the source of a PE
> failure, so don't be too disappointed if eliminating it doesn't fix your
> problem. Just one more ambiguity in a not-so-black-and-white reality.
>
> Regards,
> Steve Thompson
> +1(316)977-0515
>