Reply To: Unable to create PDF file due to foreign element

[Fa]

Hi Derek (and anyone else interested)!

Following up on this topic (sorry about the long delay!).

After discussion with my colleagues why they had ended up creating their own elements, it turned out that the main (and probably only) reason why they did that is that the program they develop uses context sensitivity.

The help file they create is a simple “single html file”.

Since they are writing their code for the different modules before the corresponding help topics even exist, they already create a context sensitive link within the software pointing to an element that does not yet exist (in a file that does not yet exist either).

At first, they tried to use the topic id attribute value as a unique identifier, but it failed because of the way the conversion is done. When DITA-OT processes the xml topics, it collects all the links and targets (in this case the topic id's), and it renames all targets in the html to “#unique_01”, “#unique_02”, etc.

I guess the reason behind the behaviour is that since it creates a single html out of lots of small DITA files, it wants to make sure there are no duplicate anchors, and therefore, instead of having a mechanism that checks for duplicate, it just coldly replaces all names for anchors created from elements with new names that it knows are unique.

The drawback in this case is that there is therefore no way of knowing what to link to before the html has been built, and even then it would require a lot of manual work. That's how they came up with the idea of creating the help_anchor elements that they then process to become an html anchor ().

So my question now is: is there
a) a way to force XMetaL (DITA-OT) to keep the elements' IDs intact and transfer them to the href attribute value for anchors () in the html instead of replacing them by the #unique_nn value
or
b) an existing, valid DITA element that could be use for this purpose?

Thank you!

Reply