garrettm30

I’m so totally stoked about this beta. I have spent a couple hours poking around, and I can say that this beta is further along than I expected. I have high hopes that this will in time replace Indesign for us (a small publisher), and it looks well on track. Among several features that wowed right away and other "missing features" that I can work around, the one thing that stood out for me is the lack of GREP searches. In Indesign, I have a small series of GREP searches that I have saved over the past years, and I run nearly everything through them. A couple minutes on a typical file, and I have made several hundred changes. When I work on a book, the changes are in the thousands. (Note: I publish in French, and French typography relies heavily on non-breaking spaces; these GREP searches help me rapidly put them where they ought to go.) While you're there: being able to save the searches as presets would be ideal. And as not everyone is familiar with GREP, a few pre-saved searches would help provide them immediate use: remove multiple spaces, remove trailing space, etc.

Are footnotes and endnotes currently possible (besides manually creating them, of course)? I haven't found them so far. If not, this is a feature that I think would be widely used. I suspect it may take some time to get right if it is not yet under development, so I would understand if it is not a day-1 feature.

It's actually a Unix command line utility, used for searching files by regular expressions.

I would use this feature if available. I usually do have a very small amount of glyph scaling in my justification. Incidentally, the publishing work I do is also in French. The extra nonbreaking spaces that French has as compared to English means justification has to work a little harder to look good.

I think the suggestion is to allow it to duplicate immediately without the first click to select the object.

I'm sorry; I have a document with that very configuration, but so far I have never experienced that kind of crash. I am using an iMac from 2011 with High Sierra.

I can't seem to reproduce a crash, but I am not exactly sure what kind of document you are setting up. So you have a basic document that you can share where this behavior occurs?

Thank you, fellow user @PadifyWales. As we are busy reporting bugs and things we wish AP would do differently, it is helpful to occasionally consider the many good things it does well.

I have tried your workflow, and of course a V is entered as text as a result. Otherwise, how else could one type a v as text? As to using command-V, that is universally the paste command. What you want to do is press escape then V. Or if text is selected, press escape twice, then V. This latter point I only just discovered and commented on in another post. My opinion is that the need to press escape twice when text is selected is needless and error-prone.

Interesting point. Looks like alt-drag (opt-drag on Mac) with nothing selected simply brings up the selection rectangle. I cannot tell whether opt-drag in this context has any purpose, in contrast to shift-drag, which adds to a selection, shift-opt-drag removes from selection, and control-drag changes selection behavior. Does anyone know if opt-drag when nothing is selected has some particular meaning? If not, it seems opt-drag could well be used to duplicate whether or not something is selected.

It might be worth noting that you may have to press escape more than once. For example, if you have some selected text inside a text box, pressing escape once deselects the text and places the insertion point at the end of the text that was selected; a second time removes the insertion point, but still has the text frame selected; and a third time deselects the text frame entirely. Thank you @kdog3682, as your question has surfaced an area that in my opinion could be improved. My preference would be to remove the behavior of the first escape. I do not see any reason why pressing escape when there is text selected should then move the insertion point to the right of the selected text. If I actually want this behavior, then pressing the right arrow will do just that. On the other hand, removing that behavior can reduce user errors. Consider the following scenario: the focus is currently inside a text frame (in other words, the text frame is accepting keyboard input as text) and you want to switch to another tool. To do this with a keyboard shortcut, you need to first press escape, and then the keyboard shortcut, such as the V for the move tool. But if you have text selected, you must press escape twice before pressing V; otherwise, you end up just typing a single V somewhere in your text, and you might not even notice it. In this case, one must always consider whether text is selected (which not even be currently in view) to know how many times escape is necessary. Removing the behavior would remove no functionality, as one can accomplish the same with the right arrow if that is what one intends to do.

Thank you, @Old Bruce for confirming, and @walt.farrell for letting me know about the similar report in the Windows section. I never look in that sub-forum.

