In 8 years, my FrameMaker "templates" for publishing display module datasheets have never remained static from one datasheet to the next. I always have changes that I need to carry forward to future publications -- ideas I glean from the technical support database; reviewer suggestions; different kinds of source information from our many suppliers; and from the constantly changing technology of the display industry.
In other words, I don't really have templates. Instead, I reuse my most recent publication for whatever "family" of display modules I am working on. I use conditional text to hide information when I publish a new datasheet. A few examples of the hidden information are "here is the formula to calculate the spec" and "use this X information only under these Y circumstances and keep hidden if not needed" or "have an engineer measure each time, then add 10% -- do not use supplier spec".
Example of final datasheet: http://www.crystalfontz.com/products/document/3187/CFA635-xxx-KL_Data_ Sheet_Release_2013-03-06.pdf.)
I've tried keep how to/alternative information in separate files, but that adds too much time because of the nonstop changes. Ideally, I would like to open 2 views of a document at the same time: one with the hidden notes hidden and one with the hidden notes visible. This would make my work easier when I need make manual page breaks, be sure I applied conditional text to a paragraph return, etc.
Any thoughts on this? I am using FM10.
Sylvia in Spokane Valley, WA
the only way would be to have two instances of FM running. In the first, open the file and show all conditional text elements (set but dont save).
In the other FM instance open the same document (for viewing only). In this one you will see the end output from the last time you saved the doc.
> the only way would be to ...
You can also create clone documents that import the entire Flow A of the master document (as a text inset), but with the desired condition codes preset. Although these clones could be opened read/write, you can't edit the insets. This approach might be a little more convenient for rendering v.s the open-RO approach.