Surely someone has this figured out.
I have a running header in an index where I want the first index term on a page to be in the header (left) and last term in header (right), but I don't want the page numbers in the index entry in the headers. So I applied a GREP style up to the first 2 spaces. However when I generate the entry the character style for the running header variable is not being applied to the index entry text as expected.
The running header does work if I apply the character style manually. And I suppose I could do a grep search and apply them after generating the index but I'd rather it worked automatically.
Does anyone know the right way to make this happen?
Adding: I am not very good at GREP. I just figured out how to write the GREP for find any Character preceding two spaces and apply the Character Style.
But, I tried putting that in the GREP Style and it still does apply it to the generated index text.
I can however use it to apply the style after generating the index. So I guess there's that.
Still looking for answer on whether GREP styles can be applied to index text automatically—and what I am doing wrong.
You can do this automatically, but use a nested style on the Index Level 1 Tag:
Assign a character tag (I called mine TOC) that doesn't change anything through 2 spaces.
Barb, are you already on '18? If so, did you try the same thing with a GREP Style? If yes and yes and no it doesn't work, I'll submit that feat req. right away.
Who knows, we may get lucky and be in time for the very first round of bug fixes. </grinsmilesigh>
I am on 2018 but I am self-proclaimed GREP avoider, wherever possible.
Happy to give it a shot—still have the file set up—but what GREP string would you like me to test?
OP's attempt in post #2 is a good first attempt, but rather than collecting those two spaces and then looking back, I propose looking ahead instead (Forward! Onward! )
This matches any character (the period), one or more as needed (the plus) until the forward look (the (?=....) parenthesized expression) matches two space-like characters (the double \s). (And that's GREP 101, honestly. If you ever need an actually complicated search expression, just holler.)
Not safe to use in a straight-up GREP (it is free to start matching anywhere it likes, and a hard return is a spacey character as well, so it'll happily straddle a paragraph boundary), but GREP Styles are confined to single paragraps only, by design.
First of all, thank you for the GREP and the accompanying explanation!
Here are the results, baffling at best:
That's the same result I got.
Also, now my last entry in my test was: Mexican Border, The
After eliminating the extra return thing at the bottom I get Mexican Border,
So, it eliminated the The
I tried then to change the variable to remove the trailing punctuation, but it then eliminated the entire entry. LOL.
Too much brain damage to figure that out. I'll probably just apply the style manually for any it messes up.
That's odd, and I got the same result. Here's what I'd do:
In the index, change the space Following Topic to an en or em space, and then update the nested style to apply TOC through one of the same character. An em space will look about the same as two spaces, and now the Index is fully automated.
Oh! Duh. Well that would be simpler. I'll try that.
Hmm. Welp. It sorta worked, but it's not picking up the last on the page right side one. Weird.
I'm still on 2017. I'll keep futzing. Doing the grep thing afterward may be less brain damage.
What's showing up? I found that my little index had an extra line at the end after I generated it. I had to delete it, and then update the index before the last word showed up correctly.
Well, I' be darned.
Yep it was the extra return thingy.
The good news is that it didn't come back after I updated the index. Glad we could help.
Edit: Actually it did come back.
These running header variables should pick up character styles, but, to freely abuse Orwell, some character styles are more equal than others. For some reason they never have worked right with GREP styles! You'll find it works as advertised when you apply them through their more limited precursor Nested Styles instead.
(Which is something Adobe might want to fix some time. I'll try and see if this is made to work in the latest 2018 release; if it isn't, I'll submit it as a feature request. There seems to be no technical reason it should not work.)