Customizing com.oxygenxml.pdf.css DITA-OT plugin
Posted: Thu Mar 18, 2021 3:12 am
Hi,
I have been trying to figure out why my custom HTML5 DITA-OT plugin works properly in a straight HTML5 build, but this same HTML5 plugin does not seem to be called at all during execution of the oxygenxml.pdf.css plugin (which uses DITA-OT's HTML5 plugin).
I saw that the com.oxygenxml.pdf.css plugin defines its own extension point, so I tried making another plugin to hook in my HTML5 customizations that way - it still doesn't work.
I took a closer look at the com.oxygenxml.pdf.css plugin, and it seems that it explicitly imports all its own XSL using relative paths into the org.dita.html5 plugin. In other words, it doesn't seem to participate in DITA-OT's usual "make a new plugin and copy-the-template-to-override-behavior" approach.
So my first question is this: Is my assessment of this situation correct?
Next question: If I'm correct, then what is the best strategy for customizing the HTML5 part of the com.oxygenxml.pdf.css plugin? It seems like we must either directly edit the XSL in the oxygenxml.pdf.css plugin (in this case it's the file html5-figures.xsl), or, we can duplicate the entire com.oxygenxml.pdf.css plugin and make our customizations. This way we leave the base plugin intact. Is there another, better way that I'm missing?
If I'm correct, I'm very curious to understand why the com.oxygenxml.pdf.css plugin seems to skirt the usual DITA-OT plugin override mechanism. The plugin does use the override mechanism for its own customizations of the HTML5 build, however, it seems to put up a wall that prevents other plugins from customization of HTML5. Was there a technical reason that necessitated this design?
Thanks,
John
I have been trying to figure out why my custom HTML5 DITA-OT plugin works properly in a straight HTML5 build, but this same HTML5 plugin does not seem to be called at all during execution of the oxygenxml.pdf.css plugin (which uses DITA-OT's HTML5 plugin).
I saw that the com.oxygenxml.pdf.css plugin defines its own extension point, so I tried making another plugin to hook in my HTML5 customizations that way - it still doesn't work.
I took a closer look at the com.oxygenxml.pdf.css plugin, and it seems that it explicitly imports all its own XSL using relative paths into the org.dita.html5 plugin. In other words, it doesn't seem to participate in DITA-OT's usual "make a new plugin and copy-the-template-to-override-behavior" approach.
So my first question is this: Is my assessment of this situation correct?
Next question: If I'm correct, then what is the best strategy for customizing the HTML5 part of the com.oxygenxml.pdf.css plugin? It seems like we must either directly edit the XSL in the oxygenxml.pdf.css plugin (in this case it's the file html5-figures.xsl), or, we can duplicate the entire com.oxygenxml.pdf.css plugin and make our customizations. This way we leave the base plugin intact. Is there another, better way that I'm missing?
If I'm correct, I'm very curious to understand why the com.oxygenxml.pdf.css plugin seems to skirt the usual DITA-OT plugin override mechanism. The plugin does use the override mechanism for its own customizations of the HTML5 build, however, it seems to put up a wall that prevents other plugins from customization of HTML5. Was there a technical reason that necessitated this design?
Thanks,
John