RE: Conditional text insets
One possibility for handling conditions in insets without applying the conditions is to set up a very simple structured document and manage conditions using attributes. Wait - don't have a heart attack! It is possible to set up an extremely simple structure that doesn't do anything other than let you assign the attributes you need (print vs. help) to your paragraphs. Then you could go ahead and use your paragraph catalog as you always do and otherwise ignore the structure. It might not be any more complicated than using scripts or managing multiple conditions. Fred -- Fred Wersan Senior Technical Writer MAK Technologies 68 Moulton St. Cambridge, MA 02138 617-876-8085 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Conditional text insets
Thank you all for your comments and detailed explanations of how you deal with conditions and text insets. The short answer to why we'd like to use clean insets is simplicity - minimize the number of conditions we need to create, minimize the potential for writers to unwittingly apply conflicting conditions, maximize the use of as many standard conditions (e.g., Help Only, Print Only) as we can. I am aware of how to solve conditional problems, although I'm probably not as adept at it as many of you. Our situations are not quite as complex as some of the examples you have posed (at least not relative to the projects I have worked on). As a department, we try to avoid layering conditions and creating conditions unless absolutely necessary. Sometimes it can't be avoided. In any case, many of us meticulously record Show/Hide settings create conditional settings files to easily import conditional settings for our different outputs. I'm sure many of you do, too. The potential for scripting a solution (as posed by Rick Q.) gives me hope. The department has serious initiatives that include simplify, automate, cut costs, increase productivity. Anyway, I'm holding on to your e-mails in case our Product Owner nixes a scripting solution and we end up handling this manually. At my age, I need all the reminders I can get. Conditionals make my head hurt - your e-mails could be part of my pain relief program Thank you again for your interest and information. From: Stephen O'Brien [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 4:58 PM To: Duncan, Gary; Stephen O'Brien; framers@lists.frameusers.com Subject: RE: Conditional text insets Now I see. That is FrameMaker's normal behavior...so the need for scripting... If I understand you have 50 text insets...with 30 with one conditional tag and 20 with anotherwhen you update the text insets the conditional format on their marker disappears... Sounds like a job for a different book for each need... Couldn't each text inset become a document in a book and then by controlling the numbering the first 10 text insets are numbered like section 1, the next ten become numbered as section 2, etc... No conditional notions here... Does that help? At 03:19 PM 25/04/2008, Duncan, Gary wrote: Hi Stephen, Another person on the list was confused, too. I probably should have mentioned that we are single-sourcing for Print and Help and are not conditionalizing the text inset content directly. The inset is clean, we call it in, conditionalize from within the container file. That works until the inset is updated (called back in). The inset and related condition info is replaced by the clean inset that is called back in. That is the basic dilemma. Gary From: Stephen O'Brien [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Friday, April 25, 2008 3:12 PM To: Duncan, Gary; framers@lists.frameusers.com Subject: Re: Conditional text insets Not sure I understand the problem. But I am interested because I use text insets (several hundred) and conditional text formats (twenty). Let's say that Doc1 has a text inset Doc2 which has three conditional formats A, B, and C. If in Doc1 I want to see only the content of Doc2 that is flagged with condition C, I set show condition C in Doc1 and that's that. No problem. The only time I had a problem with this is when I had the following case: Doc1 has a text inset Doc2 with a text inset Doc 3 (with conditional formats called A, B, and C). I set show condition C in Doc1 and it didn't work! The problem I believe was that the condition was not defined the same way in Doc2 so the specification didn't make it to Doc3. I deleted the condition in Doc2 and then the correct condition definition (created in Doc3) was imported into Doc2 and then Doc1. I wonder if this is clear..helps. I don't understand how/why a script would be useful here. I probably don't quite understand the problem. Good luck. At 08:20 AM 24/04/2008, Duncan, Gary wrote: Hi everyone, We are trying to use text insets that get called into the chapter and then are conditionalized from within the container file. For example, if we want the content of an inset to appear only in Help, we give it a HelpOnly condition from within the container file. We do not want to conditionalize the text inset content itself because the condition may not be appropriate in other places we use the inset. This works fine until we revise the inset and it gets called back into the container file. The condition is lost. At first, it seemed like a bug. But after thinking about it, it makes sense that reimporting the text inset replaces everything associated with the previous version. The buggy thing is that Frame still indicates that the inset is conditional (in the lower left corner of the screen where the paragraph/flow info shows
Re: conditional text insets
We do not want to conditionalize the text inset content itself We'd like to add our voice to the others who are urging you to overcome this reluctance. We've ourselves faced this problem again and again over the years and have never been able to gin up a way to do this without actually putting in the dog labor of going back and reprocessing all the text inset modules to rearrange the conditionalization inside these text insets. There may be a better world but this is the world we've got. There's always going to be something that cannot be finessed and is going to require dog labor. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Conditional text insets
As long as your text insets and container files have exactly the same conditional text options, when you pull in a text inset into a container file, this text inset inherits the conditional text setting of the container file. For example, let's say in a container file, you have Condition and Condition B, and you elect to show Condition A, but not Condition B. If you pull in a text inset that is unconditional, then it will always show. If you pull in a text inset that also has the conditions and you have elected show Condition A in the text inset, then when you pull in the text inset, it will show in the container file. If you have elected to show Condition B in the inset, then when you pull in the text inset, it will NOT show up in the container file, because the container file is set to show condition A. To get the text inset to show in the container file, you need to set the container file to show Condition B. I do this set up all the time with hundreds and hundreds of text insets and many container files without any scripts. Let's say that I know that a text inset is about 90% the same when used between two container files, but 5% is needed only for Container file A and the other 5% is needed for only Container file B. I make sure that both container files have the conditions ContainerA and ContainerB. In the text inset, which must have the same conditions, I apply the condition of ContainerA to the text that I only want to show up in the Container A file. I apply the condition of ContainerB to the text that I only want to show up in the Container B file. Then, I make sure that in the Container A file, that the ContainerA condition is set to show and that the ContainerB condition is set to hide, then when I pull in the text inset, only the text marked for Container A show. (and obviously, just flip this scenario for Container B). The trick is to conditionalize your inset (all or part) BEFORE you pull it into the container file and make sure that container file and text inset have the EXACT same conditional text options. The text inset then inherits the settings of the container file. HTH, TVB -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen O'Brien Sent: Friday, April 25, 2008 1:12 PM To: Duncan, Gary; framers@lists.frameusers.com Subject: Re: Conditional text insets Not sure I understand the problem. But I am interested because I use text insets (several hundred) and conditional text formats (twenty). Let's say that Doc1 has a text inset Doc2 which has three conditional formats A, B, and C. If in Doc1 I want to see only the content of Doc2 that is flagged with condition C, I set show condition C in Doc1 and that's that. No problem. The only time I had a problem with this is when I had the following case: Doc1 has a text inset Doc2 with a text inset Doc 3 (with conditional formats called A, B, and C). I set show condition C in Doc1 and it didn't work! The problem I believe was that the condition was not defined the same way in Doc2 so the specification didn't make it to Doc3. I deleted the condition in Doc2 and then the correct condition definition (created in Doc3) was imported into Doc2 and then Doc1. I wonder if this is clear..helps. I don't understand how/why a script would be useful here. I probably don't quite understand the problem. Good luck. At 08:20 AM 24/04/2008, Duncan, Gary wrote: Hi everyone, We are trying to use text insets that get called into the chapter and then are conditionalized from within the container file. For example, if we want the content of an inset to appear only in Help, we give it a HelpOnly condition from within the container file. We do not want to conditionalize the text inset content itself because the condition may not be appropriate in other places we use the inset. This works fine until we revise the inset and it gets called back into the container file. The condition is lost. At first, it seemed like a bug. But after thinking about it, it makes sense that reimporting the text inset replaces everything associated with the previous version. The buggy thing is that Frame still indicates that the inset is conditional (in the lower left corner of the screen where the paragraph/flow info shows). The conditional dialog indicates that the inset is conditional, but does not indicate which condition. In the end, however, the information seems bogus because if you click on something else, then click back on the inset, the info is carried over from the previous text you clicked on. If the conditional info was truly held in Frame, I was hoping that a solution could be a script that scans for insets with associated conditions and update and apply the condition. Now, I am not so hopeful. Has anyone run into this and solved the problem? Thank you... Gary ___ You are currently subscribed to Framers
Re: Conditional text insets
Hi Gary, Here is an idea for solving this with a script. Each text inset has a Unique property, which acts as a serial number for the inset. This number remains constant, even after the inset is updated. You could follow a workflow similar to this. 1) Import and correctly conditionalize your insets. 2) Run a script that would loop through the insets and pick up its Unique value and the current condtion applied. This information would be stored in some kind of database. 3) After insets are updated, another script would be run that would lookup each text inset's Unique value in the database and retrieve the appropriate condition for that inset. The script would apply the proper condition to each text inset. Of course, a script like this could be run on a single document, book, or an entire folder (and subfolders) of documents. It could be further automated so that the first script could be run automatically whenever the document is closed, and the second script could be run automatically when the script is opened (after the insets are updated). As usual, with FrameScript the sky is the limit. Rick Quatro Carmen Publishing 585-659-8267 www.frameexpert.com - Original Message - From: Duncan, Gary [EMAIL PROTECTED] To: framers@lists.frameusers.com Sent: Thursday, April 24, 2008 8:20 AM Subject: Conditional text insets Hi everyone, We are trying to use text insets that get called into the chapter and then are conditionalized from within the container file. For example, if we want the content of an inset to appear only in Help, we give it a HelpOnly condition from within the container file. We do not want to conditionalize the text inset content itself because the condition may not be appropriate in other places we use the inset. This works fine until we revise the inset and it gets called back into the container file. The condition is lost. At first, it seemed like a bug. But after thinking about it, it makes sense that reimporting the text inset replaces everything associated with the previous version. The buggy thing is that Frame still indicates that the inset is conditional (in the lower left corner of the screen where the paragraph/flow info shows). The conditional dialog indicates that the inset is conditional, but does not indicate which condition. In the end, however, the information seems bogus because if you click on something else, then click back on the inset, the info is carried over from the previous text you clicked on. If the conditional info was truly held in Frame, I was hoping that a solution could be a script that scans for insets with associated conditions and update and apply the condition. Now, I am not so hopeful. Has anyone run into this and solved the problem? Thank you... Gary ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/frameexpert%40truevine.net Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Conditional text insets
Not sure I understand the problem. But I am interested because I use text insets (several hundred) and conditional text formats (twenty). Let's say that Doc1 has a text inset Doc2 which has three conditional formats A, B, and C. If in Doc1 I want to see only the content of Doc2 that is flagged with condition C, I set show condition C in Doc1 and that's that. No problem. The only time I had a problem with this is when I had the following case: Doc1 has a text inset Doc2 with a text inset Doc 3 (with conditional formats called A, B, and C). I set show condition C in Doc1 and it didn't work! The problem I believe was that the condition was not defined the same way in Doc2 so the specification didn't make it to Doc3. I deleted the condition in Doc2 and then the correct condition definition (created in Doc3) was imported into Doc2 and then Doc1. I wonder if this is clear..helps. I don't understand how/why a script would be useful here. I probably don't quite understand the problem. Good luck. At 08:20 AM 24/04/2008, Duncan, Gary wrote: Hi everyone, We are trying to use text insets that get called into the chapter and then are conditionalized from within the container file. For example, if we want the content of an inset to appear only in Help, we give it a HelpOnly condition from within the container file. We do not want to conditionalize the text inset content itself because the condition may not be appropriate in other places we use the inset. This works fine until we revise the inset and it gets called back into the container file. The condition is lost. At first, it seemed like a bug. But after thinking about it, it makes sense that reimporting the text inset replaces everything associated with the previous version. The buggy thing is that Frame still indicates that the inset is conditional (in the lower left corner of the screen where the paragraph/flow info shows). The conditional dialog indicates that the inset is conditional, but does not indicate which condition. In the end, however, the information seems bogus because if you click on something else, then click back on the inset, the info is carried over from the previous text you clicked on. If the conditional info was truly held in Frame, I was hoping that a solution could be a script that scans for insets with associated conditions and update and apply the condition. Now, I am not so hopeful. Has anyone run into this and solved the problem? Thank you... Gary ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/sobrien%40innovmetric.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Stephen O'Brien Technical Writer / Rédacteur technique InnovMetric Software Inc. / InnovMetric Logiciels inc. 2014, Cyrille-Duquet, suite 310 Québec (Québec) Canada G1N 4N6 Tel.: (418) 688-2061 Fax: (418) 688-3001 E-mail: [EMAIL PROTECTED] www.innovmetric.com PolyWorks, the Universal 3D Metrology Software Platform for Manufacturing (TM) Don't miss the upcoming International PolyWorks User Meeting on May 29-30, 2008, in Montreal, Canada! http://www.innovmetric.com/Manufacturing/ipum2008.aspxRegister Today! Ne manquez pas le prochain Congrès international des utilisateurs de PolyWorks les 29 et 30 mai 2008, à Montréal, Canada! http://www.innovmetric.com/Manufacturing/ipum2008.aspx?lang=frInscrivez-vous dès aujourd'hui! ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Conditional text insets
Hi Stephen, Another person on the list was confused, too. I probably should have mentioned that we are single-sourcing for Print and Help and are not conditionalizing the text inset content directly. The inset is clean, we call it in, conditionalize from within the container file. That works until the inset is updated (called back in). The inset and related condition info is replaced by the clean inset that is called back in. That is the basic dilemma. Gary From: Stephen O'Brien [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 3:12 PM To: Duncan, Gary; framers@lists.frameusers.com Subject: Re: Conditional text insets Not sure I understand the problem. But I am interested because I use text insets (several hundred) and conditional text formats (twenty). Let's say that Doc1 has a text inset Doc2 which has three conditional formats A, B, and C. If in Doc1 I want to see only the content of Doc2 that is flagged with condition C, I set show condition C in Doc1 and that's that. No problem. The only time I had a problem with this is when I had the following case: Doc1 has a text inset Doc2 with a text inset Doc 3 (with conditional formats called A, B, and C). I set show condition C in Doc1 and it didn't work! The problem I believe was that the condition was not defined the same way in Doc2 so the specification didn't make it to Doc3. I deleted the condition in Doc2 and then the correct condition definition (created in Doc3) was imported into Doc2 and then Doc1. I wonder if this is clear..helps. I don't understand how/why a script would be useful here. I probably don't quite understand the problem. Good luck. At 08:20 AM 24/04/2008, Duncan, Gary wrote: Hi everyone, We are trying to use text insets that get called into the chapter and then are conditionalized from within the container file. For example, if we want the content of an inset to appear only in Help, we give it a HelpOnly condition from within the container file. We do not want to conditionalize the text inset content itself because the condition may not be appropriate in other places we use the inset. This works fine until we revise the inset and it gets called back into the container file. The condition is lost. At first, it seemed like a bug. But after thinking about it, it makes sense that reimporting the text inset replaces everything associated with the previous version. The buggy thing is that Frame still indicates that the inset is conditional (in the lower left corner of the screen where the paragraph/flow info shows). The conditional dialog indicates that the inset is conditional, but does not indicate which condition. In the end, however, the information seems bogus because if you click on something else, then click back on the inset, the info is carried over from the previous text you clicked on. If the conditional info was truly held in Frame, I was hoping that a solution could be a script that scans for insets with associated conditions and update and apply the condition. Now, I am not so hopeful. Has anyone run into this and solved the problem? Thank you... Gary ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/sobrien%40innovmetric.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. Stephen O'Brien Technical Writer / Rédacteur technique InnovMetric Software Inc. / InnovMetric Logiciels inc. 2014, Cyrille-Duquet, suite 310 Québec (Québec) Canada G1N 4N6 Tel.: (418) 688-2061 Fax: (418) 688-3001 E-mail: [EMAIL PROTECTED] www.innovmetric.com PolyWorks, the Universal 3D Metrology Software Platform for Manufacturing (TM) Don't miss the upcoming International PolyWorks User Meeting on May 29-30, 2008, in Montreal, Canada! Register Today! http://www.innovmetric.com/Manufacturing/ipum2008.aspx Ne manquez pas le prochain Congrès international des utilisateurs de PolyWorks les 29 et 30 mai 2008, à Montréal, Canada! Inscrivez-vous dès aujourd'hui! http://www.innovmetric.com/Manufacturing/ipum2008.aspx?lang=fr ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
