2

I'm formatting a music program that mixes English and Chinese. I read a tip that suggested using the Chinese font in the style definition and then using a “GREP style” for switching to an English font (and rules) over characters in the range of those characters.

Great idea!

Note that I already am adept with regular expressions in Perl 5, and I'm also knowledgeable about Unicode including how it's organized.

Everything I find via Google on InDesign GREP Style is a basic tutorial about regular expression and dead simple to anyone who already knows Perl etc. I've not seen anything about how InDesign 11.1.0.122 on Windows is using the regexp, which I assume is some particular way

enter image description here

Note that the expression stops at the last space in the paragraph, and is not applied to the last word. A work-around is to add extra space at the end, but that's wrong for centered text.

The expression /[$a-$b]+/ when $a and $b include all ASCII characters will not stop at a space, and even if it did (e.g. some other kind of whitespace character), the stuff after it would be consecutive letters in that range, too.

So what exactly is InDesign doing with the expression, and more to the point why does it not work as stated?

(Once I get it working at all, I can improve upon it if InDesign knows the codes for Unicode properties, rather than stating a range of absolute code point values.)

  • Indesign has several custom matchpoints. Make nongreedy matching use ?+. Then matching \Z|\> instead of space. You would get this problem even in perl – joojaa Oct 27 '15 at 1:26
  • How in the world did “Laundry Song” become “Tibetan Dance” (or vice versa)?!? – Janus Bahs Jacquet Oct 27 '15 at 1:42
  • 1
    @JanusBahsJacquet Like my nephew remarked to someone selling "Texas Toast": "In Dallas we just call it Toast". I think the English name is not a translation but the name given to it by outsiders. – JDługosz Oct 27 '15 at 2:24
  • @joojaa ah... an unseen space at the end of the expression, after the '+'! Your comment inspired me to figure that out, but I don't see how what I reported would be a problem or need lazy matching. – JDługosz Oct 27 '15 at 2:27
  • 1
    Well thanks for taking the moment. It was enough to get me un-stuck. – JDługosz Oct 27 '15 at 23:55
1

It turns out I had an unseen trailing space in the field. Maybe you can tell in the blue highlight in the illustration once you know to look for it. I had

[\x{0020}-\x{2fff}]+ 

rather than

[\x{0020}-\x{2fff}]+

due to extra space being present from the copy/paste of the string.

Don't see any difference above? Highlight it to show where the string actually ends. ☺

  • Now that you mention it, I can also see that space in my post (the original tip) as well. God I hate Adobe's Jive editor 😡 - to think I even wrote out the required space as \x{0020} just to make sure it would appear correctly! – usr2564301 Oct 30 '15 at 22:44
  • The space inside the range is correct, and using \x20 emphasizes that the number is in range and contiguous. The mistake is a space after the + on the end. – JDługosz Oct 30 '15 at 23:01
  • That's the one I meant - and it appears courtesy of the Jive editor. The only one that ought to be in the expression is the one I wrote out in full. – usr2564301 Oct 30 '15 at 23:22
  • Ok, I understand what you said now. The post I copied it from also had a > in front. – JDługosz Oct 31 '15 at 6:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.