Conditionalizing text insets

Report · Jul 31, 2012

FrameMaker 10, Windows 7 x64.

I have a document with a lot of external files inserted as text insets. I would like to have this file appear in a book only under certain conditions. I've created the appropriate conditions, selected the entire file, and applied the conditions. All of the insets are conditionalized, with the exception of a single inset. When I reselect that inset and attempt to reapply any of the conditions, I get a dialog, whose title is too long for its size, so you cannot fully comprehend the purpose. See below.

I do not wish to make the text unconditional, and I do not wish to delete the text. I wish to set a condition. There is nothing I can find in any FrameMaker resource that describes why I am getting this message, or what to do about it. All of the other insets are correctly conditionalized.

Any ideas?

Steve

Report · Aug 03, 2012

@Russ,

Thanks for the perspective.

Report · Aug 01, 2012

Steve,

across the ten models out there

Maybe the better approach is to avoid conditional text altogether. Sometimes it is better to manage the different possibilities through the book rather than conditional text.

If I understand you situation, you have many documents. Some are used in one model and some are used in one or more but not all models. There is no rule against using a particular document in several books.

So, suppose you created a book file for each of the ten models. Doing each book (model) separately, import the documents needed for that model. You mentioned creating chapter folders. Are you talking about creating folders in the BOOK file, say one for each chapter? If so, then you can import the files into each folder as appropriate (caveat: I have never used folders in books, so I have no idea the implications downstream of doing this). I am inferring from you post that you then want to create cross-references to the documents in the folders, say from one or more of the chapters in the book. You can do this.

NOTE that any one document can be used in any number of folders in any number of books. FrameMaker does not care how often or where you use the documents.

NOTE that nothing is conditioned, at least not whole documents. IF PARTS of each single document has to be conditioned, you can do this. Just do not condition the whole document.

NOW create a PDF from the first book. Assuming nothing INSIDE the single documents is conditioned, you can simply update the book and create the PDF.

THEN repeat for EACH book, one for each document. HOWEVER, BE SURE to update the book before creating the PDF. When you use a document in book 1 and update book 1, FrameMaker leaves information about that update in the document, particularly page numbers. When you use the document in book 2, you need to update book 2 to redo the page numbering, for example. SO, always update the book before creating the PDF, even if you have made no edits in any of the documents in the book.

Note that using this approach, there are NO text insets and NO wholly conditioned single documents. The "conditioning" is managed through the books. Each book specifies which files are to be used in that book, NOT the conditions.

It is also possible to use conditioning within each single file. Suppose a particular file has content most of which applies to two models, but there is one sentence in the content that has to be written one way for model A and another way for model B. Simply create the one file. Write the A sentence and condition it A. Right after it write the B sentence and condition is B. This one file is added to both books, A and B. Before updating the A book, you need to show condition A and hide condition B; then update the book. For book B, show condition B and hide condition A; then update the book. For each PDF, always show/hide the conditions, update the book, then create the PDF.

I may not have resolved your problems, but maybe this gives you a better approach.

Van

Report · Aug 01, 2012

I understand your suggestion, and I can see that it would likely work. But it also introduces a lot of what we're trying to get away from here, which is when something changes, we have to go in search of all the places where that information resides and change it multiple times. Making separate books reintroduces that issue, at least partially negating the point of single sourcing. Unfortunately, I've stupidly championed the idea of single sourcing so effectively, the entire organization is now convinced. The first time we make a change and every instance isn't updated, I'm going to have some explaining to do.

Still, your suggestion has merit from the perspective of getting things to work. It may be that I can find a happy compromise design based on this. Thanks for the idea.

Meanwhile, I wonder if FrameMaker will EVER be a product that has had its creaky parts updated and producing error messages for humans.

Edit: The more I look at this idea, the better I like it. And I don't think I have to give up any single sourcing advantages to do it. Thanks to the responders here - it has been a useful discussion for me, and I hope helps others avoid this same pitfall. Many thanks!

Report · Aug 01, 2012

Let me second Van's suggestion of using book-based editions, plus you can use Conditions.

We do this. Separate .book structures import common text. The common text is tagged, in the inset source, with various conditions. What appears in the importing document is controlled by what is inset and condition code settings in the importing document (which are basically set-and-forget).

But attempting to perform any mods on an inset, in the importing document, is risky. If you save out an importing.fm as a MIF and study it, you'll see that there are a some locking tags associated with insets:

They are documented in the MIF Reference Manual, except for TextInsetLocked.

I have had problems in the past with <PgfLocked Yes>. After deleting the inset, that tag got transferred to the hosting para, and it required a MIF hack to fix it. The empty para could not be changed or even deleted.

I'm actually surprised that it appears possible to apply conditions to an inset in the importing document. I would be totally unsurprised to learn that sometimes it doesn't work, or has unpleasant side effects. Apply the conditions in the source of the inset. Set the Show/Hide conditions in the importer.

Report · Aug 09, 2012

@Error7103,

"Apply the conditions in the source of the inset. Set the Show/Hide conditions in the importer."

OK, I get that, but maybe i plucked it out of context.

What if I want the entire inset to vanish from the importer? With that, I want the "host" paragraph in the importer to vanish as well.

I've inherited a few chapters like this. They contain some all-versions unconditional content and some VersionX content that is inset-based. Most of those VersionX insets are procedure steps.

We're not willingly doctrinaire around here. Just looking for reliable, high-speed maintainabiltiy.

Best regards,

Report · Aug 09, 2012

> What if I want the entire inset to vanish from the importer? With that, I want the "host" paragraph in the importer to vanish as well.

I think that circles us back to the problem that gave rise to this thread. You'd be applying a condition to the anchor for the inset, with the presumed intention of applying it to not just the anchor, but the entire inset, which might have ideas of its own as regards that condition.

And in any case, Frame may not be coded to handle this kind of condition overload. For extra credit, you can Xref that imported inset, and apply some other conditions to that .

Report · Aug 01, 2012

Steve,

The more I look at this idea, the better I like it. And I don't think I have to give up any single sourcing advantages to do it.

You indicated you are using some prewritten service bulletins. These are your single sources. The books that use them are simply using them. Assuming there is not a lot of overlap among the service bulletins, then updating the content in the service bulletins is not a process of finding all the places where they are used. The usage is in the books, which link to the content where the changes are made. As time goes by, you will probably update/rewrite the service bulletins to look less like service bulletins and more like parts of books. Then you will have single sources used in several books. Write once, publish as many times as you need.

Van