Using conditions for "Either / Or"

[Wierdbeard65]

Hi,

I'm (fairly) new to Frame (9) although not to computers and a myriad of applications!

Anyway, I have a question about Conditional Text that I cannot find the answer to via forum, site or even Google searches.

In the documentation, it gives the example of having a manual for two versions of a product, Unix and Windows. It suggests that you need two tags and would switch the appropriate tag on when you produce the printed manual.

I would like to achieve this with a single condition. Is this possible? In other words, I'd like to be able to mark text as conditional when a particular condition tag is NOT selected.

In this way, if I choose (using the example) Show Windows, I get the Windows comments (but not the Unix ones) and if I Hide Windows I get the Unix ones (but not the Windows ones). Rather than having to remember to show one and hide the other all the time.

My situation is that I am trying to produce a manual for consumption both in paper form and via electronic PDF. I have some animations which I want to appear in the PDF but (obviously) not on paper. In the paper version, I want a series of static graphics and accompanying text. I will never want both in a single document, so would like a single conditional tag of "Print Only" that will switch between the two versions.

Can this be done or am I stuck with two tags?

TIA

[peter_minneapolis]

Wierdbeard65 wrote:

Hi,

I'm (fairly) new to Frame (9) although not to computers and a myriad of applications!

Anyway, I have a question about Conditional Text that I cannot find the answer to via forum, site or even Google searches.

In the documentation, it gives the example of having a manual for two versions of a product, Unix and Windows. It suggests that you need two tags and would switch the appropriate tag on when you produce the printed manual.

I would like to achieve this with a single condition. Is this possible? In other words, I'd like to be able to mark text as conditional when a particular condition tag is NOT selected.

In this way, if I choose (using the example) Show Windows, I get the Windows comments (but not the Unix ones) and if I Hide Windows I get the Unix ones (but not the Windows ones). Rather than having to remember to show one and hide the other all the time.

My situation is that I am trying to produce a manual for consumption both in paper form and via electronic PDF. I have some animations which I want to appear in the PDF but (obviously) not on paper. In the paper version, I want a series of static graphics and accompanying text. I will never want both in a single document, so would like a single conditional tag of "Print Only" that will switch between the two versions.

Can this be done or am I stuck with two tags?

TIA

Conditional text in "Standard" FrameMaker isn't smart enough to do this. However, Structured FrameMaker, when used with a Element Definition Document (aka EDD), a counterpart to a Document Type Definition (aka DTD) can do this, but it's not trivial to set it up. Structured FrameMaker has a built-in rules processor that works as you'd expect if you'd programmed in most computer languages.

Search Google for terms like "FrameMaker structured application, structured authoring, edd, dtd, getting started," "FrameMaker conditions based on attributes," "FrameMaker structured applications development guide," and "FrameMaker structure application developers guide," and similar phrases for lots of references.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

[Jeff_Coatsworth]

If you were only going to exclude your animated graphic and not put something else in (the static graphics), you could get away with one PrintOnly or PDFOnly tag. Everything not marked with it would be included. But since in the PDF output you really want animation & no static graphics, and in the paper output you want no animation & yes to the static graphics, you'll be stuck with 2 tags.

[Wierdbeard65]

Thanks, both of you, for the very rapid response!

It looks like I'm going to be stuck with two tags since I'm not sure the rest of my department will want to go down the route of Structured FrameMaker..

[peter_minneapolis]

Wierdbeard65 wrote:

Thanks, both of you, for the very rapid response!

It looks like I'm going to be stuck with two tags since I'm not sure the rest of my department will want to go down the route of Structured FrameMaker..

You're welcome.

Take a look at this result of a Google search for "FrameMaker condition sets" without quotes: http://help.adobe.com/en_US/FrameMaker/8.0/03h/conditions.html 

You'll have to create and apply all the tags needed to manage the conditions, but once done, you can switch more easily between preferred outputs.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices

[Bob_Niland]

Can this be done or am I stuck with two tags?

Stuck with two tags. A single XOR tag might be handy, but having two is hardly much extra work. I'm doing several manuals with the XOR challenge right now (localization, not media content).

In the Book menu, select all the book component .fm files, then

View > Show / Hide Conditional Text

<*> Show	Hide
Web-Only	Print-Only
Others

Swap two *-Only codes with the <--- --->

[Set]

Push

Caveat. The Push workflow order gets important when you have extensive CCs:

1. Book: View > Show / Hide
   (almost certain to cause repagination)
   
2. Book: View > Hide Condition Indicators
   (assuming your codes have text decoration)
