FrameMaker vs InDesign book files

[Rick Quatro]

Hi Steve,

I thought maybe scripting could come to the rescue, since InDesign has a lot
of scripting choices (AppleScript on Mac, VBScript on PC, JavaScript on
both). My thought was to write a script that would loop through the
duplicated book's files and point them to the files in the duplicated
folder. Unfortunately, the fullName property for each book component is
read-only so you can't programmatically change it.

By the way, the paths to each component in a FrameMaker book are actually
stored internally as absolute, but when you open the book, FrameMaker
"resolves" the paths, and treats them as relative, if possible. This is how
paths to imported images and external cross-references are handled as well.
With FrameMaker, these path properties are fully writeable, which means you
can change them with FrameScript or an FDK client.

You can see an example of how this can be beneficial for imported graphics
here:

http://frameautomation.com/2010/02/23/managing-imported-images-solution

A similar thing can be done for FrameMaker books, especially large books
with complex numbering or pagination requirements. Say that you want to
duplicate the book but use it with a set of components with different names.
You want to use the same book because you spent a lot of time getting the
component numbering and pagination for each set up just right. You would
follow this procedure.

1) Duplicate the book and put it in the new folder.
2) Run a script that extracts all of the book paths into a spreadsheet file.
3) Open the spreadsheet file and edit the paths to point to the new
components.
4) Run a companion script to update the book's component paths to those
specified in the spreadsheet.

All of the components will have the properties as originally specified in
the original book, even though they point to different components. The
assumption here is that the new book has the same number of components in
the same positions as the old book. But even if there are slight
differences, changing them by hand after you use the scripts will still be
less work than building and configuring a new book from scratch.

This method can also be used to update a book after you move or rename its
components.

I also have a similar script that allows you to change external
cross-reference paths with an Excel spreadsheet.

Rick Quatro
Carmen Publishing Inc.
585-659-8267
rick at frameexpert.com

*** Frame Automation blog at http://frameautomation.com


Here is an issue that just caught me out, so I'm posting it here in case
it's of use to anyone who uses both apps.

When versioning books in FrameMaker, I duplicate the entire enclosing folder
and then create an alias to the book file in the copied folder. This is a
common operation.

The alias is a red herring here, but when you duplicate a book's enclosing
folder in InDesign, open the book file in the duplicate and from there open
a chapter file in the book, InD opens the *original* chapter file and not
the corresponding chapter file in the duplicated book. This is because InD's
references to files in a book are absolute and not relative: this can be
confirmed by hovering over the chapter name in the book file. This is
potentially very confusing for people who use both applications. The only
way around it in InD that I can see is to delete and recreate the book file
after duplicating the book's enclosing folder.

This has just landed me with a bit of a version control headache that I had
to sort out by hand. There's nothing about book versioning that I can see in
InD's help (CS3), and although Kvern and Blattner ('Real World InDesign 2')
touch on this in relation to individual chapter files, no thought seems to
have been given to versioning entire books. As FrameMaker uses relative file
pathnames, its operation is completely different: duplicating a book's
folder and then opening the book file in the duplicate accesses the chapter
files in the *duplicate* also, as most folks here will know. I find
FrameMaker's approach much more logical, but maybe InD is bound by the
operation of InCopy or some other part of the Adobe stable.

Something to watch out for. I guess I should be posting this to an InD
group, but I'm not on any.

-- 
Steve