<i> tags not processed when nested in <section><p> tags

[mharvey]

One of my DITA concepts contains the following text in its <conbody> element:

Code: Select all

...

<section>

   <title>DNS Server</title>

   <p>A DNS (Domain Name System) server allows the use of symbolic names rather than IP addresses

        for network devices. For example, a protocol might refer to a substation device as

          <i>relay6.mycompany.com</i>, instead of using its 10.106.121.34 IP address. When a

        symbolic name is used, the DNS server translates the name to an IP address.</p>

  </section>

...

When I use the PDF2 transform to convert it to PDF, the <i> tag (which surrounds "relay6.mycompany.com") is not processed at all.

Does someone knows which .xsl I need to modify to get it right ?

I use Oxygen 15.0, with version 1.7 of the DITA-OT.

Thanks a lot in advance for your help !

[Radu]

Hi,

Using the DITA OT 1.7 which comes with Oxygen 15.0 and without any customizations, the processing renders the host name in your example with italic font.
Did you add any customizations to the PDF processing? Because they might be the cause for this.

Regards,
Radu

[mharvey]

I added some customizations. But most of them works just fine.

One of the thing I noticed when using customization is that I sometimes need to add a XSL file from the org.dita.pdf2\xsl path (without even modifying it) to my customization folder for the processing of some tags.

That was the case for the following files (these imports are in the custom.xsl file of my \xsl customization folder):

Code: Select all

<xsl:import href="pr-domain.xsl"/>

<xsl:import href="sw-domain.xsl"/>

<xsl:import href="ui-domain.xsl"/>

Maybe there is one more file that I should move to my customization folder (and list it in the custom.xsl file)...

By the way, I just noticed that the <i> tag is also not processed in the <context><p> tags.

Can it be related to an "bad use" of the <p> tag ?

[Radu]

Hi Mathieu,

The custom.xsl should contain only the template which is overridden.
Just like in the example we gave here:

http://www.oxygenxml.com/doc/ug-oxygen/ ... ation.html

Why exactly did you consider you needed to add references to the other XSLs? Even if validation of the custom.xsl complains that certain called templates do not exist, the main XSL stylesheet which gets published will import all necessary XSL files.

Can it be related to an "bad use" of the <p> tag ?

No, your customization probably broke this. If you can send it to us (support@oxygenxml.com) we can take a look at it. As an example the last time I saw something similar was when somebody added an XSLT template like:

Code: Select all

    <xsl:template match="*[contains(@class, '  topic/ph  ')]">

        <xsl:choose>

            <xsl:when test="@outputclass='customClass'">

                ...

            </xsl:when>

            <xsl:otherwise>

                <xsl:value-of select="."/>

            </xsl:otherwise>

        </xsl:choose>

    </xsl:template>

A match like this "*[contains(@class, ' topic/ph ')]" matches also bold and italic tags because for example the @class attribute of the <i> tag is + topic/ph hi-d/i , this means that the default processing template for italic is inhibited.

Regards,
Radu

[mharvey]

I just sent you my customization files at the specified email.

Thanks for your help !

[Radu]

Hi Mathieu,

Thanks for the samples, I think I found the problem.

Let me try to give you some more details about how matching the italic element works in the default XSLT stylesheets first.
As I said in my previous post the italic tag <i> has the @class attribute + topic/ph hi-d/i .

In this XSLT file:

OXYGEN_INSTALL_DIR\frameworks/dita/DITA-OT/plugins/org.dita.pdf2/xsl/fo/hi-domain.xsl

there is a template:

Code: Select all

    <xsl:template match="*[contains(@class,' hi-d/i ')]">

      <fo:inline xsl:use-attribute-sets="i">

        <xsl:call-template name="commonattributes"/>

        <xsl:apply-templates/>

      </fo:inline>

    </xsl:template>

which matches italic elements and applies a certain styles to them.

But in this XSLT file:

OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/org.dita.pdf2/xsl/fo/commons.xsl

there is another template:

Code: Select all

    <xsl:template match="*[contains(@class,' topic/ph ')]">

        <fo:inline xsl:use-attribute-sets="ph">

            <xsl:call-template name="commonattributes"/>

            <xsl:apply-templates/>

        </fo:inline>

    </xsl:template>

which can also possible match the italic element because it has the @class + topic/ph hi-d/i .

Both these XSLT stylesheets are imported in:

OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/org.dita.pdf2/xsl/fo/topic2fo.xsl

in this order:

Code: Select all

.....

<xsl:import href="commons.xsl"/>

.....

<xsl:import href="hi-domain.xsl"/>

When the XSLT processor will try to match an element (like the italic element for example), it will prefer the template in the last imported XSL.
In this way, it will match the template in "hi-domain.xsl", adding styling to it.

But your "custom.xsl" gets imported in this XSLT stylesheet:

OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT/plugins/org.dita.pdf2/xsl/fo/topic2fo_shell.xsl

in this order:

Code: Select all

...

 <xsl:import href="topic2fo.xsl"></xsl:import>

...

 <xsl:import href="cfg:fo/attrs/custom.xsl"></xsl:import>

 <xsl:import href="cfg:fo/xsl/custom.xsl"></xsl:import>

So because your "custom.xsl" is the last import, it will take top precedence.

But what you did in your "custom.xsl" was to import again a copy of "commons.xsl" and thus the template which matches *[contains(@class,' topic/ph ')] became more powerful and started matching bold and italic elements.
So whenever you make a customization (like your modified version of "commons.xsl"), please try to only overwrite certain templates, do not make an entire copy of an XSLT stylesheet's contents in your customization.
So you should go through all XSLs imported from the custom.xsl and remove/comment in them the templates which have no changes relative to the base implementation.

More about the way in which multiple templates which match a certain nodes are prioritized can be found here:

http://www.w3.org/TR/xslt#conflict

Regards,
Radu

[mharvey]

Hello Radu,

First of all, thanks for your quick response and help !

I'll clean up my customization files and I will keep you informed it works or not !

Regards,

Mathieu Harvey

[mharvey]

Just cleaned up my customization files, and it works !

And I understand the customization process much better now. Thanks again !

[maglid]

So I assume this also applies to customized attribute files? For example in \plugins\myplugin\cfg\fo\attrs\custom.xsl I have this order:

Code: Select all

  <xsl:include href="task-elements-attr.xsl"/>

  <xsl:include href="commons-attr.xsl"/>

  <xsl:include href="toc-attr.xsl"/>

  <xsl:include href="static-content-attr.xsl"/>

etc.

Should I move commons-attr.xsl to the top?

Thanks

[Radu]

Hi,

I do not have enough information about your customization to decide.
In my opinion most people have all the overwritten templates placed directly in the custom.xsl without additional includes to other XSLs from the customization plugin.

Regards,
Radu