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.)

Improve this question
6
  • Indesign has several custom matchpoints. Make nongreedy matching use ?+. Then matching \Z|\> instead of space. You would get this problem even in perl
    – joojaa
    Commented Oct 27, 2015 at 1:26
  • How in the world did “Laundry Song” become “Tibetan Dance” (or vice versa)?!?
    – Janus Bahs Jacquet
    Commented Oct 27, 2015 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
    Commented Oct 27, 2015 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
    Commented Oct 27, 2015 at 2:27
  • 1
    Well thanks for taking the moment. It was enough to get me un-stuck.
    – JDługosz
    Commented Oct 27, 2015 at 23:55

1 Answer 1

Reset to default
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. ☺

Improve this answer
4
  • 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!
    – Jongware
    Commented Oct 30, 2015 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
    Commented Oct 30, 2015 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.
    – Jongware
    Commented Oct 30, 2015 at 23:22
  • Ok, I understand what you said now. The post I copied it from also had a > in front.
    – JDługosz
    Commented Oct 31, 2015 at 6:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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