Re: Master page by paragraph tag

["Lynne A. Price" <lprice@xxxxxxxxxxxx>]

The recent discussion on the Framers list about the FM 7.0 Apply 
Master Pages command has not addressed the question of where all 
the master pages come from.

Text Structure Consulting, Inc., and Tassos Anastasiou have
designed a tool for maintaining a set of related master pages.
This message asks for feedback on the proposal.


THE PROBLEM:
This tool simplifies making systematic changes to the master
pages throughout a set of templates. A typical situation where
it might be used involves a set of related templates consisting
of templates for chapters, appendices, glossaries, front matter, 
index, table of contents, list of figures, and list of tables. 
Suppose all these templates are two-sided and the basic page layout 
in all of them is similar. Page numbers and running headers and 
footers are positioned consistently throughout the template set, and 
various adornments such as a company logo or rules separating the 
main text frame from the header and footer appear throughout. 
All templates use a custom master page called First. The chapter
and appendix templates also provide left and right landscape pages.
Furthermore, chapters and appendices may be divided into sections.
No custom master page is needed for a section that fits on a single
page. However, if a section spans pages, the text "Continued on next
page" appears on the bottom of all but the last page, and the text
"Continued from previous page" appears on the top of all but the
first. Thus, master pages are needed that have only the next page
message, only the previous page message, and both messages. Left-
and right-sided versions of both are needed.

Altogether then there are 8 templates, each with First, Left, and
Right pages, or 24 master pages. In addition, the chapter and
appendix templates each have two landscape master pages and 6 continued
master pages for 16 more master pages. The template set thus defines
40 master pages.

FM makes it easy to create a new master page from an existing one, so
defining the master pages for this group of templates is not difficult.
Maintaining it is trickier. Suppose there is some systematic change to 
the book design. If, for example, an adjustment is made to the inside
margins, several objects on all 40 master pages must be edited. This
much manual editing is both tedious and error-prone.

THE PROPOSED SOLUTION:
In effect, our proposed plug-in uses a table in one FM document
(the configuration file) as a script that defines the master pages
in one or more templates. The plug-in deletes all deletable master 
pages (i.e., custom pages not used by existing body pages) in the
target templates and deletes all objects from the remaining master 
pages. It uses information in the configuration table, which may be
structured or unstructured, to construct new master pages. Each row of 
the configuration table contains:

Column 1 -- Names of one or more files to be updated (one filename 
  per paragraph)
Column 2 -- Names of one or more master pages to be updated
Column 3 -- Object to place on specified pages. This column either 
   contains the name of a frame on a reference page in the configuration 
   file, or contains an anchored frame. The plug-in copies the objects within 
   the specified frame to the master pages it is constructing. Advantages 
   of reference frames versus anchored frames are briefly described
   below.
Columns 4-7 -- Height, width, top offset, and left offset of the specified 
   object on the constructed pages

Within the configuration file, variables can be used for repeated values.
Furthermore, sometimes some placement information may be calculated from 
other data. For example, the top of the body frame on First may be lower than 
the corresponding frame on Left and Right while the bottom of these frames is 
at the same position. Thus, the top offset for First should be increased and 
the height decreased by the same amount. Configuration tables with such 
calculated values can be maintained in a spreadsheet and imported into the 
FM configuration file when complete.

As mentioned above, objects on the master page can be specified in either 
anchored frames or reference frames. Use of anchored frames is more direct
and spares the user the need to define and name reference frames. Reference
frames can be used when:

1) The object includes system variables (e.g., running header/footer variables)
   that are not recognized on body pages and hence cannot be placed directly 
   in the configuration table

2) The object appears in different locations on different pages and
   hence needs to appear in different rows in the configuration table.
   For example, suppose a rule of a particular color, thickness and
   line-end style appears between the running header and the body frame,
   and that another rule with the same properties appears between the
   body frame and the running footer. Each rule requires its own row
   in the configuration table. If these rows contain anchored frames,
   both anchored frames must be edited whenever a property is changed.
   If the two rows both name the same reference frame, editing the
   rule in that reference frame propagates the changes to both rules
   in constructed master pages.

3) Anchored frames can only be used when the configuration table is
   maintained in FM. Reference frames must be used when the table is
   maintained in a spreadsheet that is imported into FM.

QUESTIONS FOR THE READER:
Please send email to info@txstruct.com or call (510) 583-1505 with
your feedback on this idea. Would you purchase such a plug-in? What
version of FM/FM+SGML do you use and on what platform? Would your 
organization be willing to sponsor part of the development cost?


Lynne A. Price
Text Structure Consulting, Inc.
Specializing in FrameMaker+SGML consulting and training
lprice@txstruct.com
http://www.txstruct.com
voice/fax: (510) 583-1505
cell phone: (510) 421-2284


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **