6 Replies Latest reply on Dec 13, 2012 1:23 AM by [Jongware]

    Unintended Repeating of GREP Style

    kmc27 Level 1

      I am using this GREP style

       

      ^.+?\.(?=\s\u)

       

      to identify text in the beginning of a paragraph and then to apply a specific character style to that text. The GREP formatting needs to happen only once at the beginning of the InDesign copy block. Where I am running into trouble is when I edit the text using a hard or soft return, the GREP style is repeated, which is not what I want to happen. I need to be able to put in returns without having the GREP style repeat itelf. Here is a screen shot of an example.

       

      Hightlighting the GREP style from within the Paragraph Style editor and then clicking the flyout menu button to the right of the code brings up a menu that includes options for controlling repeating, such as "Zero or One Time", but even when that is selected, the GREP style is repeated.

       

      Is there a way to apply the GREP style just once per InDesign story, so that any subsequent hard or soft returns do not invoke the GREP style a second time?

        • 1. Re: Unintended Repeating of GREP Style
          Jump_Over Level 5

          Hi,

           

          Since GREP style is a paragraph property - each paragraph is a separate order for GREP activity, I guess. That's why using hard return leads you to duplicate GREP style definitions.

           

          You can use GREP "to the end of story" wildcard inside find_change feature, not inside paragraph definition.

           

          But did you try regular nested style "first sentence" option? Soft return shouldn't be a problem here.

           

          rgds

          • 2. Re: Unintended Repeating of GREP Style
            kmc27 Level 1

            I was using a regular nested style "first sentence" option, but it wasn't sufficient in those cases where the sentence contained a description that contained two periods such as .5 t.w. carat. That's why I moved on to a GREP style.

             

            I understand the GREP style being repeated when a hard return is used, but why is it repeated when a soft return is used. The soft return isn't creating a new paragraph.

            • 3. Re: Unintended Repeating of GREP Style
              Jump_Over Level 5

              Hm,

               

              To tell  you the true, it works on my side with soft returns (I mean GREP)...

               

              rgds

              • 4. Re: Unintended Repeating of GREP Style
                [Jongware] Most Valuable Participant

                kmc27 wrote:

                 

                I was using a regular nested style "first sentence" option, but it wasn't sufficient in those cases where the sentence contained a description that contained two periods such as .5 t.w. carat. That's why I moved on to a GREP style.

                 

                I understand the GREP style being repeated when a hard return is used, but why is it repeated when a soft return is used. The soft return isn't creating a new paragraph.

                 

                You might call it "an interpretation". Does a soft return create "a new paragraph"? Well, yes and no. Soft returns are abused to insert line breaks into running text, and I'm pretty sure that's not the intended usage. Something like a First Line Indent is not honored with a soft line break.

                 

                I think the explanation is straightforward, though. GREP, in general, is not aware of the difference between a hard return (0x0D) and a soft return (0x0A). That behavior is by design, because different OS platforms save their 'plain text' with different line endings, and GREP's original function was to search in plain text only. It's imaginable the behavior you are seeing is a side-effect of Adobe's programmers not realizing this (they didn't actually "write" the GREP code for InDesign, they downloaded it from somewhere).

                 

                That said: one of the more peculiar things of a GREP style that must be "fully intentional" is that they only work inside an entire paragraph. Therefore, you cannot do something like "test the previous paragraph for x" -- ID flatly refuses to straddle the hard return. But: the paragraph it's applied to is a proper InDesign paragraph, from hard return to hard return, and this mechanism ignores GREP's "let's include the soft return". So, weirdly, strangely, and oddly enough, this does work:

                 

                ^(?<!\n).+?\.(?=\s\u)

                 

                as "before" the start of an InDesign paragraph there never can be a soft return (there is always "nothing" before it), but "before" the start of a GREP paragraph, there is something -- a soft return!

                • 5. Re: Unintended Repeating of GREP Style
                  kmc27 Level 1

                  Jongware

                   

                  Thanks for the explanation and for getting this working for me. The use of nested styles - "applying a paragraph style through 1 period" was not a perfect solution for identifying the first sentence due to the fact that some of the fist sentences included intials followed by periods, thus resulting in the wrong text being identified.

                   

                  The regular expression got past the nested style limitation, but then the fact that the pattern was repeated after a soft return was an unexpected nusiance. I'm not sure how Jump Over got it to work as I originally intended. On my and several other computers, the GREP formatting (bolding of the first sentence) was repeated after soft returns.

                   

                  I'm trying to learn from the code you provided. Is (?<!\n) telling the script to ignore text that is preceded by a new line?

                  • 6. Re: Unintended Repeating of GREP Style
                    [Jongware] Most Valuable Participant

                    kmc27 wrote:

                     

                    .. I'm trying to learn from the code you provided. Is (?<!\n) telling the script to ignore text that is preceded by a new line?

                     

                    Something like that, yes. This is what's known as a negative lookbehind -- look back "from the cursor position", and the supplied text should not be there. If it is there, the match fails immediately, and ID goes on to find and check a next occurrence.