Publishing Engine: Problem with relative paths in DITA-OT project file

[ms2art2]

I don’t know if this is a DITA-OT problem or something possibly on your side. I’m using the Publishing Engine, and having trouble getting my WebHelp responsive build to recognize partial relative paths in some of the parameters I’m using in a project file. Here’s a portion of the project file that shows the problem area:

<deliverable name="CNX7 CA" id="CNX7CA">
<context name="CNX7" id="CNX7CAContext">
<input href="./cnx7_enduser_translations_sources/ca/end_user_ddita.ditamap" />
<profile>
<ditaval href="./common/merged.ditaval" />
</profile>
</context>
<output href="./ca/user" />
<publication transtype="webhelp-responsive">
<!--The 'build-resources' folder is in the same folder (/local1/cnxbuild/Documentation) as this project file.-->
<!--The following relative path works. -->
<param name="webhelp.publishing.template" value="./build-resources/lang-switcher/HCLDefault-Embedded.opt" />
<!--The following relative path does not work. -->
<param name="webhelp.fragment.footer" value="./build-resources/lang-switcher/header.xml_all-locales/ca/footer.xml" />
<!--The following relative path works. -->
<param name="webhelp.fragment.before.body" value="/local1/cnxbuild/Documentation/build-resources/lang-switcher/header.xml_all-locales/ca/header.xml" />
</publication>
</deliverable>

It isn't possible for me to use a relative path that starts at the root, because this file is part of some automation that doesn't require a specific build folder in which to run.

I've tried lots of different permutations of short relative paths, without success. Do you have any idea what might be going on here?

Thanks.

[radu_pisoi]

Hi,

I can reproduce the issue you describe, the relative paths for WebHelp fragments are not resolved well when they are specified in a DITA-OT project file. In this case, I think they should be resolved relative to the DITA-OT project file. I will register an issue in our issue tracker.

I see you already use a publishing template, HCLDefault-Embedded.opt. In this case, you can specify the WebHelp fragments in publishing template descriptor. You can use relative paths that will be resolved relative to the publishing template descriptor.

Code: Select all

<publishing-template>
    ...
    <webhelp>
        ...
        <parameters>
            ...
            <parameter name="webhelp.fragment.footer" value="./build-resources/footer.xml" type="filePath" />
            <parameter name="webhelp.fragment.before.body" value="./build-resources/header.xml" type="filePath"/>
        </parameters>

[ms2art2]

Thanks, Radu,

Just for your own interest, the reason I can't use the template descriptor is because I'm building multiple outputs. Each output is in a different language, and has its own translated header and footer fragments.The properties file allows me to describe the multiple outputs, including the fragments to use for each language.

Mike

[radu_pisoi]

Hi,

A publishing template (basically a folder or a ZIP archive) allow you to have multiple descriptors, one for each transformation. This layout is recommended when you have common resources(CSS, fonts, fragments) for multiple builds/customizations.

You can read more about this use case in our documentation: Using a Publishing Template with Multiple Descriptors.