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

Thanks for swift response - that worked for my example but sometimes my phone numbers are a more complicated format and don't follow the same string pattern eg Tel: +123 4567 45566 Tel: 12348 56612 ext 566 Tel: 12 5667 I tried extending your GREP as (Tel:)\s(\S+)\s(\S+)\s(\S+)\s(\S+) and replaced with \1nonBreakingSpace\2nonBreakingSpace\3nonBreakingSpace\4nonBreakingSpace\5 but it only worked for the second example with the correct amount of groups

I need to find a regular expression to find spaces in a telephone number so I can replace with non-breaking spaces. The following GREP works ok on regexr.com to find the two spaces in "Tel: 123 4567" (?<=Tel:)\x20|(?<=Tel:\x20\d+)\x20 but in Affinity Publisher it says it's an "invalid regular expression" Any ideas what I should substitute?

That makes sense. Thanks for your help

Thanks Walt. I’m only just getting to grips with Regex but I was thinking along the lines of finding any new line that wasn’t preceded by a space or return. In theory this should find any broken strings of characters Rob PS I take your point about hyperlinking all URLs but it’s not an issue with my workflow as the PDF is uploaded to ISSUU to be read as an online flip book. Single line URLs are detected always

Hi - I'm working on a long document in Publisher with some URLs that go over 2-3 lines. Is there a way to find these URLs with Regex so I can manually insert a hyperlink to ensure they are detected in Acrobat? Thanks