Page 1 of 1

PDF output: <indexterm> in sections causes empty row

Posted: Fri Jul 27, 2018 4:22 pm
by Anonymous1
Hello,

until now we used indexterm elements in the prolog only. Now we want to allow our authors to also use it in sections. According to the DITA specs this is fine.

We've only got one issue in our PDF output. When we insert an indexterm element in a section element, an empty row is created. Everything else works.

A visualization

Section without indexterm:
Section Title
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Section with indexterm:
Section Title

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
Do you have an idea why this could be?

We are using Oxygen 19, build 2017042020 with a custom framework.

Thanks,
Benjamin

Re: PDF output: <indexterm> in sections causes empty row

Posted: Mon Jul 30, 2018 12:38 pm
by ionela
Hi Benjamin,

You are using the DITA Map PDF transformation scenario, right?
I have tested in a default installation of oXygen XML v19.1 with the built-in DITA-OT 2.x on our sample project flowers.ditamap and I could not reproduce this issue. I have added in a topic two sections one with indexterm and another one without indexterm and both sections are rendered correctly in the PDF output, without an empty row (by running the built-it DITA Map PDF transformation scenario).
The problem you've indicated might be triggered by the customizations you are using.
To further investigate this issue, could you please try in a clean installation of oXygen XML with the buil-it DITA-OT and the default transformation scenario to check if you reproduce the problem.

Regards,
Ionela

Re: PDF output: <indexterm> in sections causes empty row

Posted: Thu Aug 02, 2018 5:25 pm
by ckabstein
Hi Ionela,

Benjamin asked me to check.
Unfortunately, we cannot reproduce a clean installation of Oxygen XML, at least I wouldn't know how, but I've managed to set the original framework using the built-in DITA OT.
We don't use VMs on which we could use a clean installation for these purposes.

I've used Oxygen XML 20 and compared our customized framework with the default framework output. They show exactly the same result.

If I'm not wrong, I think the most interesting part is to be found in the topic.fo files. These are the results from our framework:

Index-key placement after <title> element:

Code: Select all

<fo:block font-family="Noto Sans, Arial Unicode MS" axf:line-break="strict"
border-after-style="solid" border-after-width="0pt"
border-after-color="black" space-before="17pt" space-after="8pt"
font-size="16pt" font-weight="bold" padding-top="0pt"
keep-with-next.within-column="always">
<fo:block border-left-width="0pt" border-right-width="0pt">
<fo:marker marker-class-name="current-h2">Summer Flowers</fo:marker>
<fo:inline id="unique_18"/>
<fo:inline id="_OPENTOPIC_TOC_PROCESSING_d105e852"/>
<fo:inline index-key="flowers:summer2:"/>
Summer Flowers
</fo:block>
</fo:block>
Index-key placement after section <title> element:

Code: Select all

<fo:block font-size="9pt" line-height="1.3em" space-before="0.6em">
<fo:block font-family="Noto Sans, Arial Unicode MS"
axf:line-break="strict" font-weight="bold" space-before="11pt"
keep-with-next.within-column="always" font-size="11pt"
start-indent="0pt + from-parent(start-indent)" space-after="8pt">test section</fo:block>
<fo:inline index-key="flowers:summer:"/>
<fo:block space-before="7pt" space-after="7pt"
color="rgb-icc(0, 0, 0, #CMYK, 0, 0, 0, 1)" text-indent="0em"
line-height="1.3em">some text for the test section
</fo:block>
</fo:block>
Default framework, index-key after title:

Code: Select all

<fo:block border-after-color="black" border-after-style="solid"
border-after-width="1pt" font-size="14pt" font-weight="bold"
keep-with-next.within-column="always" padding-top="12pt"
space-after="5pt" space-before="12pt"
line-height-shift-adjustment="disregard-shifts"
font-family="Helvetica, Arial Unicode MS, Tahoma, Batang, SimSun">
<fo:block border-end-width="0pt" border-start-width="0pt">
<fo:marker marker-class-name="current-h2">Summer Flowers</fo:marker>
<fo:wrapper id="unique_18"/>
<fo:wrapper id="_OPENTOPIC_TOC_PROCESSING_d98e852"/>
<fo:inline index-key="flowers:"/>
<fo:inline index-key="flowers:summer2:"/>
Summer Flowers
</fo:block>
</fo:block>
Default framework, index-key after section title:

