Last edit: 05-03-17 Graham Wideman
| Last edit: 05-03-17 Graham Wideman |
FrameMaker |
| Document Layout Concepts (Frames and All That) Article created: 2000-01-15 |
The primary reason to use Framemaker is the power that it offers in managing long and possibly technically complex documents. And while detailed control of the formatting of every paragraph and character is important, the overarching concern is overall structure and layout on a document- or book-wide basis.
As the product's name announces, at the heart of FrameMaker's structure and layout paradigm is the "Frame". Yet I found the user documentation on the actual subject of frames to be perplexingly opaque. Frames are mentioned here and there, and what is described is not incorrect. But nowhere in the user docs is there a concise and complete discussion of this central FrameMaker feature -- which tends to stall efforts to actually get started on using FrameMaker in a productively-planned manner. Indeed, it is tempting to speculate that the FM learning curve is infamously steep precisely because this conceptual core is so ill illuminated.
So, determined to dispell the fog (at least for me!), I resorted to studying the very helpful Programmers' Reference and Guide, and built a MIF-Browser tool to get to the bottom of the matter. Herewith is an effort to clarify what to me seem the essentials needed for productive use of FrameMaker, condensed in one place.
The following drawing summarizes the top level concepts essential to mastering FrameMaker's layout and document structuring environment, including the three varieties of Frame and how they relate to one another and "contain" the actual visible elements that will appear on the finished pages.
The simple diagram notation is borrowed from the field of data modeling where it is used by software architects as part of the process to concisely document and communicate the important structure of an application's data. (It's also similar to the object diagrams provided with Microsoft applications for users to develop Automation macros and programs.) For some readers it will be intuitively straightforward -- others may wish to refer to the key below. In the ensuing discussion I describe each of the important relationships, after which the less-familiar readers will hopefully also find the diagram an effective distillation of the descriptions.
Because it's inconvenient to view this diagram and the following discussion at the same time, you may wish to print the diagram, or open two browser windows.
Discussion:
Frame Types: There are three kinds of Frame:
Note that in Frame-speak, the term "graphic object" includes not only geometric shapes and imported images, but also single Text Lines, and of particular note, Text Frames. From this it follows that the "generic" Anchored and Unanchored Frames are refered to collectively (and in my opinion unintuitively) as Graphic Frames, as opposed to the "specialized" Text Frame.
"Anchored": means that the object does not have a fixed position on the page, but rather is "anchored" to a particular position in the text. If the text surrounding the anchor moves "up" or "down" (eg: the users adds or deletes text preceding) then the anchored object will move accordingly. One of the types of Graphic Frame is Anchored, and Tables also are Anchored.
(Note that the term "anchored" is potentially counter-intuitive to the new user. Unlike anchoring a boat, the effect is not to hold the object in a fixed position, but rather to moor or harness it to something else that might move.)
Tour of the Diagram's Numbered Relationships
[1] Although not exposed directly to the user, each Page employs a top-level Unanchored Frame (the "Page Frame") which is the same size as the page, and is used as the overall container for all the other objects on the page. While Frame user docs talk about placing an object "directly on the Page", they are really talking about placing the object in the Page Frame. The distinction is minor, except that it helps to understand that the Page Frame behaves like any other Unanchored Frame -- learn about one and you've learned the other too.
[2] Unanchored Frames can contain other Unanchored Frames -- ie: they can be nested. In fact they can only be nested, as there is nowhere else to place an Unanchored Frame. (Note that where I have drawn direct or indirect loops on this diagram the meaning is this: a particular object may directly or indirectly contain other objects of the same type, but, as is probably obvious, it is prohibited from containing itself!)
[3] An Unanchored Frame can hold Text Frames.
[4] A Text Frame can hold Paragraphs, which usually hold lines of text. The relationship [4] is actually an abbreviation for what's really happening behind the scenes, detailed next to the "Flow" object.
Behind the scenes, FrameMaker actually uses Flow objects to collect paragraphs that belong together. When a Body Page is initially laid out (manually, or via Master Pages), each of its Text Frames is associated with a particular Flow, by way of its "flow tag". Paragraphs typed or copied into a particular Text Frame become members of the flow determined by that Frame's flow tag.
As the text is inserted or deleted, paragraphs are free to appear in (i.e.: "flow to") previous or subsequent Text Frames having the same flow tag. If there is only one Text Frame associated with a particular flow -- as in the case of an unconnected side-bar -- then of course FrameMaker performs no "flowing". In these cases the flow can be simply unnamed (though it has a unique ID behind the scenes.).
All that said, for the purposes of an initial understanding, the simplification of "Paragraphs contained in Text Frames" is close enough.
[5] A Text Frame can hold (via anchors) Anchored Frames.
[6] An Anchored Frame can hold Text Frames. (So note that [5] + [6] means that you can nest TF--AF--TF--AF etc if you want, though you can't directly nest a Text Frame inside a Text Frame.)
[7] A Table's Cell holds Paragraphs... which can hold anything a regular Paragraph can hold (EXCEPT that paragraphs in a table can't hold another Table directly -- but can hold an Anchored Frame which can hold a Text Frame and then another Table.)
It is possible to ignore Master Pages, and create and position all needed Frames "manually" on the Body Pages (using only the objects and concepts diagrammed above). However, in most scenarios you will want to employ Master Pages to control as much of the repetitive Body Page layout as possible.
A Master Page contains just the same kinds of objects as described above for Body Pages, but instead of appearing directly they control various aspects of any Body Page based on the particular Master Page.
The gist of the diagram is the covered in the following two points:
If you actually use the above conceptual initiation as an introduction to FrameMaker concepts, then you might proceed along one of the following lines:
Go to: