Skip navigation
(Gilda_Spitz) Calculating status...
Currently Being Moderated

Cross-references from one Frame book to another

Feb 17, 2009 12:43 PM

I have a client who has two FrameMaker 8 books. The books were a mess (left over from a previous contractor - it was a nightmare) and they hired me to fix them.

But one thing that did work in the old books was their cross-ref setup - they need cross-refs from each book to the other one. The client knew that they had to have the Frame and pdf files in a stable folder structure that did not change. Then, when they created their two pdfs, the cross-refs "found each other" properly.

I fixed everything in the Frame docs EXCEPT those book-to-book cross-refs. I told my client that they would have to create those on their own, because I couldn't duplicate their folder structure - and they were fine with that. But I DID create all cross-refs that were within each individual book (hundreds of them - very technical books).

But now they are getting hundreds of unresolved cross-refs when they open the files in each book. I thought they must have moved some files out of the folders that I gave them in their zip files, but they swear they haven't done so.

For the life of me, I can't think of any other reason why they're having trouble with the cross-refs. Any ideas?

Gilda Spitz
302 Views   4 Replies   Latest reply: Tigdave, Mar 12, 2009 9:27 AM
 
Replies
  • Sheila Carlisle
    Currently Being Moderated
    1. Sheila Carlisle,
    Feb 26, 2009 9:59 AM   in reply to (Gilda_Spitz)
    Report
    Gilda, it looks like your message slipped through the cracks (the forums are undergoing some changes which has made it tricky to log in consistently, you may have already noticed it).

    First off, can you double-check which specific versions of FM both you and the client are using, the "pxxx" numbers from Help > About, so that we know you're both in sync.

    And finally, are you still having the cross-ref problem? If it's resolved, it would be useful to know what the solution was (if you're not too annoyed at us for the slow response!)

    Sheila
     
    |
    Mark as:
  • Currently Being Moderated
    2. (Gilda_Spitz),
    Feb 26, 2009 11:34 AM   in reply to (Gilda_Spitz)
    Report
    Thanks, Sheila. Yes I was starting to wonder why I wasn't getting any replies.

    I'm using version 8, p277. My client is also using version 8, but I don't know the p number.

    Yes, we're still having the cross-ref problem, but we're closing in on the issue. We've planned a conference call tomorrow in which I hope it will be resolved.

    The problem with the internal cross-refs has been solved, but now there's another one with the book-to-book cross-refs.

    The problem is that in 15 years of working with Frame, I've often worked with cross-refs within a book file, but never cross-refs from book to book, and the complications that arise when you create pdfs for those books. I recently received some tips and tricks from Arnis Gubins about folder structures, and I'm sure we're on the right track. We'll find out for sure tomorrow on the conference call.

    Gilda
     
    |
    Mark as:
  • Arnis Gubins
    Currently Being Moderated
    3. Arnis Gubins,
    Feb 26, 2009 3:18 PM   in reply to (Gilda_Spitz)
    Report
    Gilda,<br /><br />Here are some simple rules for creating book-to-book links in PDFs<br />from FM:<br /><br />1. If you're creating the PDFs of the books as a single PDF, then you<br />must have the respective ".book" files open (no need for the .fm files<br />to be open), when creating the PDFs. Otherwise, the "external" links<br />will be made to the specific pdf equivalent of the ".fm" file, if the<br />".book" file is not open.<br /><br />2. The links between the books on the same disk drive, will be as<br />relative links, which need to preserved if the files are moved.<br /><br />3. If the goal is to have all of the book PDFs in one place for<br />distribution, then it's best to place all of the .book files in the<br />same folder to begin with. The .fm files can be in their own<br />respective project folders, but you have to keep the books together.<br /><br />Caution: simply moving/copying (or doing a Save As from within FM) the<br />.book files to the common folder will not work, as they will be<br />missing the (relative) path to the actual .fm files. You'll need to<br />either recreate the book files (be careful with TOC, IX and other<br />generated files - you have to recreate, not add, these to book) in the<br />target folder or do some spelunking in a .mif version of the .book to<br />adjust the path on the "<FileName" entry of each book component. <br />[This sounds like a job for Framescript... ;-) ]<br /><br />4. If the names of the .book files are not the names that you want to<br />have on the final PDF files, then change the .book filenames to what<br />you want before creating the PDFs. When the .book files are open for<br />creating PDFs, FM will use the .book filename for the target in<br />cross-book links. Let FM always handle the naming, otherwise you run a<br />very good chance of breaking cross-book links.<br /><br />5. If you are producing the PDFs as individual files of the component<br />.fm files in the book, then things are a bit trickier. You have to do<br />each component file, one at a time and have the target .book file open<br />when going down this route. It won't work as you expect when trying to<br />print using the "*" directive for the multiple files at once. IIRC,<br />there was a plug-in from Mekon quite a while ago that fixed this<br />situation for FM5 and 6. I don't know if it's needed now, as I tend to<br />avoid the SaveAs PDF route in the newer versions, so I haven't tested<br />this issue with FM8 or FM9.<br /><br />I hope this helps clarify some things. And the grand master of all<br />things FM to PDF (Shlomo Perets) may be all over this if I've got<br />something wrong or have outdated advice. In that case, never mind...
     
    |
    Mark as:
  • Tigdave
    Currently Being Moderated
    4. Tigdave,
    Mar 12, 2009 9:27 AM   in reply to (Gilda_Spitz)
    Report
    Here's what I use.
    I use one directory per manual, with each directory at the same level.
    Each book file (one book file per manual) is in its own directory, with its component files. Every book file has the same name (man.book) to make it easier to apply styles - most manuals use the same stylesheet, and the books are differentiated at the system level by the directory names.
    All resultant PDF files also have the same name - man.pdf - one PDF file per manual - one PDF file per directory - and are differentiated at the system level by the directory name (again). All links between my manuals therefore have the same relative structure - go up one level, look for the directory name, then look for the file in that directory. This approach has always worked well on my collection of 30 manuals. It also makes it easy to add third-party PDF manuals to the collection - just add another directory with the PDF file in it and set up a link.

    There's one other thing which I always mention because in my experience it is usually the culprit whenever documents go offsite and come back with broken links - NEVER use Save As to move a file. And tell your offsite authors to never use Save as.
    And then make a big sign to this effect and beat them over the head with it.
    The Save As facility will stretch any references (xrefs, graphics), so that they still work from their new non-standard document location. The author who stretched the links won't see any sign that they've done anything wrong because the document will still "look" okay, even though the links now won't work when the document gets back into its old standard location.
    It gets worse. Much worse. If you save as to a different disk (or otherwise stretch a link through the root directory) then voila - all pathnames in the links are automatically converted from relative to absolute, and you've just destroyed all document portability between systems.
     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)