garrettm30 Posted July 2, 2019 Posted July 2, 2019 The start of line and end of line characters do not seem to work with paragraph return. Here's a simple test: Make a new document and a new text frame Add a few paragraph breaks (return) in the text frame Search for this regex: ^\r No results are found. Quote
Old Bruce Posted July 2, 2019 Posted July 2, 2019 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: Make a new document and a new text frame Add a few paragraph breaks (return) in the text frame 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. garrettm30 1 Quote 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.
garrettm30 Posted July 2, 2019 Author Posted July 2, 2019 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: In that case, it is clear that ^ means the start of a line rather than start of the document. Quote
walt.farrell Posted July 3, 2019 Posted July 3, 2019 ^ 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.) Quote -- 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
fde101 Posted July 3, 2019 Posted July 3, 2019 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). Quote
walt.farrell Posted July 3, 2019 Posted July 3, 2019 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. Quote -- 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
thomaso Posted July 3, 2019 Posted July 3, 2019 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. Quote macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1
garrettm30 Posted July 3, 2019 Author Posted July 3, 2019 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: 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. 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. Quote
thomaso Posted July 3, 2019 Posted July 3, 2019 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. Quote macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1
garrettm30 Posted July 3, 2019 Author Posted July 3, 2019 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. Quote
Old Bruce Posted July 3, 2019 Posted July 3, 2019 Publisher uses Paragraph Separator (PS) the unicode 0x2029. Quote 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.
walt.farrell Posted July 3, 2019 Posted July 3, 2019 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. Quote -- 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
Old Bruce Posted July 3, 2019 Posted July 3, 2019 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. Quote 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.
walt.farrell Posted July 3, 2019 Posted July 3, 2019 1 minute ago, Old Bruce said: Been bit on the exterior by that internal detail. Oh? How so, to satisfy curious minds. Quote -- 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
Old Bruce Posted July 3, 2019 Posted July 3, 2019 Copy text from Publisher doc paste into a text editor. One long long long single 'paragraph' Quote 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.
walt.farrell Posted July 3, 2019 Posted July 3, 2019 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. Quote -- 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
Old Bruce Posted July 3, 2019 Posted July 3, 2019 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 .... Quote 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.
garrettm30 Posted July 3, 2019 Author Posted July 3, 2019 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. Quote
walt.farrell Posted July 3, 2019 Posted July 3, 2019 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 Quote -- 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
walt.farrell Posted July 3, 2019 Posted July 3, 2019 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. Quote -- 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
garrettm30 Posted November 1, 2019 Author Posted November 1, 2019 On 10/30/2019 at 8:29 AM, AdamW said: Find and Replace Fixes for skipping occurrences when replacingTidied 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. Quote
Recommended Posts
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.