GREP queries broken in CS6 and Sierra?

[darrylc63508848]

This is odd. The GREP queries I'd been using successfully in ID CS6 and Yosemite now are wonky in Sierra. All I'm trying to do is remove the <ltr> codes before and after certain txt passages and add a return. What's happening as you can see on the left is that my superscripts are reverting to normal and text two words down is turning to superscript. Huh?

The query used is shown on the right. Did the upgrade finally break CS6 or might I be missing something?

[Barb Binder]

CS6 isn't supported on Sierra, so that could be the issue, though I haven't see it manifest itself quite this way. Did you double check the query? Is the OS the only thing that has changed?

Looking ahead, my advice is if you aren't going to upgrade your software, then you really don't want to update the operating system. The software is designed for specific operating systems.

[darrylc63508848]

Hi, thanks for replying. I had a hard drive crash and my "superiors" decided that giving me a another machine made more sense than fixing the older Mac I was perfectly happy with. Unfortunately the IT guy I'm stuck with strongly suggested the upgrade even though this new one can handle the OS I was using. I'm trying to confirm it's Sierra before requesting an OS downgrade or Adobe upgrade. I figured out this GREP string many years ago and my understanding of them has waned.

[BobLevine]

Adobe won’t even sell CS6 anymore. It’s unsupported and you are, unfortunately, on your own here.

The best way to test this is download/install the CC2017 trial.

[winterm]

Apart really good point that CS6 isn't supported on Sierra.

Your code looks strange and confusing. BTW, it just founds nothing to me in a sample text below:

Do I understand you correctly, you just want to replace <ltr> with hard returns?

Well, if staying in a GREP tab, this simple query works just fine:

Find:\s?<ltr>\s?

Change to:~b

Here’s result:

[darrylc63508848]

I am aware that CS6 is not supported. I've been swimming against the tide for about four years now and this is potentially the first real problem I've had. 

I was hoping someone might dbl check the query, thanks so much. It's not quite that simple though. A block of copy will start with <ltr> there will be multiple paragraphs in between. And it will end with </ltr> coded like HTML and then need a blank space afterward (two returns) until the next <ltr> block of copy.

It's been a fairly brilliant and time saving method of formatting a book with multiple codes so I don't want to lose the functionality. But there's probably no logical explanation other than incompatibility for what's happening.

[winterm]

Well, I'm still not sure I understand you correctly...

This one might work:

Find:(\s*<ltr>\s*)([^<]+)(\s*</ltr>\s*)

Change:~b$2~b~b

Tested on Win7/CS6, and you're on Sierra... This may or may not be the case.

[Jongware · Accepted solution]

This looks like an earlier bug that was resolved in the mean time. The problem was that a GREP query changes the underlying text, but some manipulations do not carry over to adjusting the correct text formatting as well.

It's hard to imagine this could be a system compatibility problem ... ID's GREP engine is not driven by your local OS, it's rather an integral part of the software. On the other hand, you've used this GREP before – you even saved it at the time – and so it should have either worked correct before but doesn't anymore, OR the query always has had this particular bug, but you never noticed because there was no text formatting "near by" to mess up.

[darrylc63508848]

Hey folks. Been out of the office so couldn't reply before. Did some tests in the meantime. Turns out I get the same issue when using my Yosemite OS computer. The problem now seems to be with that specific query since my query for extracts <ex> doesn't do that. I haven't done a book with <ltr> letters in some time so maybe I forgot it's broken.

My Sierranoia got the better of me I think.

In any case I'm going to test winterm's GREP just to see what it does and try to resolve the issue of my supersrcripts disappearing when I include a Format change to a paragraph style. It's been an ongoing problem.

Thanks

[winterm]

Yeah, your superscripts may be broken, since we are deleting some text and thus changing the positions of other formatted text. It’s a GREP theory, I won’t dig in it deeply right now, sorry. BTW, [Jongware] mentions that same in the first part of his post.

Possible solution - remove that superscript formatting completely and reformat 'right’ things with additional GREP:

.\K\d{1,2}

So, 'main' GREP

before:

after:

'additional' GREP

before (with all superscripts already discarded):

after (final result):

[darrylc63508848]

Fortunately my Letters don't require and paragraph style beyond the Body Copy style that I globally apply. I set up two simple queries to just search for the codes and replace with an em space. Extracts require a paragraph style so I had been doing a manual search to find the superscripts (extracts generally aren't that long.

The formula you're showing now looks good but it would need to be able to separate a number in the text vs one that should be a superscript? Might work if it omitted any strings of numbers that were preceded by a space or only affected numbers preceded by a period.

Here's how it now appears:

William to Jane

Scottsboro Ala

April ²⁸, ¹⁸6⁴

Dear Jane

I snatch the moment to write you a few lines—We are under marching orders.⁴⁹ was ordered back to the Regiment this morning—when I got here I received your kind letter of the ²¹st inst. in relation to the box you sent me.

Thanks for your help