Jump to content

Recommended Posts

Posted

The start of line and end of line characters do not seem to work with paragraph return. Here's a simple test:

  1. Make a new document and a new text frame
  2. Add a few paragraph breaks (return) in the text frame
  3. Search for this regex:
^\r

No results are found.

 

Posted
37 minutes ago, garrettm30 said:

The start of line and end of line characters do not seem to work with paragraph return. Here's a simple test:

  1. Make a new document and a new text frame
  2. Add a few paragraph breaks (return) in the text frame
  3. Search for this regex:

^\r

No results are found.

 

I will get the very first which makes me think that the ^ represents the start of the document and not the start of the line. If I add anything other than a paragraph at the beginning I get no results.

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted
5 minutes ago, Old Bruce said:

I will get the very first

Oops, you're right. I do get the very first too, but not others.

5 minutes ago, Old Bruce said:

which makes me think that the ^ represents the start of the document and not the start of the line.

But this does not seem to be true with other searches not including a new paragraph. For me, I do get results I expect with other searches using ^. For example:

23579712_ScreenShot2019-07-02at2_56_48PM.png.6ef57b8c3c1151fafbfe5c913d7f6cbd.png

In that case, it is clear that ^ means the start of a line rather than start of the document.

 

Posted

^ definitely matches the beginning of a non-empty paragraph or the beginning of a new line caused by a line-break within a paragraph.

It should match the beginning of an empty paragraph, too, in my opinion.

(My testing is on Windows, by the way, so this issue is not Mac-specific.)

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted

MacOS is a UNIX platform and as such does not use a carriage return character (which \r is *supposed* to represent in a regex) as part of a line ending sequence - only a line feed (\n) is used, so in theory, this expression should never work on a Mac.

However, if the Affinity apps are adding a \r character (or substituting one) for consistency across platforms or some other such thing, then this probably should be working.

 

Otherwise, have you tried this expression instead:

^$

 

I don't have it in front of me right now to test, but it works in at least one text editor that I just tested on, and it should be the more technically correct way of finding an empty line (as well as being independent of the line termination sequence being used on the platform).

Posted
51 minutes ago, fde101 said:

MacOS is a UNIX platform and as such does not use a carriage return character (which \r is *supposed* to represent in a regex) as part of a line ending sequence - only a line feed (\n) is used, so in theory, this expression should never work on a Mac.

Some simple experimentation should demonstrate whether \r is a paragraph break in Publisher :)

55 minutes ago, fde101 said:

Otherwise, have you tried this expression instead:


^$

 

I don't have it in front of me right now to test, but it works in at least one text editor that I just tested on, and it should be the more technically correct way of finding an empty line (as well as being independent of the line termination sequence being used on the platform). 

Interesting suggestion. ^$ behaves oddly in Publisher, in my experience. Even $ behaves in ways I do not yet understand.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted
17 hours ago, garrettm30 said:

^\r

No results are found.

To me on mac it finds only empty paragraphs but only IF they are either at the beginning OR after a line break.

r.jpg.7fc46d712aeb97c0f5152c20b82e3394.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Posted
2 hours ago, fde101 said:

MacOS is a UNIX platform and as such does not use a carriage return character (which \r is *supposed* to represent in a regex) as part of a line ending sequence - only a line feed (\n) is used, so in theory, this expression should never work on a Mac.

That's a good observation to bring up the difference of line endings. I don't think it is true that "this expression should never work on a Mac." For one thing, it does in fact work in InDesign on a Mac. For another, the line ending convention is not an essential requirement of all files for third party apps, and files can be accepted with different kind of line endings, depending on the capabilities of the app. In the coding text editors for example, we are usually given the choice of all kinds of line endings, and the Mac can handle them all just fine. Coda 2 on Mac, for example:

2021109635_ScreenShot2019-07-03at8_32_56AM.thumb.png.24024fe48392900b50c1d3332419e7b0.png

I think the "Mac Line Endings (CR)" in the screenshot refers to classic pre OS 10 endings, but obviously the Mac can read those legacy files.

I also don't think that the problem is that \r does match paragraph breaks on a Mac for two reasons: First, \r+ will successfully find a series of paragraph breaks in Publisher, showing that \r is recognized. Second, if instead of ^\r one uses the Serif-supplied version for paragraph return (don't know how to describe it, so see this screenshot below) then the search still fails in the same way.

1763315007_ScreenShot2019-07-03at8_41_42AM.png.5e06bf2e36367cff5de4c138fab5f3e7.png

Nevertheless, the issue of line ending handling may very well be where the problem lies. I think it is the best guess so far.

Searching for ^$ doesn't work right either.

@thomaso Those are some interesting tests. Thanks.

 

Posted
1 hour ago, garrettm30 said:

Searching for ^$ doesn't work right either.

Doesn't find any – or not as expected? To me both ^$ and ^\r show quit similar results with this difference:  ^$ finds the spot before a break.

2070371140_FR.jpg.ea4b60a1f287939f3a77f5f1ed7750e0.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Posted
6 minutes ago, thomaso said:

Doesn't find any – or not as expected? To me both ^$ and ^\r show quit similar results with this difference:  ^$ finds the spot before a break.

Not as expected. As you say, ^\r and ^$ are very similar. If I have a text frame with nothing but a series of paragraph breaks, ^\r will find just the first, while ^$ will also find only one result, but nothing is highlighted, so I can't tell which line it has found.

… Apparently it also is finding just the first, which I was able to determine by using replace and seeing where the replacement went.

Posted

Publisher uses Paragraph Separator (PS) the unicode 0x2029.

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted
57 minutes ago, Old Bruce said:

Publisher uses Paragraph Separator (PS) the unicode 0x2029.

But for regex purposes, \r works, or inserting a Paragraph Break from the magnifying glass pulldown works. Users are not expected to know about 0x2029; that's an internal detail.

 

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted
3 minutes ago, walt.farrell said:

Users are not expected to know about 0x2029; that's an internal detail.

Been bit on the exterior by that internal detail.

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted
1 minute ago, Old Bruce said:

Been bit on the exterior by that internal detail.

Oh? How so, to satisfy curious minds.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted

Copy text from Publisher doc paste into a text editor. One long long long single 'paragraph'

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted
2 minutes ago, Old Bruce said:

Copy text from Publisher doc paste into a text editor. One long long long single 'paragraph'

Thanks. Should be unrelated to the current discussion (unless it somehow contributes to a Publisher regex bug), but interesting to know.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted
Just now, walt.farrell said:

Thanks. Should be unrelated to the current discussion, but interesting to know.

0x2029 is not 0x000D or 0x000A. Serif is using unicode (I guess in the hope of getting some support for non-latin characters and RtL scripts) and if the regex ^\n isn't working perhaps it is because ....

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Posted

I'm accustomed to using \n for forced line breaks, but it does seem like \n and \r are equivalent in Publisher. I see I can search for forced line breaks with the dropdown, but I don't know what to type to search for them. It would be helpful if Serif would fill out the keyboard equivalents in the dropdown as they do for \t.

Posted
16 minutes ago, Old Bruce said:

0x2029 is not 0x000D or 0x000A. Serif is using unicode (I guess in the hope of getting some support for non-latin characters and RtL scripts) and if the regex ^\n isn't working perhaps it is because ....

Perhaps, but they know how they've encoded the text, and \r will normally (even in Publisher regex searches) match their paragraph breaks. I don't know how they transform the text (or the regex) before running the search. I only know that it usually works :)

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted
5 minutes ago, garrettm30 said:

I'm accustomed to using \n for forced line breaks, but it does seem like \n and \r are equivalent in Publisher. I see I can search for forced line breaks with the dropdown, but I don't know what to type to search for them. It would be helpful if Serif would fill out the keyboard equivalents in the dropdown as they do for \t.

I agree.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

  • 3 months later...
Posted
On 10/30/2019 at 8:29 AM, AdamW said:

Find and Replace
Fixes for skipping occurrences when replacing
Tidied up finding around end of text

In the notes for beta 1.8.0.499, I thought "Tidied up finding around end of text" might have some relevance to our discussion here on line endings and this particular regex search. I have tested, and this issue is not resolved. I assume the notes refer to a different issue.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.