Producing different documents from the same source file?

Report · Dec 19, 2018

Hello all,

I write and maintain documentation for two different companies, but the software that I document is used by both.

So, I maintain two different documents which are 80% the same. Structure wise, it is exactly the same, it differs in hardware and technical names, some procedures, etc.

My question is: does Framemaker 2019 (currently using 2017 but planning an upgrade) allow me to, using variables/conditional/anything else possible for all the differences between the two documents, work with only one .fm file, and through it, produce two different PDFs?

Thanks for the help! If my description was not clear enough, just ask me specific questions about it, I will be glad to answer. This would really help me, and I would be grateful for any inputs you may have.

Thanks!

Report · Dec 19, 2018

The ability to use largely the same information for multiple outputs is one of Frame's strengths. Use variables for information that performs the same function in all the outputs but just differ in value, such as company names or product names. Use conditions to mark information that is used by one output but not the other while leaving the information that is common to both unconditioned.

I usually set up a separate file I call a settings file for each desired output. In it I define the variables specific to that output (such as CN_company_name) and the conditions used in all outputs but with only the outputs I need in the Show pane.

For example, one setting file would have the CN_company_name variable set to Acme Widgets, the condition AW_acme set to Show and the condition FI_frobs set to Hide.

The second setting file would have CN_company_name variable set to Frobs Inc, the condition AW_acme set to Hide and the condition FI_frobs set to Show. When I'm ready to create the Acme Widgets document, I import variables and conditions from the Acme_Settings file. When I want to create the Frobs Inc document, I import the variables and conditions from the Frobs_Settings file.

Report · Dec 27, 2018

Thank you so much for your answer linsims! Only now had I the time to properly reply.

So, if I have a book made of 10 .fm files, where would I set the variables and conditional text? In a copy of the same book with 10 files? The conditional text, I've been testing it and it its very straightforward to understand. Variables, not so much.

I would kindly ask you to follow through the following example:

- Having one document (book) in Framemaker that is made of 10 fm files (Lets say Chapter 1, 2, 3, up to 10)

- I want to use it to produce a document without Chapter 9 and 10, and in the new document I want to replace all the words "NO" with "YES".

What's the best way for me to produce these two outputs?

Thank you for all the help! Just now starting working with Framemaker, and I just love this tool. I can smell the amount of possibilities it allows, but amidst all of the work that has to be delivered, I do not have enough time to explore it properly.

Report · Dec 27, 2018

Whoops! I see I forgot to address your condition questions. Best way to answer this is to provide an example.

You have a book that is being provided to two different customers, Cust_A and Cust_B. Each has information specific to them that must not be seen by the other. In addition, Cust_A gets chapters 1-10, but Cust_B gets only chapters 1-8.

First, create two book files, one for Cust_A with all 10 chapters and one for Cust_B with only the first 8.

Create a settings file for each book and set up the same variables and conditions in each.

The settings file for Cust_A, for example, will have the Cust_Name variable set to Cust_A, and the RESP variable set to YES. The settings file for Cust_B will have the Cust_Name variable set to Cust_B, and the RESP variable set to NO. (Note: I usually add the settings file into the book file and set it to Exclude. That makes sure I don't lose track of which file goes with which book and also makes sure it doesn't get inadvertently printed.)

