EXM-18109 patch interferes with fig.title attribute-set in DITA OT 3.3.1

[ckabstein]

Hi,

I guess that the above mentioned patch is there for a good reason, but somehow it interferes with our custom fig.title attribute set, i. e. it adds a text-align="center" to the fig.title attribute settings, which is unwanted behavior.

The code is in the custom.xsl file of the com.oxygenxml.pdf.custom plugin:

Code: Select all

<!-- OXYGEN PATCH START  EXM-18109 -->
          <xsl:if test="following-sibling::*[contains(@class,' topic/image ')][@placement='break']">
              <xsl:attribute name="text-align" 
                  select="if (empty(following-sibling::*[contains(@class,' topic/image ')]/@align)) then 'center' 
                              else following-sibling::*[contains(@class,' topic/image ')]/@align"/>
          </xsl:if>
          <!-- OXYGEN PATCH END  EXM-18109 -->

Maybe you could tell me for which purpose this patch is needed.

When I comment out these lines, the fig title is correctly aligned to the left.
I cannot override this via our attribute-set as usual within the DITA OT setting. I guess I will have to override the com.oxygenxml.pdf.custom plugin, correct?

Thanks,
Christina

[ckabstein]

The question is: CAN I override that plugin without an existing extension point? Haven't done that yet.

[Radu]

Hi Christina,

Sorry for the delay, I added an internal issue to look into removing that fix which tries to center all images inside figures (we probably considered that it looks nicer). Thing is we are no longer very interested in the classic PDF output as we shifted our focus to the PDF publishing using CSS approach so maybe we can remove that plugin completely from the DITA OT (although it does have some useful customization for note images).
On your side you could either try to remove the plugin completely and run again the integrator or indeed somehow try to override it.
Our plugin contributes its custom.xsl with the extension point dita.xsl.xslfo. I think that if you create another plugin folder name which alphabetically comes after ours in the plugins folder and you override the same extension point, your XSLT would be imported last in the list of imported XSLT extensions so it should have higher priority. Or you can add a @priority attribute on your xsl:template to make it more important.

Regards,
Radu

[ckabstein]

Hi Radu,

Thanks for your answer. I have made an xsl:import for that template and overrode it using our own custom.xsl. That was the quickest solution I could find.

Would it make more sense to do it the way you proposed?

Other than that I wouldn't recommend removing your plugin completely. I really really appreciate all the useful fixes that you make to support the users. As you wrote, there are some useful customizations for note images which other users might use. So if you removed your plugin, they would have to make sure that they integrate those changes into their plugins.

I must admit, I have got used to making all my PDF changes with XSL that I cannot think of moving to the CSS approach right now. And we don't have time for this at the moment, so even if we wanted to change, we would have to replan.
I understand that the classic PDF output is no longer interesting, but I have realized in the past few months that CSS in general is not the solution for everything and in some cases, the XSL approach works much better for us. Layout-wise, I would agree with CSS, but for some functionality, for example, for multiple language outputs, there's no way around XSL - as far as my experience goes. So I would appreciate if you don't lose sight of the classic approach completely.

All the best,
Christina

[Radu]

Hi Christina,

I'm glad you found a solution for overriding our template.
About removing the plugin, we'll take a decision about this after the Oxygen 22.1 release (which we plan to release in about a month).
And even if we decide to remove it, you can add it back in the DITA-OT or take its contents and merge it with your own PDF customization plugin.
About CSS not being right for multi language outputs, in my opinion it should work quite well because it has selectors which can incorporate the lang() selector to show various static texts depending on the language. If at some point you find the time to convert your DITA Map to PDF using our CSS-based approach and you find problems with how multiple languages are handled we'd be happy to work more on it.

Regards,
Radu