Oxygen XML Forum

Background

Currently we use Oxygen 16.1. Our custom PDF plugin is in an external OT (v1.7) and works with no problems. Our custom transform scenario references jars in the external OT rather than those in the Oxygen path. We downloaded a trial of Oxygen 17.0 to test it with our PDF plugin. We replicated a DITA MAP transform and added the custom parameters, including the jars for the external OT.

Problem

The PDF builds but we get a severe error related to SVG graphics: As a result, the SVGs are not copied to the PDF.

Notes
- This issue does not occur with Oxygen 16.1 running the transform in the external OT. The libraries classpath is the same in both versions.
- This issue disappears with Oxygen 17.0 if we allow Oxygen to add high-priority libraries to classpath.
- the xmlgraphics-commons-1.5.jar does appear to be referenced correctly in our classpath:
C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xmlgraphics-commons-1.5.jar

Here are the libraries referenced in the classpath:

Also, we are using:
- JRE 1.8 (also tested on 1.7 with same result)
- FOP 1.1

Hi,

First of all, in Oxygen 17 it is very easy to configure an external DITA OT installation to use for all transformations.
Just go to the Preferences->DITA page and set there the path to the external DITA OT.
Then run any predefined installation scenario, it should work directly over that external DITA OT without the need to edit it further.

But configuring the transformation scenario libraries path also works for this.

If you look at the library references you customized for Oxygen 16.1, you used there in the path an editor variable called ${dita.dir.url}. That editor variable is automatically expanded by Oxygen to the parameter called dita.dir defined in the Parameters tab.

If you look at the same library references you made in the scenarios for Oxygen 17, you used in them a parameter called ${configured.ditaot.dir.url}. That parameter automatically expands to the main DITA OT folder configured in the DITA preferences page.
You can still use in Oxygen 17 the ${dita.dir.url} parameter like:
if you do not want to change the global used DITA OT installation to your external DITA OT installation.
Regards,
Radu

Thanks Radu!

I should clarify a few things:
* We left all options on the Preferences > DITA page at default
* In 16.1 transform, we did use the {dita.dir.url} parameter
* In 17.0 transform, this parameter did not expand correctly so we are using the {configured.ditaot.dir.url} parameter, which does expand correctly to our external OT. See the full lib output below.
* Given that the 17.0 transform using our external OT works correctly simply when we allow Oxygen to include high-priority libraries (which changes the classpath), it appears as if Oxygen 17 requires a custom jar that is not included in our classpath. Is this the case? Is there a jar that should be included? We can simply always use the Oxygen classpath in the transform but we would prefer to use jars in the external OT.
* IMPORTANT NOTE: The PDF transform also runs in the external OT on a build server. The transform is initiated by a custom shell script that uses the same lib entries as shown above. This transform works correctly. So again, it appears as if the issue is with Oxygen 17.0.

