I wanted to thank you again for the help with this. I was looking at a
nightmare, and it's now just a bad memory. :-)
While it already seems to be working fine, I wanted to double-check
something. The expressions are set up as you suggested, to NOT the
conditions I don't want visible in a particular book.
However, instead of setting a condition for each book being generated
(which would involve determining all of the different valid condition
combinations; admittedly a small task in this book), I am layering tags,
mostly because that's how I already have it set up and I really don't want
to figure out how to revise the tags and their application across 400+
pages in multiple document and book files. The other reason is that I
rarely know ahead of time how many books will be coming out of the same set
of documents. There's always a minimum of two (internal and external), but
I'll often have new IP being added on months after I've started the
project.
Your suggestion works just as well with layered conditions as it does with
a condition tag set up for the particular combination of circumstances.
I was wondering, though, if you or anyone else had a lot of experience
doing it this way and if there were a limit to the number of layers that
could be used. I have a maximum of two tags on any given piece of
information at the moment, but I'm also looking ahead to other books sets I
have that can generate up to 7 or 8 documents where a piece of information
can appear in 4 but not the other 3, and there's not a lot of consistency
to the combinations. In other words, I'd rather have 7 or 8 conditions to
work with than the 20 or more that would be needed to cover all the
combinations that have appeared as new books are sourced from the same set
of documents. And yes, they really DO share enough information that it's
far better to single source than it is to split into separate projects.
So will using your suggestion keep working when information has been tagged
with more than two conditions, and is there a hard limit to how many
conditions can be layered this way?
I swear, I have to read that chapter again. Maybe several more times. And
I'd still like to know why my original expressions crashed things.
On Wed, May 11, 2016 at 1:15 PM, Robert Lauriston <rob...@lauriston.com>
wrote:
> I'd probably name that TrustedCustomerOnly (or NDACustomerOnly?)
> instead of External.
>
> On Tue, May 10, 2016 at 10:07 PM, Lin Sims <ljsims...@gmail.com> wrote:
> > Most of the text is unconditional. And sadly, I actually need the
> External
> > tag.
> >
> > Not because of any of the actual TEXT, but because of the proprietary
> > language in the footers. We have one sentence for internal, do not show
> to
> > customers on pain of feeding the dragons, and another of you're our
> customer
> > and we trust you to a certain point, but you do not show this to anyone
> > else, y'hear?. And the text is in separate variables, so I can't just
> import
> > a variable definition to them. So for the sake of not having to import
> page
> > layouts as well as conditions and variables ... I have an External tag.
> >
> > Laughable, ain't it?
> >
> > On Tue, May 10, 2016 at 9:37 PM, Robert Lauriston <rob...@lauriston.com>
> > wrote:
> >>
> >> Exactly. In your situation, I'd maybe have AOnly, ACustOnly,
> >> AInternalOnly, BOnly, BCustOnly, BInternalOnly, and Internal. Then the
> >> conditional expressions would be:
> >>
> >> for A regular version: not (ACustOnly or AInternalOnly or BOnly or
> >> BCustOnly or BInternalOnly or Internal)
> >> for A Cust version: not (AInternalOnly or BOnly or BCustOnly or
> >> BInternalOnly or Internal)
> >> for A internal version: not (BOnly or BCustOnly or BInternalOnly)
> >>
> >> If there's so little unconditional text that it makes sense to tag
> >> everything, it would probably be easier to switch to Flare.
> >>
> >> On Tue, May 10, 2016 at 5:44 PM, Lin Sims <ljsims...@gmail.com> wrote:
> >> > Interesting. If I understand you correctly, you're suggesting that the
> >> > text
> >> > that needs to appear in a certain version be tagged with a condition
> for
> >> > that version, and then in all the other versions (where it doesn't
> >> > appear),
> >> > you NOT it.
> >> >
> >> > I tell you what, after today I am definitely going to remember that!
> >> >
> >> > On Tue, May 10, 2016 at 6:31 PM, Robert Lauriston <
> rob...@lauriston.com>
> >> > wrote:
> >> >>
> >> >> If you have much content that is used in all versions, defining
> >> >> conditional text to be excluded with NOT is simpler and less work.
> >> >>
> >> >> On Tue, May 10, 2016 at 3:02 PM, Lin Sims <ljsims...@gmail.com>
> wrote:
> >> >> > One of the "rules" I learned somewhere was to either have all your
> >> >> > conditions say what the text is IN, or have them all say what the
> >> >> > text
> >> >> > is
> >> >> > NOT in, because (I was told) it could get confusing if some
> >> >> > conditions
> >> >> > were
> >> >> > for when you did want text and others where for when you didn't
> want
> >> >> > it.
> >> >> > I
> >> >> > generally pick what I want the text to be in.
> >> >> >
> >> >> > So my environment at the moment has two separate IPs, and two (or
> >> >> > maybe
> >> >> > 3)
> >> >> > separate audiences, so that was how I defined my conditions (plus
> the
> >> >> > two
> >> >> > spare that are only seen in review drafts).
> >> >> >
> >> >> > People inside the company get to see everything for a particular
> IP,
> >> >> > so
> >> >> > their book has generic plus internal information for the IP plus
> the
> >> >> > one
> >> >> > special customer's information for the IP.
> >> >> >
> >> >> > People outside the company (who aren't the specific customer) get
> to
> >> >> > see
> >> >> > the
> >> >> > generic information for the IP.
> >> >> >
> >> >> > People who work for that one special customer get to see the
> generic
> >> >> > information for the IP plus the customer-specific information for
> the
> >> >> > IP
> >> >> > but
> >> >> > NOT the internal information for the IP.
> >> >> >
> >> >> > I had considered doing separate tags for each combination, but I
> >> >> > could
> >> >> > see
> >> >> > the number of possible combinations getting wildly out of hand.
> >> >> >
> >> >> > There's the additional issue that I while I usually know which IP
> the
> >> >> > information is for (if it isn't generic), I don't always know who
> the
> >> >> > audience is. It can change. The IP has been known to change. ("Oh,
> we
> >> >> > said
> >> >> > it was IP A and everyone could see it? Sorry, it's actually for
> both
> >> >> > IP
> >> >> > A
> >> >> > and IP B, but only we and Cust01 get to see it.")
> >> >> >
> >> >> > Robert's "not" suggestion seems to be working correctly to generate
> >> >> > the
> >> >> > 6
> >> >> > books I believe I'll need, but I will probably do some more testing
> >> >> > to
> >> >> > be
> >> >> > sure, since I don't entirely understand how Frame is handling
> >> >> > conditions. I
> >> >> > honestly thought I had to explicitly state all the combinations I
> did
> >> >> > want
> >> >> > and all the ones I didn't want (hence the crashes and the plea for
> >> >> > help).
> >> >> >
> >> >> > Again, thanks to all (and particularly Robert) for all the help.
> >> >> >
> >> >> > Time to go home.
> >> >> >
> >> >> >
> >> >> > On Tue, May 10, 2016 at 5:02 PM, Robert Lauriston
> >> >> > <rob...@lauriston.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Generally speaking, when defining a set of conditions, you want to
> >> >> >> (1)
> >> >> >> minimize the amount of text that has to be tagged, (2) minimize
> >> >> >> multiple tagging, (3) maximize unconditional text, and (4) define
> >> >> >> the
> >> >> >> minimum number of conditions to achieve that.
> >> >> >>
> >> >> >> Sometimes that means defining conditions for text to be included,
> >> >> >> other times it means defining conditions for text to be excluded.
> >> >> >> Best
> >> >> >> practice, those should be named so as to indicate their function,
> >> >> >> for
> >> >> >> example IncludeInFoo, OnlyInFoo, and ExcludeFromFoo.
> >> >> >>
> >> >> >> I'm not sure why an Internal tag would ever be combined with any
> >> >> >> other
> >> >> >> tag. External should be unnecessary since it means the same thing
> as
> >> >> >> the absence of the Internal tag.
> >> >> >>
> >> >> >> On Tue, May 10, 2016 at 1:21 PM, Lin Sims <ljsims...@gmail.com>
> >> >> >> wrote:
> >> >> >> > Yours is a more elegant solution. As I said before, this is my
> >> >> >> > first
> >> >> >> > go-around with Conditional expressions. It didn't help at all
> that
> >> >> >> > the
> >> >> >> > standard I was told to apply here was to tag text with the
> >> >> >> > condition
> >> >> >> > for
> >> >> >> > the
> >> >> >> > book I want to produce. That produced some odd results I can no
> >> >> >> > longer
> >> >> >> > recall (mostly because I had text tagged for both Internal and
> >> >> >> > Cust01).
> >> >> >> >
> >> >> >> > What I wound up with, in variations, is as follows:
> >> >> >> >
> >> >> >> > For a book where I want IP A and Cust01, but not IP B or
> Internal,
> >> >> >> > I
> >> >> >> > used:
> >> >> >> >
> >> >> >> > "IP A" or "Cust01" and not ("IP B" or ("IP A" and "Internal"))
> >> >> >> >
> >> >> >> > It works.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, May 10, 2016 at 3:35 PM, Robert Lauriston
> >> >> >> > <rob...@lauriston.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> ("A" or "External" or ("A" and "External")) could be simplified
> >> >> >> >> to
> >> >> >> >>
> >> >> >> >> ("A" or "External")
> >> >> >> >>
> >> >> >> >> not (("A" and "Internal") or "B" or ("B" and "External") or
> "TBP
> >> >> >> >> or
> >> >> >> >> "WriterNote")
> >> >> >> >>
> >> >> >> >> could be simplified to
> >> >> >> >>
> >> >> >> >> not ("A" and "Internal") or "B" or "TBP or "WriterNote")
> >> >> >> >>
> >> >> >> >> But it's not clear why you can't just use
> >> >> >> >>
> >> >> >> >> not ("Internal" or "B" or "TBP or "WriterNote")
> _______________________________________________
>
> This message is from the Framers mailing list
>
> Send messages to framers@lists.frameusers.com
> Visit the list's homepage at http://www.frameusers.com
> Archives located at
> http://www.mail-archive.com/framers%40lists.frameusers.com/
> Subscribe and unsubscribe at
> http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
> Send administrative questions to listad...@frameusers.com
>
--
Lin Sims
_______________________________________________
This message is from the Framers mailing list
Send messages to framers@lists.frameusers.com
Visit the list's homepage at http://www.frameusers.com
Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/
Subscribe and unsubscribe at
http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
Send administrative questions to listad...@frameusers.com
