Creating Unique IDs for elements (non-DITA)...

[Gorly]

Hi,

I know there's a solution to this somehow via scripting - problem is, I have no clue so far about FM scripting

We're using the standard XML API for our structure and everything works out fine, except one thing that we stumbled over.

When creating a TOC in FM11 based on XML files within a book, we're receiving good results (pages are referenced correctly). As long as it doesn't come down to jump marks.

FM11 doesn't create the correct jump marks for the TOC entries. After an analysis, this is because the unique IDs for the referenced elements are non-existant (they're required and declared as UniqueID in the DTD and EDD, but not set automatically). Therefor FM11 points his jump marks towards the nearest element with an unique ID.

This behavior points me to two questions:

1. can I get FM11 to create unique IDs upon creation of the TOC (same way it creates the IDs when using XRef)? or

2. what can I do to get FM11 to create unique IDs automatically on insertion of an element, that requires an ID?

Cheers Gorly

[Russ Ward]

Hi Gorly,

My XRef Wizard plugin can set unique IDs automatically when you insert elements and/or save documents. I use it for this purpose all the time:

http://www.weststreetconsulting.com/WSC_XRefWizard.htm

But I don't come here to sell plugins, so perhaps there is another solution. I find that I don't completely understand your architecture. What kind of TOC are you generating? It sounds like it is a structured TOC. I'm not clear on why the referenced element would need a unique ID.

Russ

[Gorly]

Hi Russ,

we're using some custom structure similar to DITA (we came from there).

At the moment we're using simple old FM style book files with an unstructured TOC (so far nothing has changed to our old book layout).

Within the book we're including XML files from which we create the TOC.

So far so good.

The issue is, that when the TOC is created and you try to jump to a TOC entry (in FM or PDF), you land somewhere else.

I analyzed the problem and found out, that this is only true for elements that have no unique ID (as they are not referenced by xref and we didn't care to insert a ID manually).

For elements with an ID everything works like a charm.

To increase the confusion: the page references in the TOC are correct. Only the jump marks that are created in the background point to some other element, that actually has an unique ID.

[Russ Ward]

Hi Gorly,

This sounds like a bug, but I wouldn't know for sure without analyzing the files. A TOC uses a hypertext marker to create a link, which references an internal unique ID of the target. They don't reference the XML markup. So I'm not sure why you would have this problem. In any case, if you need unique IDs to be set automatically, you'll need to get a plugin or write some code yourself.

Russ

[Gorly]

Anybody else got any bright ideas how to solve the issue?

[ScottPrentice]

Hi Gorly...

Am I understanding correctly that the book contains XML files? I know this is now (as of FM10?) possible, but personally I wouldn't do it. I'm not surprised that this is one of the problems that you may run into. I may be off-base here, but this just doesn't seem like a good idea.

One possible solution is to make sure that all of the XML files are open when you generate the TOC .. then leave them open when generating the PDF. When FM generates a TOC, it'll add in the necessary markers or use existing unique IDs as targets, but when you save and close the XML file, that data is likely lost (or changed when the file is reopened). Leaving the files open through the entire process may just solve your problem.

If that doesn't work, I would just save the XML files to FM binary files and create a book with those files. Then the TOC you generate should work properly as a PDF. It should be fairly easy to create an ExtendScript that would create this "FM binary" book from your "XML" book when you want ot generate a PDF. Just treat this FM binary book as a disposable artifact that you create each time you want to create PDFs. Here's some slides and sample files from an ExtendScript workshop I gave a couple years ago, which may be helpful ..

     http://leximation.com/downloads/tcworld-2011/

If none of this works, you will likely need to create a plugn or script to fix things up. I'd be happy to help with that (as may Russ and other available developers).

Good luck!

...scott

Scott Prentice

Leximation, Inc.

www.leximation.com

[Gorly]

Thanks for the answer Scott,

getting away from the FM binaries for out content was our goal in the first place

That's part of why we moved from FM9 to FM11, discarded our (very badly implemented) DITA specialization towards our own structure (DITA never fitted  our needs anyways) and had lots of headakes otherwise (at least me).

I still would prefer a solution without the binaries - so this means I might need to get involved with ExtendedScript soon enough, but that might take a while.

Be sure I'll get back to you guys then .

For the time being, we will just enter IDs manually for the jump marks upon creation and I'll do some further research on what is going wrong here.

(I just had an idea to use  some RWR to fix the issue...guess I'll report back my findings here)

Cheers Alex

[ScottPrentice]

Hi Alex...

I'm not suggesting that you use FM binaries as the source .. just as an intermediate (disposable) publishing format. This is a common practice for publishing to PDF from XML using FrameMaker. If you don't use FM binaries as an intermediate format, you'll likely have various problems (some you're seeing .. others you may not have seen yet 😉

Yes .. do report back on your progress!

Cheers,

...scott

[Gorly]

After having no time to care about this in the last months, I just recently started to work on the project again.

So far we decided to move away from our old structure completely and are creating some completely new structure tailored to our true needs.

Doing that I, got involved with XSLT in the meanwhile and solved the ID issue temporarily with a XSLT on file open, that fills the ID gaps automatically when you open a XML file (combining the generate-id() function and some XPATH logic).

Sooner or later this will be done by some ExtendScript, but I'm not there yet.

This is the code for generating those IDs (if anybody is interested):

<xsl:template match="{element_name_with_needed_id_goes_here}">

<xsl:copy>

<xsl:if test="not(@id)">

<xsl:attribute name="id" select="concat('id',count(descendant::node()),count(descendant::{para_element_name_goes_here}),generate-id(.))"/>

</xsl:if>

  <xsl:apply-templates select="node() | @*"/>

  </xsl:copy>

</xsl:template>

Pretty simple, but does the job (yes, maybe not perfect, but at least better than doing it manually).

The XPATH stuff is only there, because I don't fully trust the generate-id function to always create some unique identifier

So far I'm pretty impressed how good a tool FM became in regards of being an XML editor, XSLT processor (yes, saxon is doing the work) and general flexibility.

This makes moving from one structure to some other quite comfortable.

I'll be adding more info as I'm progressing through the process

-Alex