Output
"C:\Program Files\Java\jdk1.8.0_31/bin/java" "-Dhttp.proxySet=true" "-Dhttp.proxyHost=genproxy.amdocs.com" "-Dhttps.proxyHost=genproxy.amdocs.com" "-Dhttp.proxyPort=8080" "-Dhttps.proxyPort=8080" -Xmx1024m -classpath "C:\DITA\PDF\DITA-OT\tools\ant/lib/ant-launcher.jar" "-Dant.home=C:\DITA\PDF\DITA-OT\tools\ant" org.apache.tools.ant.launch.Launcher -lib "C:\DITA\PDF\DITA-OT\lib" -lib "C:\DITA\PDF\DITA-OT\lib\saxon\saxon9.jar" -lib "C:\DITA\PDF\DITA-OT\lib\saxon\saxon9-dom.jar" -lib "C:\DITA\PDF\DITA-OT\lib\dost.jar" -lib "C:\DITA\PDF\DITA-OT\lib\dost-patches.jar" -lib "C:\DITA\PDF\DITA-OT\lib\xml-apis.jar" -lib "C:\DITA\PDF\DITA-OT\lib\xercesImpl.jar" -lib "C:\DITA\PDF\DITA-OT\lib\icu4j.jar" -lib "C:\DITA\PDF\DITA-OT\lib\commons-codec-1.4.jar" -lib "C:\DITA\PDF\DITA-OT\lib\resolver.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\avalon-framework-4.2.0.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\batik-all-1.7.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\commons-io-1.3.1.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\serializer-2.7.0.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xalan-2.7.0.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xercesImpl-2.7.1.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xml-apis-1.3.04.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xml-apis-ext-1.3.04.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\fop\lib\xmlgraphics-commons-1.5.jar" -lib "C:\DITA\PDF\DITA-OT\plugins\org.dita.pdf2\lib\fo.jar" -f "C:\DITA\PDF\build.xml" dita2pdf "-Dtranstype=amdocspdf" "-Dbasedir=C:\DITA\PDF" "-Doutput.dir=C:\Documentation\Dev\INF\src\..\target" "-Ddita.temp.dir=C:\Documentation\Dev\INF\src\..\temp/oxygen_dita_temp" "-Dpdf.formatter=fop" "-Dargs.input=C:\Documentation\Dev\INF\src\INF_Install.ditamap" "-Ddita.dir=C:\DITA\PDF\DITA-OT" "-DbaseJVMArgLine=-Xmx1024m" "-DDOT_VERSION=1.7" -Dmodule=INF_Install -Dmodule.dir=C:\Documentation\Dev\INF\src\..\ -Dverbose=true

The issue has been solved. This jar was left off the classpath:
- ${configured.ditaot.dir.url}/plugins/org.dita.pdf2/fop/build/fop.jar

The source of the confusion was that, previously with our Oxygen 16.1 transform, we did not reference fop.jar and it did work fine. The fop jars and the other jars in the fop distribution such as batik, do not, strictly speaking, seem to be required. I noticed that I can remove batik, xmlgraphics, etc. from the Oxygen 16.1 transform libraries and the PDF still builds correctly. Also, our custom PDF build script on our build server does not add fop.jar or any of the jars included with FOP 1.1 to the LIBS and it works too.

I have a few questions based on this whole thread, just for clarification
1. As I mentioned above, we left the Preferences > DITA page at default and are using the ${configured.ditaot.dir.url} parameter in the library definitions. This parameter correctly expands to the external OT path contained in the dita.dir parameter. Is this how it is supposed to work?
2. If we set the DITA-OT directory in the DITA page to our external OT using a custom environment variable, the dita.dir parameter is instead set to the OT from the Oxygen frameworks dir, which is not correct. This seems like strange behaviour.

Hi,

I'm glad this works for you now. Please see some answers below:

1. As I mentioned above, we left the Preferences > DITA page at default and are using the ${configured.ditaot.dir.url} parameter in the library definitions. This parameter correctly expands to the external OT path contained in the dita.dir parameter. Is this how it is supposed to work?

I'm not sure I'm following this.
The new editor variable ${configured.ditaot.dir.url} added in Oxygen 17.0 always resolves to the DITA OT directory configured in the Preferences->"DITA" configuration page.
All transformation scenarios which come bundled with Oxygen 17.0 use this new editor variable as a value for the dita.dir parameter.
If your custom transformation scenarios use another value for the dita.dir parameter, the publishing will use that referenced DITA OT.

2. If we set the DITA-OT directory in the DITA page to our external OT using a custom environment variable, the dita.dir parameter is instead set to the OT from the Oxygen frameworks dir, which is not correct. This seems like strange behaviour.

Your transformation scenario has been created and saved in Oxygen 16.1. And it has certain parameters which already have values. Oxygen 17 does not modify any parameters in already saved transformation scenarios, so this is why your older scenarios still have a custom value set for the dita.dir parameter, meaning that the DITA OT directory configured in the DITA preferences page will not be used when publishing.

Regards,
Radu