Plugin not called for all pre-process extension points for PDF transform

Desired Goal

I’m attempting to update an old job we have - we have a custom Python script which converts textual instances of @@VAR:SomeTextHere into <keyword keyref="SomeTextHere_first"> the first time the keyword is seen and <keyword keyref="SomeTextHere_other"> for subsequent uses. These keywords are defined in the ditamap.

I don’t want to modify the real source files, and ideally I don’t want to have a 2-stage process of:

• Parse ditamap, copy all referred ditas to a temporary location and modify those files
• Run dita over the new files.

So I thought I could hook into the dependency points once the dita files have been copied across to the temporary directory, and modify them there.

Expected Behavior

Using DITA-OT I expect my plugin to be called for the extension points defined in the docs (https://www.dita-ot.org/3.2/extension-points/plugin-extension-points-pre-processing.html) when performing PDF transform.

Actual Behavior

It’s only called for depend.preprocess.pre and depend.preprocess.post.

Possible Solution

• PDF transforms are provided by org.dita.pdf2.
• https://github.com/dita-ot/dita-ot/blob/3.2/src/main/plugins/org.dita.pdf2/build_template.xml defines the build template used for a transformation.
• It has preprocess2 as a target.
• As far as I can see, https://github.com/dita-ot/dita-ot/blob/3.2/src/main/plugins/org.dita.base/build_preprocess2_template.xml doesn’t have the same dita:depends targets as https://github.com/dita-ot/dita-ot/blob/3.2/src/main/plugins/org.dita.base/build_preprocess_template.xml.
  • For example, {depend.preprocess.clean-temp.pre} exists in build_preprocess_template.xml but not build_preprocess2_template.xml.

Possible solution is to add in the old preprocessing targets.

I’m also open to any other solutions to my problem!

Environment

• DITA-OT version: 3.2
• Operating system and version: Linux
• How did you run DITA-OT? dita command
• Transformation type: PDF

[Herbert-SDL]

@robander No problem! In the meantime, I’ve implemented the custom preprocessing pipeline and it works very well.

[Herbert-SDL]

@robander Thank you for clarifying. As said, I consider my current solution a hack, as I changed one of the standard files of the toolkit. Never considered having a custom preprocessing pipeline, but I’ll try that instead.