Skip to main content
P
ptc-22689331-Visitor
1-Visitor
January 24, 2013
Question

moving customizations from 5.4 to 6.0

  • January 24, 2013
  • 14 replies
  • 2232 views

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

    14 replies

    P
    ptc-48751351-Visitor
    1-Visitor
    January 24, 2013
    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


    N
    naglists1-Visitor
    1-Visitor
    January 24, 2013
    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 [
    L
    largyres1-Visitor
    1-Visitor
    January 24, 2013


    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


    A
    AndyEsslinger1-Visitor
    1-Visitor
    January 24, 2013
    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
    N
    naglists1-Visitor
    1-Visitor
    January 24, 2013
    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).


    L
    largyres1-Visitor
    1-Visitor
    January 24, 2013

    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

    D
    DavidS.Taylor1-Visitor
    1-Visitor
    January 24, 2013
    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>


    L
    largyres1-Visitor
    1-Visitor
    January 24, 2013

    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<


    A
    AndyEsslinger1-Visitor
    1-Visitor
    January 24, 2013
    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
    N
    naglists1-Visitor
    1-Visitor
    January 24, 2013
    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
    Show more replies
    Terms & ConditionsCookie settingsAccessibility statement