RobC

Both yours and @Old Bruce's solutions work a treat - it's greatly appreciated - I didn't know this end of line character and I think it will help me with another GREP problem that I've posted about before (and had stopped me moving from Publisher 1 to Publisher 2)

Thanks - I’ll try this later. GREP saves me so much time but I still always struggle to build the patterns so this will be very useful

Thanks. Away from desk now but will check later

Here's an example of what I'm trying to solve - I want to delete any hyphen with nothing after it (so bananas and damsons) - +\r picks up bananas but not damsons

I have a GREP find and replace set up to format certain ends of lines. I use \r or \n which is working fine on the whole but it's not picking up the last line as it is the section end (§)and not a new line . I can't find a GREP character that includes this despite looking on various GREP sites. Any ideas?

The docx to doc workaround didn't help but it works fine if I open the doc in LibreOffice and then paste to Publisher. My version of Word is 16.66.1 from 2022 and I can't update it due to my MacOS so maybe that's the issue. I'll stick with LibreOffice

OK - is there any reason why it would display correctly in Word but not in Publisher?

ā ē š ī ž.docx

I'm using a font called Raleway, supplied by a client. Publisher 1.10.8 and Mac OS 10.15.7

When I'm cutting and pasting from Word to Publisher, certain accented letters are being replaced by black squares and incorrect letters. eg ā ē š ī . I'm using the same font in both and can paste correctly into other apps like TextEdit etc. These characters weren't showing in the Glyph Browser until I added the Latvian keyboard so I can now correct them (if I spot the mistakes in a large document) but I just want to understand why they exist in Word and others (without adding Latvian keyboard) but not in Publisher

Got you - I'm just trying to avoid keystrokes as I have to run approx 20 GREPS (that I cut and paste from TextEdit) Thanks for your efforts, but I guess I'll stick with Publisher 1 until Affinity introduce saved searches or undo this 'enhancement'

Thanks for your response but I may have misunderstood. Typing \\¶ or \¶ in the find box doesn't seem find the para breaks. It's strange that I can copy \t from TextEdit and it finds tabs but \n doesn't find para breaks. As you say, I wouldn't want to have to select para break from the pull down menu each time Shame that you can't save searches as that would be so much easier (I see it's a frequently requested feature)

I have a workflow that relies heavily on GREP Find & replace, and as there is no way to save the searches (I don't think?) I just cut and paste my set of searches from a notes app. This has been working fine on Affinity 1 but I'm trying to move to Affinity 2. If I copy \n (special character for para return) it now pastes it as \\n as I assume its replacing \ for the special character for \ which is \\ . I realise that I could actually just type a para return on my notes app to copy but the disadvantage of this for me is that it won't be visible (so could be missed) and that it will also make the searches appear over multiple lines in the notes app Can anyone suggest another workaround Rob

Hi anto this works really well for me so your time is greatly appreciated - I'll make sure I spend some time trying to understand the how it works Rob

Thanks, John When I try this it picks up some of the digits as well - I think I'm going to go with the following two GREPs and just keep an eye for the exceptions (?<=Tel:)\s (?<=\d)\s(?=\d) Rob