DITA/FM8 topic misbehavior

Report · Jan 22, 2009

I've noticed some funny business with our implementation of DITA that I was hoping someone could shed some light on.

When we work with topic topics, tasks, or concepts, fm-xref elements don't save. When the document is reopened, they are replaced with xref elements, and nonfunctional ones at that. Similarly, image element href attributes do not populate at import in theses topics. The funny part is that in references, fm-xref elements work and save correctly, and image href values are automatically populated. HOWEVER, they populate with windows filepaths (Drive\Parent Dir\Dir\Filename) instead of the web relative urls that I was under the impression DITA used (../Sub Dir/filename).

If anyone can explain any of this, I'd be supergrateful.

Report · Jan 22, 2009

Hi Toby...

Are the cross-ref formats that you're using in your topic topics defined in the template or are you creating the formats on the fly in the DITA file? These formats must exist in the template. In general, you shouldn't see any difference between fm-xref handling based on topic type. If you are seeing differences, I'd be glad to look at your files. Contact me through the URL below (in my sig).

In FM8-DITA, image/@href won't populate until you save and reopen the file.

Unfortunately, FM8-DITA uses backslashes rather than the more appropriate frontslash in @href values. In general this works fine, but it can run into problems in certain cases. in particular if you try to edit an @href value manually, you'll need to either replace the backslashes with frontslashes or use double-backslashes (else FM will turn the backslash-character into a special character. :)

DITA-FMx uses the "correct" @href slashes and has improved image handling.

Cheers!

...scott

Scott Prentice
Leximation, Inc.
www.leximation.com

Report · Jan 22, 2009

Hello,

fm-xref is defined in our EDD; it's a suboptimal element to use but supposedly the more effective conversion from basic FrameMaker crossrefs. It is associated with a number of possible formats defined in our template- in terms of support files, all 4 of the basic topic types are the same. I am also pretty confident that it is not a structure issue, since placing both fm-xref and image elements under reference elements within a document that contains a parent topic or task element still causes the problem.

I'm not sure what could cause a specific change in file handling based on the first (non dita) element in the topic. AFAIK the read-write rules are not at fault here, and ditafm.ini controls only global import/export options so I don't think it's to blame either.

Report · Jan 22, 2009

Yes .. if you want live links in a PDF generated from FM8-DITA you need to use fm-xrefs (DITA-FMx provides a command to convert regular xrefs into hyperlinks).

Ah .. you've got nested topics? I do believe that FM8-DITA has a problem with links to topics in files where the target topic is not the top-level topic (sorry to keep repeating this, but DITA-FMx fixes this bug as well). Is it possible that it's the links to non-top-level topics that are messed up?

Also .. it sounds like you're using a customized structure application? You should test with the default apps to see if the same error happens .. if it does, then it's a general problem, otherwise it's a problem with your customized app.

...scott