can't get index configuration to work

[Gertone]

Dear all,
Using Oxygen 25 to generate PDF from DITA ('org.dita.pdf2'), I need some changes to the index configuration that I once set up with my customisation scenario. I figured out that the OT 3.x in Oxygen 25 ignores the overwrite of the index files. After some digging I figured out that by default the plugin 'org.dita.index' is used, so I can have my configuration in one place.
Nice, but I don't necessarily want that all the time. Different customisations require different indexing rules. Is there a way for me to control that either from the scenario or inside the customisation?
Thanks
Geert

[Radu]

Hi,
In general we (the Oxygen team) have shifted towards supporting the CSS-based PDF publishing which is easier to customize and we are no longer up to date what happens to the default XSL-FO based publishing between DITA OT releases.
I assume you are using a PDF customization folder, right?
As written in the DITA OT docs, this method of PDF configuration is deprecated and can be replaced with a DITA OT PDF customization plugin:
https://www.dita-ot.org/dev/topics/pdf- ... ion_folder

Looking at the plugin.xml file for the DITA-OT/plugins/org.dita.index/plugin.xml, it has an extension point:
https://www.dita-ot.org/dev/extension-p ... pdf2.index
which would mean that a separate DITA OT PDF customization plugin could implement this extension point.

Regards,
Radu

[Gertone]

Thanks for your reply, Radu.
I am using customisation directories on the PDF2.

The business scenario is as follows:
a company has a number of technical writers, all preparing technical manuals for various customers from Oxygen. Each end customer has different requirements on the customisation of their manuals. Each technical writer might have a different scheme in upgrading Oxygen.
so...
- many different customisations
- many Oxygen users, some different versions of Oxygen installed
Packaged scenarios with customisations should be available for all the technical writers and the amount of "things to care about" when upgrading Oxygen should be minimal

I need to check if the plugin approach from your references fits the above scenario
Will look into that, thanks for the suggestions

[Radu]

Hi,
The decision to deprecate the PDF Customization folder was not ours, the DITA OT project is open source and it evolves in its own ways.
Other than that maybe you could have a DITA OT folder for each specific client, each DITA OT with its own PDF customization plugin installed in it. A DITA OT folder can be packed as an add-on in order to install it for each user by selecting it in the Oxygen Preferences->DITA page: https://github.com/oxygenxml/dita-ot-3x-plugin
Because even with separate customization folders you may have problems, you may have one client who wants to use DITA OT 3, another who wants to use DITA OT version 4 because it fixes some processing bug...
Regards,
Radu

[Gertone]

Thanks for the follow up Radu.
Some more things to consider indeed, thanks for that.
Just to make sure there is no misunderstanding. I hope I did not sound as if I was pointing a finger at Oxygen. That was definitely not what I meant to say. I am very well aware on how DITA-OT evolves as an open source project, independently from Oxygen.
I am just trying to decide on the best way ahead, taking into account that I have quite some investment over the years in the various customisations on PDF2. Taking more control by packaging the OT with the customisation is definitely an option. Biting the bullet now and migrating to the CSS alternative, is also an option
Thanks for your time and suggestions

[Radu]

Hi,

I am just trying to decide on the best way ahead, taking into account that I have quite some investment over the years in the various customisations on PDF2.

I understand, ideally all customizations would also have some kind of manual attached or comments in the XSLT code discussing what the customization was for, this would allow you to create a list of the customizations you made and maybe migrate to CSS-based customizations.

Taking more control by packaging the OT with the customisation is definitely an option.

At least there would be no variable factor. But you would remain on an old DITA OT version which is no longer maintained and updated.

Biting the bullet now and migrating to the CSS alternative, is also an option

We invested time to build this CSS-based PDF engine and invest time in maintaining and offering advice for it because we considered that at least CSS-based customizations are easiert to perform, understand and maintain in time.

Regards,
Radu

[chrispitude]

Hi Geert,

We use the CSS-based PDF transformation. It is particularly nice because we are able to share common CSS styling across all of the following:

• Oxygen editor
• PDF outputs
• WebHelp outputs

We have a set of four CSS files:

• our-common.css
• our-editor.css
• our-pdf.css
• our-webhelp.css

where 90% of the CSS styling is in the common file, then the format-specific styles (and some occasional overrides over the common style) are in the other three files. This way, when we modify the common file to change an existing style or add support for a new element or structure, everything changes together.