How to treat @chunk=”to-content” in merged middle file for PDF output?

Toshihiko Makita

unread,

Sep 3, 2015, 11:28:59 AM9/3/15

to DITA-OT Users

Hi All,

I have following map file that is referenced from bookmap.

[engine_spec.ditamap]

<map>
<title>Specification Map</title>
<topicref href="topics/c_spec_title.dita" format="dita" chunk="select-branch to-content">
<topicref href="topics/r_spec1.dita" format="dita"/>
<topicref href="topics/r_spec2.dita" format="dita">
<topicref href="topics/c_spec3.dita" format="dita"/>
</topicref>
</topicref>
</map>

[bookmap]

This map structure is expanded in DITA-OT “TopicMerge” as following:

If the plug-in traces map structure without considering @chunk attribute, the references (“unique_2”,”unique_3”) and concept (“unique_4”) will be rendered twice in the result PDF. It is not a desired result.

To avoid this, I think it is needed to skip topicref children when topicref/@chunk contains “to-content”. Is it a correct decision?

DITA chunking is very complex to me and I have no test data until now. So I want your advice.

For your reference I don’t use [DITA-OT]/plugins/org.dita.pdf2/xsl/common/topicmerge.xsl for merged middle file processing.

Regards,

Toshihiko Makita

Kendall Shaw

unread,

Sep 5, 2015, 9:11:05 PM9/5/15

to DITA-OT Users

Hi,

I am also unsure about all of the combinations of chunk values.

If I understand the question that you are asking, then at least in the case here, a program written to process the output of topicmerge without using topicmerge.xsl from the pdf2 plugin would need to avoid following the topicrefs in document order, because of the duplicate references, as you point out.

I think an alternative, to capture the hierarchy and chunking, would be to start with the topics, in document order and if needed look back at the corresponding topicrefs that link to each topic.

If I didn't understand the question, I am sorry.

Kendall

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Toshihiko Makita

unread,

Sep 6, 2015, 6:01:34 AM9/6/15

to DITA-OT Users

Hi Kendall,

Thank you for your reply.

>If I understand the question that you are asking, then at least in the case here, a program written to process the output of topicmerge without using topicmerge.xsl from the pdf2 plugin would need to avoid following the topicrefs in document order, because of the duplicate references, as you point out.

Surely it is!

> I think an alternative, to capture the hierarchy and chunking, would be to start with the topics, in document order and if needed look back at the corresponding topicrefs that link to each topic.

I am adopting the bit different approach.

My intention is to use the "TopicMerge" output as far as it is. I know that PDF2's topicmerge.xsl changes the middle file format dramatically and everyone use it without no doubt.

But I think it is not a good situation for DITA-OT plug-in developers because it is not the only one solution. It has many defects.

Anyway I have solved this problem by adding the following code.

<xsl:template match="*[contains(@class,' map/topicref ')][ahf:HasAttr(@chunk,'to-content')]" priority="2">

<xsl:choose>

<xsl:when test="@print='no'" >

<xsl:for-each select="descendant-or-self::*[contains(@class,' map/topicref ')]">

<xsl:if test="exists(@href)">

<xsl:message select="'[convmerged 1001I] Removing topicref. href=',string(@href),' ohref=',string(@ohref)"/>

</xsl:if>

</xsl:for-each>

</xsl:when>

<xsl:otherwise>

<xsl:copy>

<xsl:copy-of select="@*"/>

<xsl:apply-templates select="* except *[contains(@class,' map/topicref ')]"/>

</xsl:copy>

</xsl:otherwise>

</xsl:choose>

</xsl:template>

<!--

function: Check $prmAttr has $prmValue

param: prmAttr, prmValue

return: xs:boolean

note: Return true() if $prmAttr attribute has $prmValue

-->

<xsl:function name="ahf:HasAttr" as="xs:boolean">

<xsl:param name="prmAttr" as="attribute()?"/>

<xsl:param name="prmValue" as="xs:string"/>

<xsl:choose>

<xsl:when test="empty($prmAttr)">

<xsl:sequence select="false()"/>

</xsl:when>

<xsl:otherwise>

<xsl:variable name="attr" as="xs:string" select="string($prmAttr)"/>

<xsl:variable name="attVals" as="xs:string*" select="tokenize($attr,'[\s]+')"/>

<xsl:sequence select="$prmValue = $attVals"/>

</xsl:otherwise>

</xsl:choose>

</xsl:function>

Regards,

2015年9月6日日曜日 10時11分05秒 UTC+9 Kendall Shaw:

Kendall Shaw

unread,

Sep 7, 2015, 6:05:35 PM9/7/15

to DITA-OT Users

Hi,

One of the cases in the DITA specs might not work, if it were something to consider.

In example 4 in the spec,that looks like:

<map>
  <topicref href="ditabase.dita#Y" copy-to="Y.dita"
            chunk="to-content select-topic">
    <topicref href="ditabase.dita#Y1" copy-to="Y1.dita"
              chunk="to-content select-branch"/>
    <topicref href="ditabase.dita#Y2" copy-to="Y2.dita"
              chunk="to-content select-topic"/>
  </topicref>
</map>

Y.dita is supposed to exclude the topics referenced from the child topicrefs. And, at least with the current development branch, if I process that map, the dita-merge file reflects that. If you follow #unique_1 it references a topic with no child topics.

So, I suppose you would want to account for the copy-to attribute also.

Kendall

Toshihiko Makita

unread,

Sep 8, 2015, 3:52:04 AM9/8/15

to DITA-OT Users

Hi Kendall,

> So, I suppose you would want to account for the copy-to attribute also.

Thank you for your information.

I will investigate the merged middle file later.

Regards,

2015年9月8日火曜日 7時05分35秒 UTC+9 Kendall Shaw:

Kendall Shaw

unread,

Sep 8, 2015, 4:15:31 PM9/8/15

to DITA-OT Users

Hi,

I should have said that it was the result I observed from topic-merge, without the use of topicmerge.xsl from the pdf2 plugin.