We’ve painted ourselves into a bit of a corner. We created two ToCs one with links for the eBook, one with page numbers for print media. I saw the opportunity to use conditional compilation to flip them instead of ticking them manually. We created two labels “eBook [PDF Xcl]” and “PDF[eBook Xcl]” and used the compiler’s “Apply filter” option to Exclude Documents with Label the one we weren’t using. This worked perfectly. So well, in fact, we started using the labels for other tweaks between the two versions, like web links which are live in the eBook and text in the paperback.
Then we decide to do a Large Print version of several books and the entire system falls apart because this setup is binary and can’t support three options. Is there a better way to implement the original idea so it can support three (or more) conditional compilation options?
There are several ways you can go about getting more from filters, if you need it—this is indeed an idea that scales well. Most of them will revolve around using Collections as your primary filter, and putting the variability into the collections themselves. The idea is to create a collection for each compile target, which will through one way or another, list everything that should be in that particular edition. Some ideas:
Manually created collections can work fine for some things. You drop the items into the tab that you want compiled and that’s that. It’s very simple, but it is also more time consuming and prone to error. I find this method works best for proofing smaller chunks of text. I can drag in the parts that need proofing, along with some standard elements that I always want.
Search collections will generally be the better tool for the job. With searches you can use various metadata to mark sections as being relevant to this or that edition, and the edition collection itself can look for those markers.
As for what you can use as metadata:
Keywords are an obvious choice, as you can assign however many you need to a particular item in the binder. Something may be relevant to two out of three editions, and that is no problem for keywords to handle. When setting up a collection to work toward this, you can type each keyword into the search field and set the search mode to “Any words” to include all overlap, with of course the scope being set to “Keywords”. Other options may be handy, such as draft only.
Custom metadata also opens up some possibilities. You could for instance use checkboxes to indicate which editions a section should be included within. The search itself would look for “Yes”, and to confine it to which checkboxes matter, you would first select one of the checkboxes from the magnifying glass menu, and then Option-click on the button to add additional checkboxes to the search scope.
There are surely other approaches as well. You could even continue having a simple exclusive assignment with labels, if it is unlikely that binder items will ever be relevant to more than one edition, but regard editions as consisting of more than one label using the same technique used for the “Any Words” keyword search.
One last thing of note, specifically for what set you down this path in the first place, is the Front Matter feature. That won’t solve any of the above, to be clear, but if all you need is a different ToC per edition (or whatever), then using different front matter folders is the easiest way to accomplish this. Since the Front Matter setting is bound to the compile format you use, and each edition is likely to have a different compile format, switching between editions only requires switching formats.
If you create a new collection from a search of a particular LABEL, can you then search within that collection to further filter it by a particular keyword?
In other words, I have for example 500 documents that share a particular label and which are all now a part of COLLECTION A. Within COLLECTION A, I want to search for all 36 documents that share a keyword. Is that a possible search sequence?
While you can certainly run successive searches to narrow things down, that won’t be useful to you as a compile filter, because you can only have one filter active at a time. That is why we need to use a Collection as a filter in the first place, because collections are capable of handling multiple search criteria. Thus the correct answer for your case would be to set up your collection to look for this intersection of fields in one shot:
First select “Label” from the “Search In” section.
On the second magnifying glass click, hold down the Option key, and select “Keywords”. If you’ve done this correctly, then the prompt text will read “Multiple” instead of “Label” in the entry field, and when you click the magnifying glass button again, you’ll see both fields checked.
Set the Operator to “All Words”.
The remaining settings are arbitrary.
The way this works is that both fields are internally combined into one text attribute internally. So an item with a label of “Purple” that has the keywords “Hit” and “Miss” will be considered to have the text of “Purple Hit Miss”, for the sake of what search looks for. Thus, a search criteria of “Purple Hit” that requires all words to be present will match. It will not match a document with a label of “Red” that has a “Hit” keyword.
So of course for those wanting OR logic instead, where the second example would still be a match, would use the “Any Word” operator instead. The only documents that would not match that setup are those that are set to any label other than “Purple” and lack the “Hit” keyword.
Further interesting results can be had with the “Invert Results” option, as well.
Invert reverses the match, so to use a simple example, if you search for “Purple” in the label field, then the only items that will come back in search results are anything not labelled as purple.
Ignoring diacritics probably won’t be terribly useful unless you use them in your metadata and don’t type them in that way in the search. A keyword for “Café” will still match if you type in “Cafe”.
Oh interesting, that Inverse is quite useful. And that’s good to know on the diacritics, thanks much.
In the multiple search sequence of a collection you laid out with LABEL and then KEYWORD as a ‘multiple’ search filter: is it possible to do the same thing but with two Keywords? So that you can search essentially for items that contain both the keywords at once? I’m unable to produce it but perhaps I’m missing a keystroke step.
Hmm, that should be working just fine with the first checklist of settings (make sure you didn’t leave “Invert Results” on!). Keep in mind that the whole keyword list plus the label becomes one piece of text internally, so searching for ‘Purple Hit Hit2’ with “All Words” set will match a document set to purple that has both of those keywords present. It won’t match a document that only has “Hit”.
Just think of it like you’re searching for regular old text and dismiss the complexity of the search settings. It’s no different than if you copy and paste this response into an item in your binder and run an “All Words” text search for “checklist response complexity” then you’ll find this item and any other that contains all three words. It’s that simple—the only complex part is how we are defining the source text to search within.
That did it, and makes good sense. I didn’t realize the list and labels are treated as one text block, but visualizing that helps to make more clear how the search is actually performed. Thanks very much!