I am trying to search by format (not by style), specifically, find all text that is italic. It always returns <No results found>. I have tried searching by "Italic: On" or even the font family and specific font traits (Ex: Font family: Arial: Font trait: Italic). Nothing. If someone wants to confirm, here is a simple prepared file where I have just inserted filler text, left every thing default except selecting a few words and changing them to italic (by just clicking the italic button in the context bar). Are you able to get results by searching for italic text? search italics test.afpub I am testing on Mac OS 10.13.6, and I tried both AP betas 249 and 257. I have tried searching with and without regex. With empty search string, or with regex .+

This is a feature that I also hope to see in Publisher at some point. I use it perhaps in about 20% of my documents. Maybe it can’t be added right away (they can’t do everything at once), but it would be good to know it's on the roadmap.

I noticed this too (now beta 257), and I also thought it was distracting. However, strictly speaking, it is not just with the Show Text Flow enabled. If you turn that off, then select a text frame, that particular text frame will display the same flashing behavior when scrolling. It is much more noticeable when you turn on Show Text Flow because now every frame is outlined as a currently selected frame, so there is a lot of flashing. Furthermore, for some reason, the outlines of some text frames do not show up at all when not selected if Show Text Flow is not enabled, but they do show up when Show Text Flow is activated. In this picture, Show Text Flow is enabled, but no text frame is currently selected: In this picture, Show Text Flow is disabled, and no text frame is currently selected: There are much fewer text frame outlines visible when Show Text Flow is disabled, and those that do show up do not flicker in and out on scroll. In this mode, only a selected frame flickers. Every one of the frames that are added by Show Text Flow does flicker. Unless it is a matter of performance, I would prefer that every guide or frame outline that is currently on view will remain visible in scrolling.

I would like to suggest that indents and tabs can optionally take text wraps into account. Here is a quick example to illustrate: Example 1: Example 1 shows current behavior. Please draw your attention to the text wrapping on the right side of the gray rectangle. In the paragraph "Morbi pellenteesque…", notice that the first line indent is calculated based on the location of the text wrap, which is I I desire it. Now look at the numbered list items 1 through 4. They are formatted identically, yet the left indent of the numbered list items 3 and 4 is not respected as it is in numbers 1. and 2. Notice also that the tab spacing between the automatic number and the start of the words is not kept consistent, as it is added as a multiple of the tab value beginning from the text frame margin and not from the wrap. To explain it another way, the starting x position of each line is not calculated consistently. The left indent and tab spacing is calculated relative to the text frame margin, regardless of any text wrap, whereas the the first line indent is calculated relative to the effective margin caused by the text wrap. I would rather that the left indent and the tab position are treated as the first line indent, so that they all take the text wrap into account. Below is a screenshot where I have faked the behavior that I would prefer. Notice number list items 3 and 4 have the same kind of apparent indenting as 1 and 2. It is as though the image causing wrap is temporarily moving the margin. Example 2 This would also be important in cases such as block quotes that are indicated by left indent. Here is an example: Example 3 In this example, please focus on the right column of text. You see that the two paragraphs beginning "In eget sapien" and "Morbi pellentesque" have a left indent, as they are representing two paragraphs in a block quotation. The last paragraph ("Nulla adipiscing") is not, as you can tell by the portion of the paragraph that extends below the gray rectangle. What about the paragraph "Maecenas eu diam"? Is it a third parargraph in the block quotation, or is it the first body paragraph following the end of the quotation? You cannot tell by looking, as the left indent is not respected since the text wrap extends beyond the level of indent. Summary: I suggest that the text wrap should effectively move the margin at each line, and that things like indents and tabs positions are calculated based on that temporary margin location. I suggest this proposal be implemented optionally, either as part of the text wrapping settings or as part of the indent and tab settings.

