Duplicated topics with Reltable Not Outputting Correctly in Webhelp

[dgallo]

I have a ditamap that contains 4 topics (1 parent and 3 children), that are chunked into one topic. I have added a relationship table in the ditamap to create anchor links for the chunked child topics to the parent topics.

Code: Select all

<reltable title="Anchor Links">

  <relheader>

   <relcolspec>

    <title>Main Topic</title>

   </relcolspec>

   <relcolspec linking="targetonly">

    <title>Anchor Links</title>

   </relcolspec>

  </relheader>

  <relrow>

   <relcell>

    <topicref href="topics/pre_processing/geometry/collector_mirror_r.dita"/>

   </relcell>

   <relcell>

    <topicref href="topics/user_interface/tool_mirror_c.dita"/>

    <topicref href="topics/pre_processing/geometry/part_mirror_t.dita"/>

    <topicref href="topics/preferences/keyboard_shortcuts_mouse_controls_tool_mirror_r.dita"/>

   </relcell>

  </relrow>

 </reltable>

I have then added this map into two different locations of my main production map.

When I compile my project using Oxygen 17.1 - webhelp, the topics output correctly in the two locations is references, but the anchor links being generated are duplicated twice in the first instance of the chunked parent topic, with double anchor links.

What I would expect to happen is that each reference of the chunked parent topic would have its own set of anchor links from the reltable.

[Radu]

Hi,

This looks like a bug in the DITA Open Toolkit. Oxygen 17.1 comes bundled with both DITA Open Toolkit 1.8 and 2.x bundled. The Oxygen Preferences->DITA is the place where you can select the default DITA Open Toolkit to use.
I tried replicating your scenario and in my case the first occurrence of the chunked topic had no child->parent links at all, while the second occurrence had one child->parent link, so only the second occurrence had the proper links. So this looks like a bug but I'm not sure my samples are perfectly equivalent with yours. Maybe if you have the time to come up with a sample DITA project and send it to us, we could try to look into this further.

As possible workarounds, maybe you could either remove those related links from the children to the parent chunk or add those links manually in the topics without using a reltable. Or in the parent topic you could add conrefs to the subtopics and thus avoid using chunking in the DITA Map.

Regards,
Radu

[dgallo]

I am instead trying to use the copy-to attribute to differentiate between the two use cases of the same topic. So I have done the following:

Topic A: Instance 1

Code: Select all

<topicref href="topics/units_and_measurement/measure_dimentions_bounding_box_t.dita" toc="no"

    copy-to="topics/units_and_measurement/measure_dimentions_bounding_box_ta.dita"

    keys="measure_dimentions_bounding_box_ta"/>

Topic A: Instance 2

Code: Select all

<topicref href="topics/units_and_measurement/measure_dimentions_bounding_box_t.dita" toc="no"

    copy-to="topics/units_and_measurement/measure_dimentions_bounding_box_tb.dita"

    keys="measure_dimentions_bounding_box_tb"/>

Both instances of this topic are child topics of a parent topic that has chunked=to-content, so they are then assembled into one topic. I have anchor links created in a reltable to jump from the different child topics in the chunked parent topic, but like I said in my first post, the duplicated links cause the second link reference to jump you to the first instance of the topic in the webhelp.

I thought by using the copy-to attribute and specifying a key I could get around this link issue by entering the key reference in the reltable, instead of the topic reference. This does not appear to be working. I think because when a topic is chunked, the child topics recieve a unique id that the end of their filenames in the webhelp, therefore my reltable links do not identify this. Can you help?

Thanks,
Danielle

[Radu]

Hi Danielle,

Please try to come up with a small DITA Project exhibiting the problem and send it to us. The DITA Open Toolkit publishing engine has some bugs related to chunking but maybe we could find a workaround once we can analyze an example.

Regards,
Radu