Code: Select all

<fo:block space-before="0.6em">
<fo:block font-weight="bold"
keep-with-next.within-column="always" space-before="15pt"
line-height-shift-adjustment="disregard-shifts"
font-family="Helvetica, Arial Unicode MS, Tahoma, Batang, SimSun">test section</fo:block>
<fo:inline index-key="flowers:"/>
<fo:inline index-key="flowers:summer:"/>
<fo:block space-after="0.6em" space-before="0.6em"
text-indent="0em">some text for the test section</fo:block>
</fo:block>
In either case, the index-key after the section title is not part of the fo:block element of the title, whereas the index-key after a typical title element is embedded in the fo:block element of the title.
Could this be the issue?

Thanks,
Christina

Re: PDF output: <indexterm> in sections causes empty row

Posted: Tue Aug 07, 2018 2:00 pm
by Radu
Hi Christina,

It would have helped if you had posted some sample DITA content to show exactly where you insert the indexterm.
I can reproduce the problem on my side with some DITA content which looks like this:

Code: Select all

<section id="section_jqn_pnt_s2b"><title>My
section</title><indexterm>abcdef</indexterm><p>My content</p></section>
It's a bug in the Apache FOP processor:
https://github.com/dita-ot/dita-ot/issues/2455

so probably using the AntennaHouse commercial PDF processor should remove it.

Regards,
Radu

Re: PDF output: <indexterm> in sections causes empty row

Posted: Tue Aug 07, 2018 3:56 pm
by ckabstein
Hi Radu,

Sorry for not providing a proper example, but I thought it was clear from what Benjamin wrote. Our example looks exactly like yours:

Code: Select all

<section><title>test section</title><indexterm>flowers
<indexterm>summer</indexterm></indexterm><p>some text for the test section</p></section>
We have already changed to Antenna House. Even with Antenna House this problem persists. So it looks as if this is not only an FOP issue.

Thanks,
Christina

Re: PDF output: <indexterm> in sections causes empty row

Posted: Wed Aug 08, 2018 8:36 am
by Radu
Hi Christina,

My Antenna House installation is acting up this morning so I cannot test with it.
But I did test the classic PDF output without any customizations using the RenderX XEP processor and it does not add that extra spacing between the title and paragraph.

Regards,
Radu

Re: PDF output: <indexterm> in sections causes empty row

Posted: Wed Aug 08, 2018 11:49 am
by ckabstein
Hi Radu,

I've just found that in the index.xsl file (org.dita.pdf2), the following template seems to influence this:

Code: Select all

<xsl:template match="opentopic-index:index.entry">
<xsl:for-each select="opentopic-index:refID[last()]">
<fo:inline index-key="{@value}"/>
</xsl:for-each>
<xsl:apply-templates/>
</xsl:template>
Our customized template looks like this:

Code: Select all

<xsl:template match="opentopic-index:index.entry">
<xsl:for-each select="opentopic-index:refID[not(following-sibling::opentopic-index:index.entry)][last()]">
<fo:inline index-key="{@value}"/>
</xsl:for-each>
<xsl:apply-templates/>
</xsl:template>
In our customized template, I've changed the <fo:inline> element to <fo:wrapper> - and that WORKS! I don't know why, but it works. :wink:
Please tell me that it's OK to do this. It seems that our PDF output hasn't changed in any other way, apart from the fact that the empty spaces between section titles and text have disappeared.

Regards,
Christina

Re: PDF output: <indexterm> in sections causes empty row

Posted: Thu Aug 09, 2018 3:00 pm
by Radu
Hi Christina,

I agree, you should use fo:wrapper instead, I added also an issue on the DITA OT issues list:

https://github.com/dita-ot/dita-ot/issues/3042

Regards,
Radu