The idea of compensating us somehow is an interesting suggestion, and I do not think it was bad to ask. However, I think the real reward is that we actually have a voice in the development of this app. I sometimes leave feedback for the "big guys," like Apple, but I usually have the feeling that no one ever sees the feedback who can or want to do anything about it. I do not feel that way at all about the Affinity range of apps and their developers. Bugs really do get addressed, and feature requests often do get implemented. It's easier to warm up to software when we have a line of communication with the people behind it. I believe that (A) getting to use unreleased software months early for free, and (B) getting to leave feedback that is honestly considered and often implemented is plenty reward.

If they allow us to save previous searches (suggested in another thread), then they could supply a few common settings. For any who are not familiar with regex, let me give a few simple examples with some explanation to give you a taste for what it can do. (If you already are familiar with regex, you can just skip the rest of this post. I think I got carried away.) By the way, "regex" is the common shorthand for "regular expressions", which in turn just refers to a kind of search by pattern matching. -------------------------------- Example 1 First, let's say that you have received a story or novel from an author, and it is your job to do the layout. The author has indented nearly every paragraph with tabs or spaces, but you prefer to control indentation with a paragraph style. This means you now need to delete all the tabs or spaces. You could do that one-by-one—and hasten the onset of carpel tunnel. You might be able to do a simple find/replace to replace every tab with nothing at all, if tabs are only used at the beginning of the paragraph and nowhere else. Or you could try something like this regex: ^\s+ That tiny regex pattern will select any space at the start of each paragraph, whether it is a tab, several spaces, or any combination. The ^ indicates that what follows must be at the beginning of the line. The \s counts for any white space such as tab, space, nonbreaking space, etc. The + indicates one or more of the preceding, in other words, as many tabs or spaces as there are at the beginning of the line. To remove those opening spaces, replace them with nothing. That is, leave the replace field empty and press replace all. Every tab or space at the start of a paragraph will be removed. Similarly, $ indicates the end of a line, so you could remove all trailing space at the end of each paragraph by searching for this pattern: \s+$ -------------------------------- Example 2 Next, let's say that the author used a lot of numbered lists, but he manually typed out each number, like this: 1. First item 2. Third 3. Fourth 4. Fifth Maybe you want to change the manual numbering to a paragraph style with automatic numbering. Or maybe you just need to insert an extra item, such as if the author forgot one thing and wants to include it. Here, I purposely made the "mistake" to leave out "Second," and now my numbering is off. To fix it manually, I would have to type the new item and then renumber every item after it. The disadvantage to manual numbering is probably obvious enough that I do not need to do so much explaining. So now you set up a paragraph style with automatic numbering and you are ready to apply it. To select the manual numbering we need to delete, try this regex: ^[0-9]+\.\s+ This will select the "1. ", "2. ", "3. " portions of the first part of each line, and so on. It looks more complicated, but we can start with what we know from the previous example. The ^ indicates the start of a line. Next comes the brackets [ ]. You use this to define any single character you are looking for. For example, [abc] will match either a, b, or c. In our example, we have defined a range by entering 0-9, which is the same as typing [0123456789]. Any one of those characters will count as a match. You can also use ranges like [a-zA-Z] to match every unaccented letter in lowercase and uppercase. [0-9] by itself will match one digit only, so "10. " and above would not match. So we add the plus sign: [0-9]+ will match one or more of the digits 0 through 9. Next we want to match a period, but the period character has a special meaning in regex: it represents any single character. In this case, we want to match an actual period, so we do that by "escaping" the period, which is done by adding backslash before it: \. This tells the computer to match any literal period and not "any single character." You can escape any other characters that have special meaning in the same way. If you were looking for a literal plus sign, you put \+ . For a literal bracket, \[ , etc. Finally, we have a space to search for. The author could have used a tab, a single space, multiple spaces, and he may not have been consistent. No matter, we can handle that with \s+ , which, as we saw earlier, will match one or more of any space character. Now that we are correctly selecting the part that we want to remove (the "1. ", "2. ", etc.), lets do some replacing. Leave the "Replace with" field empty to just delete those manually typed numbers. But don't stop there: you can simultaneously apply the numbered style you want by selecting a replace format or paragraph style. You see, once you have it set up, you can accurately format every numbered list item in an a whole document at the push of a button. -------------------------------- Example 3 Let's say you have a long list of phone numbers in this format: 574-234-1998 930-823-1818 And you want them in this common US format: 1 (574) 234-1998 1 (930) 823-1818 There are several ways to go about it, but I might start with this: ([0-9]+)-([0-9]+)-([0-9]+) We already know from the earlier examples that [0-9]+ will match one or more of any numeral. In this case, you see three of those numeral matches, but they are surrounded by parentheses: ([0-9]+) . Parentheses do two things in regex. First, they group patterns together when things get complex (which is not necessary in this case), kind of like a math equation. Second, they also define "capture groups" that we can reuse later. You will see the benefit of a capture group in a moment. The last thing I have done here is insert a simple hyphen, twice placed between these capture groups of numbers. It is a literal character, meaning it matches an actual hyphen in the text. Our regex pattern will match any string of numbers divided by two hyphens in this format (where x is any number): xxx-xxx-xxxx x-xxx-xx xxxxxxx-x-xxxxx (You see in this case it was not necessary to specify how many digits are in each group. If you had a string like 1-19321332-8, it would also match. If you had such numbers in the text that you did not want to match, you would have to be more specific.) Now, let's replace using this pattern: 1 ($1) $2-$3 We are adding the numeral 1, parentheses, and a couple spaces, but we are also putting back the numbers that were found in the capture groups. $1 refers to whatever match was found between the first set of parentheses. $2 and $3 likewise refer to the matches inside the second and third sets of parentheses. This is what a capture group is and how it can be used. As a variation on this example, maybe you live in a different country, and the the starting and ending format is different. Maybe you are starting with raw numbers from a database, like this: 5742341998 9308231818 And you want this format: 574.234.1998 930.823.1818 Again, no problem. We just need to alter our search and replace patterns a little bit. Search: ([0-9]{3})([0-9]{3})([0-9]{4}) Replace with : $1.$2.$3 I have not changed the search pattern very much: I have taken out the hyphens, and instead of the + to indicate one or more matched character, I have instead used {3} and {4} to specify exactly 3 or 4 matched characters. -------------------------------- Summary I have tested all of these examples in Affinity Publisher, and they do work correctly in the current beta. There are a few more basics I have not covered, but I hope these examples give you an idea of the power of regular expression. I regularly make thousands of corrections in book with a short series searches that are of common use in our material. It takes me about 10-30 seconds to do those thousands of corrections (since I saved the find/replace expressions that I use most). But the value in understanding regex is not simply in having a few saved searches that may or may not match the problem before you; rather, it is in knowing how to build patterns to accomplish what you need. Anytime you have a repetitive task for changing text, find/replace can probably do it for you, and regex is what takes it beyond simple text replacement. When you first start using it, it may take you just as long to figure out a pattern as to just manually make any necessary changes, so the temptation is to stick to what you know. However, the same time spent doing a boring repetitive task could instead be used as an exercise to broaden your skills while accomplishing the same goal. Depending on your interests, you may even enjoy the challenge. Regardless, next time you come across a similar problem, you will be able to apply what you learned, and over time your efficiency will greatly increase. (Did anyone actually make it to the end of my long post? I did indeed get carried away.)

Just to make sure: have you set your search to look for regular expressions? You do this by clicking the gear above and to the right of the find field. In the dropdown menu that pops up when you click the little gear, make sure to check "Regular Expression." I tried the regex that you posted, and I did come up with results. I've posted this before, but my favorite resource for building regex is the website https://regex101.com. It looks pretty technical, but is great for trying out regex before applying it to a whole document. I currently use it both with Indesign and programming, but when I need a new regex that's different from what I have done before, I first go to that website to construct it. I select a large sample of text from my document and place it in the Test String field, which is useful for testing what I have. I also use the Substitution field to test out results for a find/replace operation. The Quick Reference section is very helpful when I can't remember the exact syntax. I don't pay attention to the Explanation or the Match information section. For configuration advice, I recommend you set the regex flags (which is done from the far right of Regular Expression text field) to g (global - shows all matches rather than just one) and m (multiline - allows you to use ^ to indicate start of a paragraph and $ for its end). Once you get the regex to work like you want, you can copy it from the website and paste it into the find field in Affinity Publisher or Indesign. It works great.

Are you sure about lookahead and lookbehind not working? It seems to work for me, for example (?<=\s)[a-zA-Z]+(?=\s) will find words that that have a space character on both sides. Maybe you found a case where it doesn't work? Edit: With further testing, I noticed that the above will find the results, but it will not highlight them in text and it will not replace. Clearly a bug. If I remove the positive lookahead and lookbehind, then the remaining regex behaves as expected.

When you put it as kindly as that, how could I mind? I added a brief note of context to the start of my original comment. In Adobe, I am used to using \r for paragraphs and \n for forced line breaks (not new paragraph). But line ending format is not a settled thing across platforms. Whatever they settle on, the ability to type as an alternative to the drop down would be appreciated. For me, the purpose of the drop down is for reminding me when I can’t remember what to type. Currently it only shows the key for a few items, but I expect that will be filled in. Affinity has a great history of making everything available by keystroke.

[edit for context: this was originally in a feature suggestion thread requesting searches by GREP/regular expressions] I am returning especially to say Thank You for listening to our suggestion. It makes me feel like I have had a small part in the shaping of the app. As this is the first beta iteration of the feature, I have some observations: 1. Ability to save search/replace combos is suggested in another thread, and this was my first thought too. 2. Text size of the two text fields (Find, Replace) as well as the results do not respect app's Font UI Size preference. They stay tiny regardless - hard to make out those tiny regex patterns. 3. Some search characters get replaced with an icon. I think that is helpful. But others that do have icons do not get replaced when one types the equivalent. For example, typing \t gets changed to the tab icon, but \r and \n do not get changed to the new paragraph and line break icons. 4. Is there a way to control the scope of the search (story only, end of the story, document, selection, etc.)? I do use these features. 5. I often make the mistake to come back to an earlier search where I had set formatting conditions. (Yay for search by format and styles by the way! Very useful.) Then my results weren't what I expected. Is there some way to show a small indicator that a style or format condition is set? Maybe a little "reset format" button that only shows up when there is a format set. An additional suggestion that might help people who do not use regex: A coding IDE that I use has, in additional to regex searches, a little placeholder icon (similar to your icons for \t, etc.) that can substitute any text. To illustrate (I hope this shows up), he might be able to change all the HTML paragraphs to headings this way, whilst preserving the attributes: Find: <p❶>❷</p> Replace: <h2❶>❷</h2> I wonder whether that would be of use to some. It can be accomplished easily through regex, so I won't be hurting without it, but it may open up a little power to those who don't yet understand regex. Or would it have less use in this context as compared to programming and markup context?

Thank you for pointing that out. I'll still make the mistake of forgetting that is set, as I often do, but at least now maybe I can find the solution faster since it is staring me in the face.

I assumed that to be a given, but it is right that you pointed it out. Assuming things can be dangerous. Thank you.

I'm very excited to have regular expressions at all. My impression of the power of this program has gone up greatly from this addition. I understand this is just the first beta of the new feature. Like, Seneca's suggestion, adding the ability to save searches/replace combos (particularly regex, though why stop there?) is what I would recommend for the next step of fleshing out this feature. I regularly run through a set of fifteen in almost every document, and having them saved in the app itself makes it easier.