3. Book: Format > Page Layout > Apply Master Pages*
   (assuming you aren't just Left/Right)
   
4. Book: Edit > Update Book*
5. Book: View > Color Views
   (assuming you have some author-only stuff to switch off)
6. Book: File: > Print

I have not looked into scripting the above.

Another tip: for your XOR content that is not normal text flow, you can apply a condition code just to the anchor glyph for anchored frames and tables. Avoid, however, having the XOR'd anchors on top of each other in the paragraph.

This can get messy when both conditions are "In", as  they commonly are for authoring, so it may be cleaner to have clone  paragraphs, or even entire pages of content, which can be switched on  and off.

________

* There's an AMP option in Update Book. It is seriously unreliable in FM71./Unix. So we AMP separately.

[Van Kurtz]

If you think about it, a single condition tag would have to have the ability to be applied negatively. That is, in some instances you want the text to show when its condition is shown, and in others you would want the text to HIDE when its condition is SHOWN. Adding that ability is equivalent to having two conditions. Furthermore, having conditions with subconditions would probably make even the most experienced Frame user shriek into the night.

[Wierdbeard65]

Thanks again for the various comments. I've looked at the resources you suggest, but it all boils down to having two tags and then relying on the person creating the document to rememebr to include one and exclude the other, which is what I was hoping to avoid.

The problem is that we have quite a few either / or pairs. Our materials are international with some (slight) modifications for different countries / areas. (Usually US vs Everywhere else!) and I didn't want to risk anyone accidentally having either both sets of conditional text in, or neither.

Never mind, I'll just battle on with pairs of tags for now, I may look into Structured Framemaker at a leter date, or even see if I can't automate it to a point with the FDK.

[Jeff_Coatsworth]

The other (maybe more manageable) way is to create separate books that apply the conditions the way you want each time. I do that for my PrintOnly stuff - I include that tag & exclude the HelpOnly material.

[Van Kurtz]

Jeff,

The other (maybe more manageable) way is to create separate books that apply the conditions the way you want each time. I do that for my PrintOnly stuff - I include that tag & exclude the HelpOnly material.

If both books include the same set of fundamental files and you show one condition and hide the other for all files in the book, then when you open the other book and update, FrameMaker will complain (if I remember correctly) that some files have different condition settings. I thought one had to apply the condition set to all the documents in the book. Then you have to do it again for the other book. I do not see how having two books solves the problem.

If I am missing something, please enlighten me.

Thanks,

Van

[Bob_Niland]

If both books include the same set of fundamental files and you show one  condition and hide the other for all files in the book, then when you  open the other book and update, FrameMaker will complain ...

I would say "almost certainly", without even having tried it yet.

I do not see how having  two books solves the problem.

It doesn't, in terms of auto-applying the conditions.

If the filesets are identical, having two books could confer the following advantages:

• Unique default file names for .ps or .pdf output.
• Unique default PDFinfo for each book.
• Puts future writers on notice that the .fm files represent two different books.
• Speculation: variant scripts would have their own book files to operate on.

[Jeff_Coatsworth]

No, you're correct - I just find it more of a mental reminder - "Now I'm in the Printed Version Book. I have to change conditions to show PrintOnly. Once I'm done, put it all back to Show All"

My problem is that I'm not cranking off print stuff very often & when I do, I'm creating a new ToC & IX sections for it anyway that don't exist in my "normal" workflow.

[Bob_Niland]

... but it all boils down to having two tags and then relying on the person  creating the document to rememebr to include one and exclude the other,  which is what I was hoping to avoid.

Yes, it adds yet another thing to stewardship.

What we do:

1. Each manual source resides in its own directory, based on the document part number, say M12345.
2. In addtion to the expected M12345.book, M12345_BODY.f, M12345_TOC.fm, we create and maintain ...
3. An M12345_readme.odt*, that contains important info for future authors, including condition codes and workflow instructions.

With the advent of XOR books, the variant editions are getting a part number suffix, for example:

• M12345-US might be the U.S. edition
• M12345-UK might be the U.K. edition

As a great big hello-there-pay-attention flag, there will be TWO book files:

• M12345-US.book
• M12345-UK.book

both of which invoke the same component files. The existence of two book files just might get the writer to read the readme.

_______

* We also use the readme as a repository for fixes and enhancements for the next edit, plus a ./pending/ subdir for emails and scanned/markup PDFs. This works tons better than the previous hanging file and unsorted in-basket system of paper update requests.

[Bob_Niland]

... battle on with pairs of tags for now ...

Since I'm a few hours ahead of you in the battle, here's another caveat I just discovered.

If the leading characters/word(s) of a paragraph are conditional, they control any markers auto-created at start of para.

I want a level3 heading that is

TyreTire Inflation Specification

where the leading term is XOR'd by locale.

Example in pseudoMIF:

<Heading3><CC.UK>Tyre</cc><CC.US>Tire</cc> Inflation Specification</H3>

After tagging the Tyre and Tire cc's, and with both codes "in" (visible), I then create a cross reference to that heading. The Cross-Ref marker gets inserted at the beginning of the paragraph, apparently INSIDE the <CC.UK>. When I switch off CC.UK, bye bye marker, and an unresolved Xref error arises.

You can, with some effort, select the marker and deliberately tag it unconditional. I also move it to an unconditional portion of the para.

This tends to be less of a problem for TOC gen, because Frame will just generate a new marker if none is there.

Chances are you'll also accidentally tag some hand-inserted markers as well. Expect a few unresolveds on the first Update attempt.

[AxialInfo]

This kind of thing could be done by a custom Framescript, too. The script to change the condition could be run on-demand by the user as needed, but also have some sort of a process-trigger, e.g. when the user starts to create a PDF the script could intercept and bring up a dialog to confirm that the condition(s) have been correctly selected.