moving customizations from 5.4 to 6.0

[ptc-2268933]

Wondering if anyone ran into issues upgrading customizations from 5.4 to 6.0. Could you do it on your own, or did you need external support? We have a unique application and custom folder that rest outside of the install path\custom folder. When we move forward to 6.0, the stylesheets can upgrade, but since i have APTAPPLICATION set I believe, it's not find the java dita.application object. I guess the bigger question is, how do you model customizations forward to the new release?

Thanks

Bryon Thomas

[ptc-4875135]

Bryon,



It depends on the kind of customizations you have. It sounds like you might
have a customized copy of one or more of the ACL scripts shipped as part of
the core Editor or DITA application. This is bad practice, because those
core scripts change all the time, in MOR releases as well as in major dot
releases. The specific error you mention - dita.Application not being found
- makes me think you probably have a copy of dita.acl in your customizations
somewhere (check under 'scripts'). This file underwent major changes between
5.4 and 6.0, as did a lot of the Java code that it calls into. I suspect
that's what you're seeing.



In general, you should never copy the scripts out of the Arbortext install
tree into your customizations and tweak them, because it's going to make
migration much harder.



Chris

[naglists]

We avoid doing this under the same principles Chris describes, but we have,
on occasion, decided there was some behavior we needed to add, modify, or
suppress found in similar code. (Core ACLs, I mean, not specifically the
one Chris suspects you have modified ... we're not a DITA shop.) When so
doing, one can minimize the "future upgrade debt" by keeping such changes
as few and as small as possible, by commenting your changes to the code and
documenting them externally, and by planning for the time required to redo
or abandon those changes when upgrading.

It may also be advisable to simply "overwrite" one specific function. If
you copy just the function of the system ACL you are "fixing," place that
code in your custom folder, and force it into the same package name as in
the system ACL, you can further minimize your exposure to an upgrade
requiring you to recode. That would look something like this:

your_custom_path/scripts/your.acl:
====
package core_acl_package_name

core_function_name() {
...
====

It could be your custom/editinit or custom/init ... as required.




On Thu, Jan 24, 2013 at 5:52 AM, Chris Nitchie <chris.nitchie@oberontech.com<br/>> wrote:

> Bryon,****
>
> ** **
>
> It depends on the kind of customizations you have. It sounds like you
> might have a customized copy of one or more of the ACL scripts shipped as
> part of the core Editor or DITA application. This is bad practice, because
> those core scripts change all the time, in MOR releases as well as in major
> dot releases. The specific error you mention - dita.Application not being
> found - makes me think you probably have a copy of dita.acl in your
> customizations somewhere (check under ‘scripts’). This file underwent *
> major* changes between 5.4 and 6.0, as did a lot of the Java code that it
> calls into. I suspect that’s what you’re seeing.****
>
> ** **
>
> In general, you should never copy the scripts out of the Arbortext install
> tree into your customizations and tweak them, because it’s going to make
> migration much harder.****
>
> ** **
>
> Chris****
>
> ** **
>
> *From:* Bryon Thomas [

[largyres]

We're a non-dita shop as well upgrading from 5.3 to 6.0 because of Win 7 for which 5.3 is no longer "supported." We've pretty much followed Paul's approach modifying a minimum of core ACL functions in the aptcustom init, editinit and scripts as needed.

Along with tracking down re-mapped aliases (see "Arbortext map command" a couple posts back), I found differences in several of those core functions; some where 6.0 caught up to the desired behavior I had customized ... and others where it regressed (thankfully fewer).

Our biggest expense has been switching to FLEX from ELAN licensing; need more floating licenses since I can't remote between different boxes under FLEX.

CEB.com - Continuing Education of the Bar - California

Oakland, CA

In Reply to Bryon Thomas:

Wondering if anyone ran into issues upgrading customizations from 5.4 to 6.0. Could you do it on your own, or did you need external support? We have a unique application and custom folder that rest outside of the install path\custom folder. When we move forward to 6.0, the stylesheets can upgrade, but since i have APTAPPLICATION set I believe, it's not find the java dita.application object. I guess the bigger question is, how do you model customizations forward to the new release?

Thanks

Bryon Thomas

[AndyEsslinger]

Lou,

FYI: I didn't find any problems running Epic 5.3 on Windows 7. Mine is a plain installation with no customization except whatever I did with the FOSI (no ACL, JAVA, XML, XSL, Styler, etc. Init and editinit directories are empty).

My custom\lib directory has feature.cf with everything except print composer turned off
set featurePrintPublishing=on
set feature3B2=off
set featureAdapterDocumentum=off
set featureAdapterFileNET=off
set featureAdapterIBMDM=off
set featureAdapterInterwoven=off
set featureAdapterOracleiFS=off
set featureAdapterWindchill=off
set featureAdapterXMLDocumentum=off
set featureDCAM=off
set featureDLM=off
set featureDMPPublishing=off
set featureDMS=off
set featureImportExport=off
set featureImportMapping=off
set featureInterchange=off
set featureWebPublishing=off
set featureXMLAuthority=off

Just curious,

* What kind of problems did you have when you installed 5.3 on Windows 7?

* Was it political decision (no discussion - just told to "do it")

* I am especially interested in problems that make you want to wade into version 6 instead of going to 5.4 first? A related shop in my area went to 5.4 and my counterpart reports a "butt chewing" every week since that decision was made over a year ago.

So far every change I see from PTC just breaks something else that used to work, so we are holding off updates until we have to. Your position (non-DITA shop upgrading 5.3 to 6.x) is probably the same situation I will be in and I am very interested in the thread.

Thanks,
-Andy

Andy Esslinger LM Aero - Tech Order Data
(817) 279-0442 1 Lockheed Blvd, MZ 4285
(817) 777 3047 Fort Worth, TX 76108-3916

[naglists]

Hey Lou,
How did setting up the ELAN license server go? I've been having trouble. I
managed to get it working, turned it over to an author to test, and now
it's failing again (for me as well). Had to make Windows Firewall changes
on the client (the install method I chose made them on the server).

[largyres]

Andy,

We found that 99%+ of 5.3M030 works fine under Win 7. As described, you should at least have breathing room. IMO some around here have "upgrade-itis," so it was partly political.

Triggering event for learning that 5.3 is not "supported" was not being able to install 5.3 ImportExport Workbench because it couldn't find .NET 3.5+ on 64-bit Win 7. We're heavily dependent on ImportExport for ongoing legacy conversion and exchange with the outside world. Import works, but trying to write or debug MapTemplates without Workbench is beyond me.

Also, outputting our in-house PDF manuals from axdocbook.style drops all combinations of lower-case "fi" because, I suspect, 5.3 Styler's FO engine isn't compatible with Win 7.

CEB.com - Continuing Education of the Bar - California

lou.argyres@ceb.ucla.edu

[DavidS.Taylor]

Lou,

Note that 'fi' is a ligature. When you say it is dropped does this mean the characters are missing in the word, or are they replaced by something that indicates the current font has no 'fi' glyph (U+FB01) available? Anytime I've had a similar situation it has turned out to be an encoding/font/glyph problem.

Have you tried disabling ligatures (I'm not sure how this is done using Styler, I'm using FOSI) to see if it resolves this particular problem for you?

Cheers,

David

David S. Taylor

Project Manager, Production and Marketing
Codes and Evaluations | NRC Construction
National Research Council Canada
Building M-23A, Room 239 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
David.S.Taylor@nrc-cnrc.gc.ca<">mailto:David.S.Taylor@nrc-cnrc.gc.ca>

[largyres]

Thanks for the heads up David.

There's just space where thecharacters are missing. I have no idea how to disable ligatures in Styler. Any ideas where to start looking?

In Reply to David Taylor:

Lou,

Note that 'fi' is a ligature. When you say it is dropped does this mean the characters are missing in the word, or are they replaced by something that indicates the current font has no 'fi' glyph (U+FB01) available? Anytime I've had a similar situation it has turned out to be an encoding/font/glyph problem.

Have you tried disabling ligatures (I'm not sure how this is done using Styler, I'm using FOSI) to see if it resolves this particular problem for you?

Cheers,

David

David S. Taylor

Project Manager, Production and Marketing
Codes and Evaluations | NRC Construction
National Research Council Canada
Building M-23A, Room 239 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
David.S.Taylor@nrc-cnrc.gc.ca<

[AndyEsslinger]

Interesting.

The fi ligature I had to turn off manually in %aptcustom%\inputs\custom.tmx file. If ligaturesenabled =1, it made searches in the PDF files not find words like "figure" and people complained.

\ligaturesenabled=0


5.3m040 is the earliest version that was certified for Windows Vista and I standardized on that; As far as I can determine, it works 100% OK under Windows 7. Support for any 5.3x version ended in 2011 but I haven't needed support.

-Andy

Andy Esslinger LM Aero - Tech Order Data
(817) 279-0442 1 Lockheed Blvd, MZ 4285
(817) 777 3047 Fort Worth, TX 76108-3916

[naglists]

We used to use the following on PE:

$ENV["APTLIGATURESENABLED"] = "no"


I found this mention in adepters archives
> In the end, I 'cured' the problem by turning off ligatures, using a .tmx
file for the doctype.
> This file contained the line
> \ligaturesenabled=0

[largyres]

One of ournetwork tech handles the license server so I can't say.

During testing it had a problem on thelocal box when I tried to add a test licensewith an additional feature. That required a support call, but I couldn't follow what the PTC tech did to restart the FLEX server and force it to recognize the new license.

[largyres]

Thanks all. "APTLIGATURESENABLED = no" did the trick.

[ptc-2268933]

I was able to update my application folder with the 6.0 upgrade by comparing the 5.4 application folder with the custom, then with 6.0, and change as needed. I'm now able to find the java dita.application, however now for some reason Arbortext cant find the ditabase.pcf file in the ditabase folder. It's still listed in the dcf files as @APTAPPLICATION/com.arbortext.dita/doctypes/ditabase/ditabase.pcf. Am I missing something?

[ptc-2268933]

Fixed it. The pcf call in sma-module was supposed to be commented out. Arbortext Editor couldn't handle there being two profile calls from the dcf, so it caput them both and defaulted to the install path. Thanks