BOTH settings files will have a condition named Cust_A and Cust_B. The settings file for Cust_A will have the Cust_A condition set to Show and the Cust_B condition set to Hide. The settings file for Cust_B will have the Cust_A condition set to Hide and the Cust_B condition set to Show. (Make sure you add some color or something to the condition style so it's obvious at a glance which text is seen by which customer.) The Show Indicators option should NOT be selected in the settings file only, because when you go to final you don't want it to be obvious which text has been conditioned.

When you are working in the chapter files, make sure that BOTH conditions are set to Show (or use the Show All option) and have the Show Indicators option selected so you can see what's there for both customers. When you go to final, select all the files in the book (except the settings file), select File > Import > Formats, choose the appropriate settings file, select the Variables and Conditions checkboxes, and click Import. That will import the variable definitions from the settings file, and apply the condition settings from the settings file.

Report · Dec 27, 2018

There are two ways to handle the situation you describe, as far as including or excluding chapter files. One is to set up two separate book files, each of which contain only the files you need for that book. This is MY preferred method.

The other is to have a single book file with all the files in it, and each time you produce a version of the book, you exclude the files you don't need by right clicking on the chapter file name in the book and selecting Exclude, or, if the last time you produced a version you were excluding files, right clicking on the chapter filename and deselecting Exclude. I don't like this method, since it requires me to remember every single time that I have to either remove or add the exclusion. It does have the advantage that you don't have to create separate generated files, such as TOCs, for each book, but that's not a big deal.

Variables are actually pretty simple. You create them by clicking Insert > Variables, which opens the Variables pod. The icon to the far left of the Variables pod menu bar lets you add a new variable. You give it a name, which is how it is referred to in the document, and a value, which is your NO/YES. Any place you need either the NO or the YES, you open the Variables pod, find the name, and double-click on it. (The Variables pod is one of the things I keep open all the time, btw. It will not close unless you close it.)

Remember that Settings file I talked about? That's a separate file that I create for each output from a book file that contains the user variables and the conditions that pertain to that output. In your case, I'd create two settings files. One would have that variable contain the value NO. The other would have the same variable name but assign the value YES. When you want to change the value, you click File > Import > Formats, select Variables and the name of the appropriate settings file, and then click OK. You might want to look into Rick Quatro's Import Special plugin/script, since that gives you finer control of what is and isn't imported and is pretty cheap for the value it adds.

If you see the image below, the variables with the purple gear next to them are called "system variables", and they are in every Frame document by default. The ones with the blue gear are "user variables", those are the ones you created. The Definition column shows the assigned value. The highlighted variable is one I use for the product name. This isn't likely to change for a document, mind you, but using a variable means I don't have to retype it all the time and avoids spelling errors. You might also notice that I have a variable called DS Degree Sign, which lets me insert a degree symbol without using the ASCII codes or the character palette. Since I have the variables pod open all the time, it's faster.

All variables, system and user, are editable by clicking the pencil icon on the Variables pod menu bar. Just be careful that what you edit is the Definition field! (I goof on this from time to time, and I've been using Frame for more than 2 decades now!)

Report · Dec 27, 2018

Separate parent .book files can also be used for this role, as can Color Views (for limited instances where reflow is not required).

Report · Dec 27, 2018

I normally set up a "book of books" that contains all the book files and all the chapter files, generated files, and settings files for every document coming out of a given set of files. Given that rafaeltraquin is new to Frame, I thought it best to leave out that additional level of organization.

Report · Dec 29, 2018

Taking advantage of the thread to ask

How do you use the book of books? Just to keep track of everything?

Also adding a note to prevent confusion (I think)

Frame has its own sets of files called Settings files, used to define Word import, help export etc. I take it that you do not mean this, but just a regular frame file that you call Settings right?

Report · Dec 31, 2018

Basically, yes. It's a one-stop for all the files for all the books, and it helps me keep track when I create a new condition or variable that I import them into all the necessary files.

And yes, the settings file I'm talking about is a regular FrameMaker file. It's usually got the book name followed by _Settings.

Report · Dec 31, 2018

I've never used Color Views, and I don't really know or understand much about them. How would they help in this situation?

Report · Jan 01, 2019

View » Color » Views
Provides six different states (#1…6) that your document can be in. Each state allows a different visibility configuration for arbitrary constellations of the document's entire Color Catalog.

In each state, page elements can thus be turned on and off by the named color applied to them. Note that the color itself could be, say, full black (RGB 0,0,0) in each case, as long as there are different names for black
(names: Client_A_Black, Client_B_Black).

Here's a discussion from 2011: Color Views Common Conventions?

When I used the feature, I found that it was most useful for:
• document status indicators (Rough, Draft, Review, Proof)
• document editions (authoring {everything on}, print vs. web {margin nav on/off})
It might also be useful for paged vs. scrolled editions, although the current Publish settings seem to handle that.

It could be used for aspects of multiple client editions. For example, if one client wants a page background other than white, or one wants their simple-color logo on every page. This is an advantage that CV has over Condition Codes, by the way, as you can't apply a CC to a graphical object per se, only to it's text anchor (if it has one, and Master Page content often does not).

It apparently doesn't matter how the colors are applied (override, character format, paragraph format). And it appears that if a color is set to "Invisible" via color views, that content is not present in the output. Alas, you can't overload an object with multiple colors for this. If any are off, the object is not there. But unlike Conditional suppression, no re-flow occurs. If you use this technique on text, is just leaves blank spaces.

And you only get 6 state sets, and they don't have names. Yet another reason to have at least a readme.txt file for every document, recording the conventions used, and workflow steps.

This short note does not get into why you might want to set a color to Cutout.

Report · Jan 02, 2019

Hi Lin,

Happy New Year!

Adding to what Bob has said, you can think of Color Views as being an FM analogy to layers. The Invisible setting is the on/off toggle for the "layer" in a specific View. The nice feature of this is that FM still knows about any invisible content, though you will never see it in any output. This allows for a number of tricks to augment FM features that I have been mentioning for years.

For example, you can create background grids to toggle on/off to check placement and alignment (of graphics, tables, lists, callouts, etc.). This is especially useful in template development. You can also create x-ref and hyperlink targets to anchored frames with alternate text contained in text frames (e.g. so you don't get a whole paragraph or a very long heading for an x-ref). Use your imagination and you'll find a lot of other uses for these FM "layers".

The other nice feature is that they (Views) can be quickly changed (i.e. layers turned turned on/off even at the book level for all docs) using the <esc> v 1 to 6 shortcuts.

They're probably more for unstructured docs than structured docs though.

Arnis

Report · Jan 02, 2019

My imagination seems to be out to lunch today, although it may just be my brain being out of gear thanks to the holidays, but I'm not really understanding the purpose/use for color views. I did a little experimentation to see what effect it has, and as Bob mentioned, there are big gaps where nothing is visible if it happens to be a color that is "invisible".

One experiment I did made "black" invisible. Everything except the hyperlinks/xrefs, headings, and pictures disappeared. Amusing, but I'm not getting the point.

Report · Jan 02, 2019

Whoops. Incorrect. The graphics ALSO disappeared, but the anchored frame they're in stayed put. Interesting!

Report · Jan 02, 2019

re: My imagination seems to be out to lunch today

Heck, I didn't even use Color Views for the first 15 years that I used FM. I also have no idea what the original intent was for it. But as you can see from Arnis' and my remarks, people can find ways to employ it, that include variant editions of a common content base.

re: there are big gaps where nothing is visible

There are unlikely to be many use cases for CVs within in-flow text (redaction might be one, but it's not very elegant for that). It's more useful for marginal and Master Page elements.