Working with templates

In this topic, I address some of the issues to consider when designing files that act as templates. Much of this is subjective, of course, but even so, I will present my reasoning behind the approaches.

I have also created this page for my own personal use. When I need to know Frame's defaults, I can review this page. That's the purpose of the tables that follow the headings.

About the word "templates"

If you have experience in Word templates but not FrameMaker, the word "templates" may be misleading. In Word, templates can be attached to documents, so that when you modify the template, the document to which it's attached reflects the changes. Frame does not attach templates; rather, the word really means nothing more than a file that's used as a model for other files. You can import its tags and other settings into other files, but it's not attached in any way and is not automatic.

Use the defaults

When you launch a new document, you get quite a few things right off the bat. I will address each one later, but first, I'll tell you that in general, I like to use the defaults whenever I can. But note that I don't mean that the layout and individual definitions should be the same: what I mean is that the names of the objects should remain as is. For example, a new document has several paragraph tags. One of these is Body, and I see no need to rename it to, say, Body Text.

The reason for this has to do with copying text from one file to another, or importing text from one file into another. If Body means "the text used for the main body of the book" then why bother changing it? Further, if you have to whip up a quick new file, you can simply import the tags from your present file and you're done.

Paragraph and character tags

The following table lists tags you get by default, and additional tags that I add right off the bat because I use them in nearly every document.

Paragraphs Notes
Body This one should remain Body. When Frame imports text and is not told what to name the body copy, it calls it Body anyway.
Bulleted  
CellBody  
CellHeading  
Footer You don't get Footer as a freebie in the catalog, but it's the name used in the footer anyway.
Footnote  
Header You don't get Header as a freebie in the catalog, but it's the name used in the header anyway.
Heading1 I usually rename Heading1, Heading2, and HeadingRunIn to something that describes the level and is easy to select with a Ctrl+9, like 1Level, 2Level, 3Level. Selecting them is then only a single key.
Heading2
HeadingRunIn
Indented  
Numbered  
Numbered1  
TableFootnote  
TableTitle  
Title For most of my books this is only used on the cover, so I delete it in the rest of the book files.
Characters Notes
Bold  
BoldItalic  
Emphasis I usually delete this one and use Italic.
EquationVariables  
Italic Same as Emphasis, but I like it better.
Symbol I force the angle, weight, and variation to Regular. This helps prevent using nonexisting variations.
ZapfDingbats I force the angle, weight, and variation to Regular. This helps prevent using nonexisting variations.

Other tag-name techniques. One rule of thumb I adhere to is that I don't use spaces. I'm certainly no HTML or XML expert, but I think these should be avoided if you ever plan on exporting your docs.

The other rule of thumb is that I create tags that are named in such a way as to present their most common uses first when you use the keyboard (Ctrl+9 and Ctrl+8) to quickly select them. Take for example a tag you use to identify steps. The name for the tag you use for most of the steps may be called Step. But what about the tag used to reset the numbering to 1? Would you call it 1Step or Step1? I use the latter. Doing so presents Step and Step1 in adjacent positions in the list, and when you press Ctrl+9 and the letter s, you get Step, which is the one you use most often.

Tables

With a new document you get two defaults: Format A and Format B. I use A for whatever table design is used most often, and B for the second-most-often. I never rename Format A because when you import a file from an application other than Frame (like Word, for instance), Frame will assign Format A to each table. Assuming that the tables you import will take on the appearance of your most common format, they might as well use the same name; otherwise, you will have to rename them all. I don't rename Format B because it's probably going to reappear later anyway.

What not to do. I've seen lots of templates that use names like "2-col table" and "3-col table". Names like these are silly because Frame doesn't include the number of columns in the table definition. It appears to retain the number of columns only because it remembers what you did last time.

Cross-references

The names I use are derived from two sources: the first is Frame's defaults; the second is what you get when you import a Word document containing cross-refs. With one exception, all of these definitions in the table below are as-is; the one that I tend to modify is See Heading & Page. I have lowercased the see and removed the closing punctuation to take into account where I want to change the sentence structure a bit.

Name Comes From   Definition
Heading & Page New Word   \`<$paratext>\' on page\ <$pagenum>
Page New Word   page\ <$pagenum>
Page Number   Word   <$pagenum>
Paragraph Number   Word   <$paranumonly>
Point Display   Word <$paratext>
Point Source   Word   <Default_XREF_style><XREF>
See Heading & Page New Word see \`<$paratext>\' on page\ <$pagenum>
Table All New     Table\ <$paranumonly>, \`<$paratext>,\' on page\ <$pagenum>
Table Number & Page New     Table\ <$paranumonly> on page\ <$pagenum>
Table & Page   Word   Table\ <$paranumonly>, \`<$paratext>,\' on page\ <$pagenum>

I usually take the time to delete Point Source.

Variables

Never ever never ever define a variable that is specific to a file in a book. Never. If you can't import the variables from any file into any other file without doing damage, come up with another approach.

Master pages

When you set up a master page, do as much as possible from the dialogs like the Column Layout dialog, then nudge headers and footers afterward, if you need to. Reason is that if you adjust the dimensions or location of the main body flow, you create a disconnect or override (it's easier to demonstrate than to describe).

Many files use a different first page. You can call them what you want (I call a main chapter's first page First), but if you should need yet another first-page layout for the TOC and index, do not use the same name -- use something like FirstTOC and FirstIndex instead. Reason: If you should later import page layouts from one the main book into the special chapters, you'll destroy the first pages of the TOC and index.

Reference pages

I remove unused reference pages. Two types of reference pages that have a way of propagating throughout every file are TOC and HTML reference pages. The TOC reference has no need to be in any file other than the TOC, and having it elsewhere can only help to damage the TOC's own reference page.

The HTML reference is more subjective. For any book, Frame examines the one in the first file and ignores the rest, so it can definitely be removed from other files. If you don't think your files will ever be made into HTML, you can just remove it everywhere. If you need it again, you can just create a new document and import its HTML page -- you'll end up with the same one you had originally.