8 Replies Latest reply on Nov 29, 2012 2:23 AM by LukeF11

    Find/replace double paragraph breaks with single breaks causes second para to adopt style of first

    LukeF11

      Am using find / replace to globally find double para breaks and replace with single breaks on a huge INDD which is already styled.

       

      So, find ^p^p replace ^p

       

      This is causing paragraphs to adopt the style of the preceding para.

       

      Eg (excuse mishmash of notation).

      <heading style>This is a heading</heading style>

      <break>

      <break>

      <text style>And this is some text</text style>

       

      is turned into:

       

      <heading style>This is a heading</heading style>

      <break>

      <heading style>And this is some text</heading style>

       

      or possibly:

       

      <heading style>This is a heading

      <break>

      And this is some text</heading style>

       

      It's as though the second break and the start of the text paragraph style which follows immediately are both being picked up and deleted by the 'find'.

       

      Does anyone know a way around this?

       

      thanks!

        • 1. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
          Michael Gianino Level 4

          A few questions:

          1. Is your text locally formatted, or do you use styles?
          2. If you use styles, are they pure, or do you use local overrides on top of the styles?
          3. Does the appearance of your type change, or are you just seeing the + that indicates a local override. I'll expand on that question with a screenshot:

           

          ss.png

          1. The left-most example shows that the first paragraph has a paragraph style called Green applied with no local overrides.
          2. The second paragraph is styled with Red, also with no local overrides, as you can see in the second example.
          3. In the third, I have removed the paragraph return, combining both paragraphs into one. Notice that the type hasn't changed it's appearance.
          4. In the fourth example, I have broken the type back into two paragraphs. The top paragraph is still Green with no local overrides.
          5. The fifth example shows that the second paragraph has retained the Green style it adopted when the paragraphs combined, but with the local override indicated in the styles pallet.

           

          So, are you saying you are getting what I have shown, or is the red type changing to green? I tried a few different ways to make the type change to green, but I couldn't.

           

          One last question: have you tried using the GREP for Multiple Return to Single Return or Remove Trailing White Space instead of ^p^p to ^p?

          • 2. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
            [Jongware] Most Valuable Participant

            This is a know "feature" -- more an artefact of how the process of finding/replacing works. The 'find' text is removed, which causes the paragraphs to run together in the background. Then, the 'replace' text is inserted, but at that moment the harm already has been done. InDesign does not "know" that all you want to do is remove the second hard return, it performs the find-and-replace steps no matter what.

             

            Pre-GREP, this was a horrible thing to do, involving multiple find-and-replaces in sequence. But with GREP, you can search for a hard return that is preceded by a hard return, and remove just the one hard return you found. It does the same thing as the regular find-and-change, but because you only "find" the second hard return in any pair, nothing gets tacked together in inappropriate places.

             

            The Find query is:

             

            (?<=\r)\r

             

            and you can simply replace it with nothing.

             

            (... I just tested Michael's suggestion of the built-in Multiple Return to Single Return query. I wonder why this does work as one logically would expect -- I sure didn't expect it to.)

            • 3. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
              Michael Gianino Level 4

              What I find a little odd is that ^p^p to ^p is working just fine for me. I tried with four different setups:

               

              Screen shot 2012-11-28 at 3.58.54 AM.png

              The two left columns use styles, and the two right columns use no style with local overrides. The blank paragraphs are styled with the green style in the first column and red in the second. They are locally formatted green in the third and red in the fourth. When I run the find/change, I get the correct styles with no local overrides in the first two columns, and all of the paragraph returns in the third and fourth columns have the correct color (I think I'd get at least the wrong color of the paragraph return if I were getting the problem the OP is describing).

              • 4. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
                LukeF11 Level 1

                Michael, thanks very much for taking the time to reply in such detail. I really appreciate it. I was just typing my response when Jongware's comment came in. I'm going to try the GREP that's recommended below first and see how I go. Thanks again.

                • 5. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
                  LukeF11 Level 1

                  Thanks very much for taking the time to reply. I'm now away from the office and unable to access my document, but I will try this when I'm back in tomorrow and let you know how it goes. Thanks again.

                  • 6. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
                    LukeF11 Level 1

                    Also, yes, you're right -- at the moment, away from the office and unable to access my document, I can't recreate the behaviour I described, but it is definitely occurring in the document in question. If you're interested I'll send you a copy. Thanks.

                    • 7. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
                      LukeF11 Level 1

                      Michael, thanks again for your help. I have debugged this issue and isolated it to the fact that the styles were applied by being mapped to XML tags. I should probably have mentioned this earlier, although I didn't imagine it would be an issue. By untagging the elements, the find/replace works fine. Thanks.

                      • 8. Re: Find/replace double paragraph breaks with single breaks causes second para to adopt style of first
                        LukeF11 Level 1

                        Thanks again for the detailed response. It seems that the problem was being caused by the fact the styles had been applied by being mapped to XML tags. Once the elements were untagged, the find/replace worked fine.

                         

                        Which leads me to a follow up question... seeing as you seem to be quite the scripting wizard, could you suggest a solution for either of these?

                         

                        a. a find/replace for removing a return at the start of a text boxes throughout a document

                        b. a find/replace for removing a return which immediate follows and anchored image. If I cut and paste, I get ^a^p but if I replace that with ^a I just get the text string ^a, rather than the anchored image being left, and the return following it being removed. That may not make complete sense, so let me know if it's unclear!

                         

                        There's a whole series of find/replace commands that I'm executing through the sample script that comes with INDD, so packing as many of them into the one operation is a big time saver on this project.

                         

                        Thanks again, and any suggestions gratefully received.