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?
Tigdave, Mar 12, 2009 9:27 AM
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,<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...
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.