🚀 go-pugleaf

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

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

Gilda,

Here are some simple rules for creating book-to-book links in PDFs
from FM:

1. If you're creating the PDFs of the books as a single PDF, then you
must have the respective ".book" files open (no need for the .fm files
to be open), when creating the PDFs. Otherwise, the "external" links
will be made to the specific pdf equivalent of the ".fm" file, if the
".book" file is not open.

2. The links between the books on the same disk drive, will be as
relative links, which need to preserved if the files are moved.

3. If the goal is to have all of the book PDFs in one place for
distribution, then it's best to place all of the .book files in the
same folder to begin with. The .fm files can be in their own
respective project folders, but you have to keep the books together.

Caution: simply moving/copying (or doing a Save As from within FM) the
.book files to the common folder will not work, as they will be
missing the (relative) path to the actual .fm files. You'll need to
either recreate the book files (be careful with TOC, IX and other
generated files - you have to recreate, not add, these to book) in the
target folder or do some spelunking in a .mif version of the .book to
adjust the path on the "<FileName" entry of each book component. 
[This sounds like a job for Framescript... ;-) ]

4. If the names of the .book files are not the names that you want to
have on the final PDF files, then change the .book filenames to what
you want before creating the PDFs. When the .book files are open for
creating PDFs, FM will use the .book filename for the target in
cross-book links. Let FM always handle the naming, otherwise you run a
very good chance of breaking cross-book links.

5. If you are producing the PDFs as individual files of the component
.fm files in the book, then things are a bit trickier. You have to do
each component file, one at a time and have the target .book file open
when going down this route. It won't work as you expect when trying to
print using the "*" directive for the multiple files at once. IIRC,
there was a plug-in from Mekon quite a while ago that fixed this
situation for FM5 and 6. I don't know if it's needed now, as I tend to
avoid the SaveAs PDF route in the newer versions, so I haven't tested
this issue with FM8 or FM9.

I hope this helps clarify some things. And the grand master of all
things FM to PDF (Shlomo Perets) may be all over this if I've got
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.