Oxygen XML Forum

It seems that if I run a transform on the same ditamap twice, with different profiling condition sets selected each time, the same filename is used for both outputs. So the second output overwrites the first one. It would be more convenient if the output filename can somehow reflect the profiling condition set that was used to create it, perhaps by automatically appending the condition set name towards the end of the filename, just before the file extension. Thank you for considering this. If this feature already exists in some form, I'd appreciate you pointing it out to me.

Hi,

I assume you are publishing to PDF. One option would be to simply create multiple transformation scenarios, one for each profiling condition and each transformation scenario has a different output folder configured.
Or if you want a single transformation scenario there is an Oxygen editor variable named ${activeConditionSet}:
https://www.oxygenxml.com/doc/versions/ ... ables.html
You could use this editor variable in the transformation scenario's "Output" tab for the Output directory field "${cfd}/out/pdf-${activeConditionSet}" or you could use it in the "Parameters" list there is an "args.output.base" parameter which can be set to some name like "my-pdf-${activeConditionSet}". And when publishing Oxygen should expand such editor variables to the profiling condition set which was applied from the Oxygen toolbar.
So if the transformation scenario has in the "FIlters" tab "Use profiling condition: <Currently applied>" then you can change the profiling condition from the toolbar, then run the transformation scenario and obtain a specific named PDF.

Regards,
Radu

Hi jmorales,

If you define your deliverables using DITA-OT project files, you can do this.

DITA-OT 4.0 implemented the following enhancement, which allows the PDF filename to be specified uniquely for each deliverable:

#3682: In DITA-OT project files, allow a PDF <deliverable> to specify its output file name

Oxygen is not yet using DITA-OT 4.0, so we developed a preprocessing workaround to implement this support in another way:

Preprocessing DITA-OT Project Files

We use this preprocessing workaround in our production flow and it is completely reliable. It works both in Oxygen when writers interactively publish deliverables, and in our linux production flow when we batch-publish using Oxygen Publishing Engine.

When Oxygen moves to DITA-OT 4.0, then the preprocessing flow can be discarded and the support for specifying PDF basenames in deliverables will become standard.

Hi jmorales,

I should also mention that if you use DITA-OT project files, then currently you must run transformations from the project file, either from its context menu in the Project view, or by opening it in the editor and clicking on the transformation buttons shown by the editing window CSS.

Our writers want to run transformations directly from the DITA Maps Manager (as that is where they centrally work on their books), so we filed enhancement request EXM-48744 for a way to build relevant deliverables from the DITA Maps Manager in a familiar way:

Feature Request: Show DITA-OT Project File Deliverables in Transformation Scenario List

Thanks, Radu and Crispitude!
For my immediate purposes, it works very well to set args.output.base = ${cfn}_${activeConditionSet}
The other approach, using Preprocessing DITA-OT Project Files, looks like it might be useful when we are publishing all our documents for a release. I will pass this information to our tools specialist to see if he wants to try it out.
Thanks again!