claidheamdanns

Never mind @dominik. I found it. Here it is, if anyone else is looking for it.
 

I agree. I was trying to set up in my Affinity palettes to match my InDesign workspace, and couldn't find the Links palette. The Resource Manager is nice, but really needs to be a dockable palette, since I use it every single job, throughout the job.
Ditto on the Gradient Map popup.

Hobbyists will more likely not use GREP styles, nor would they possibly understand how to use one. I regularly have documents that rely on "massaging" database generated text that comes in plain text. Back in my InDesign days I didn't even need to think about editing the document to massage the text. Now for EVERY document I get this way (monthly) I have to do five Find/Replace operations, manually typing in the grep commands for each one. It is a huge time waster! I always have to carefully check to see that I have typed in the expression correctly. The end result is the same as when I did things in InDesign, but my productivity has gone down big time.
Affinity is definitely the logical replacement for InDesign. Do I regret switching to Affinity? Not at all!!! I love using Affinity. I just wish that grep styles would be implemented, seeing that the first part of the issue is already implemented - mainly GREP. PLEASE PLEASE... Serif... Go the rest of the way and implement GREP styles. Those of us who would benefit from this improvement will rise up and call you blessed!
 

Hi,
when I open an image box, I have four possibilities how the image behaves in this image box. That's very good so far! 
But I don't have the possibility to adjust the image box automatically to the proportions of the image. If I choose "scale to min fit" or "None", I can manually adjust the frame to the image, but this is annoying, and my hand is usually not calm enough to see a very narrow border again and again. An automatism would be great!
Thanks and br
Martin

I stumbled across an interesting observation recently in this regard that leads me to believe that a multiline composer works together with and is possibly even necessary for the ragged balance lines concept to work. Consider the example in this screenshot from Indesign:

Here you see two text boxes that are identical in every respect (that is, I duplicated them) with the sole exception that the box on the right has balance ragged lines activated. Compare the first line of the paragraph in both versions: in order to achieve the more balanced look in the specimen on the right, the program had to break lines earlier than necessary even as far back as the very first line in the paragraph. That is, it had to calculate line breaking for the whole paragraph rather than a line-by-line fashion that Publisher uses as its only option.
That is what leads me to the conclusion that balanced ragged lines is an extension of the concept of a multiline composer. I do not know whether this is inherently so, but it does seem to be the case at least in InDesign, as evidenced by the fact that the balance ragged lines setting does nothing at all if "Adobe Single Line Composer" is activated rather than the "Adobe Paragraph Composer."
This does not give me much hope, as so far Serif has not seemed interested in a multiline composer as far as their public comments are concerned–but I do realize and accept that they are not in the habit of publicly commenting on desired features until they show up in beta.

I would also like to suggest the "Balance ragged lines" feature. This is something I use in almost every publication I produce.
For those who do not know what I am talking about, this is a feature from InDesign. Imagine a center-aligned heading that is just a bit too long to fit on a single line. Normally, this would mean only the last word or so would get bumped to the next line. Such as this:
The quick brown fox jumped over the lazy
dog
Balance ragged lines would instead display the following, without any need for forcing a line break:
The quick brown fox jumped
over the lazy dog

Just a question, is there anyway to turn off the scrubby zoom so that it behaves like the previous zoom tool?

You can already do a one-time search/replace with regular expressions (being mislabeled as "grep" expressions in this and various other threads), but as far as dynamically applying styles as text is entered and modified, there are performance ramifications involved as well as a possible concern with ambiguity which can both make this more complex than you seem to think.
Consider an expression such as "begin.*?end " (note the space at the end) which has caused a large block of text, maybe even several pages long, to have a conditional style applied to it.  Now go somewhere in the middle of this large block of text and type the word "ending" just before an existing space character.  
Each character that you type would require Publisher to at least partially  re-evaluate the expression against the modified text in order to determine if it still matches the expression.  Given the general nature of regular expressions, this is a non-trivial check for a typical engine that was designed to do one-off searching as is possible for the Find and Replace panel: there are so many different ways that an expression could evaluate (particularly with optional parts within the expressions) that the amount of work involved could grind Publisher to a halt, so it may be that Serif actually needs to rewrite the entire regular expression engine to be able to do this efficiently and correctly, so that it can dynamically adapt to small changes within long blocks of text (in the absence of which this feature would be less interesting) and not grind to a near-halt.  
Once you hit the "d", with the space character after it, the match changes the style: everything after the space character needs to be restyled and redrawn as no longer being part of the conditional style, which might cause text to re-flow if the size or font changes (for example).
Then when you hit the "i", the word no longer marks the end of the matched block, so the text after the space needs to be restyled again back to what it was in the first place, again possibly triggering a large amount of text to be redrawn, along with a possible re-flow.
In entering this one word there would have been two consecutive characters which changed the end of the matched region back and forth and caused adjustments to a large block of text.
 
Now consider that a second such style is present in the same document (meaning they BOTH need to be similarly evaluated with each character typed into the text flow).  Let's use "abc.*?xyz" for this one.  If the "xyz" is present in the document at some point after the "end " which ends the large block of text mentioned above, but "abc" was not originally present within that block, then go somewhere in the middle of that block of text and add "abc".  You now have two overlapping conditional styles: when the "c" was typed in "abc", Publisher now needs to apply a second style to the text, covering a region which overlaps the end of the block with the existing conditional style.  If there is a conflict between the two styles (ex. one makes text red and one makes it blue), Publisher also needs to figure out which one "wins" between them for the text within the overlapped region.  This would not be difficult to work out on its own, but when combined with the need to make these changes dynamically while typing where the detection of the changes is already complex can take an already difficult task and make it even harder and even more likely to not work as intended for various cases.
 
In short, it may seem simple on the surface, but when it comes down to actually coding a feature like this - there is a lot more that needs to happen under the hood than you seem to realize.

Same here, I really need GREP Styles - Thanks 👍

I couldn't agree more with all the grep-style proponents. The nice thing about a grep style is that it is non-destructive to the text. Using grep on its own forces the text itself to be modified. If I want to change the style of a body of text, I have to start from scratch if I use a replacement function in grep. When using a grep style the text remains unchanged.
I do a lot of text importing from a database that is not in rich text format. For example something in bold looks like "This is in |bold| today." would become " This is in bold today." Back in InDesign, the text would look like "This is in |bold| today." but the grep style would change the looks. Remove the style and you would see the underlying text with the "|"'s in it. However in Affinity Publisher, once you execute a grep find\replace the underlying bold command ("|") is gone forever.
Grep styles would be an answer to my prayers!!!

Ah darn, this is a major blocker for me. Using inDesign has become prohibitively expensive but my projects all involve data merging blocks of text with mixed fonts (for symbols and such). I was finding Affinity Publisher so much more intuitive and user friendly but, if I cannot mix my fonts on data merging, I cannot continue to use this product. That's a real shame. I think that leaves me up a creek without a paddle

+1, need GREP.

+1 for GREP style

Hey Goeff777, thank you for your answer. i already now these settings. There it is possible to upload and save templates. My question referred to whether there is already a template that contains most of the Photoshop shortcuts. Then I only need to upload them.

Has anyone found a file of shortcuts that add all the missing Photoshop shortcuts, or modify existing shortcuts to be the same as Photoshop?
 

You're preachin' to the choir here. Just hope Affinity joins the choir! 

Is it possible to have a selected area and crop to selected pixels?

I beg to differ...
When I create a greyscale image in photoshop it is exported as greyscale tif/jpg etc. It is not converted to rgb.
Single colour printing is as old as the printing press and it is bizarre that Publisher can't output a single colour file consistently.

Yes, thank you for understanding and clarifying my point. What is the point of having a grayscale profile if it gets converted to rgb or cmyk? If I wanted colour I'd choose a colour profile.
Perhaps the "big announcement" coming tomorrow will fix some of these basic 'duh' items. The other is slug area export for this like fold, die-cut and knife marks... (we wait in hope that Publisher might actually equal InDesign in functionality).

@claidheamdanns I fully agree with your point of view. Without GREP styles I still miss a crucial tool. Whenever a project requires more then basic typography, like kerning punctiation or other microadjustments, I am lost without Indesign.
I was told that the staff has it on their list, but that was two years ago.

I keep coming back to this topic, hoping to see movement on it. At work we still use Adobe, but at home I don’t. 

At work, I use GREP in styles Every. Single. Day. 
Many of my documents at home had GREP in styles built into them, back in the days when I used Adobe. All this was lost, coming to Affinity. Was moving to Affinity the right choice? Absolutely. Do I still wish GREP was implemented in styles. Absolutely. 

Any time you have repetitive, predictable, pattern-based formatting, that is a job for GREP in styles. Set and forget. Let the program do the mundane, allowing the human to focus on the parts the program cannot. 

I keep coming back to this topic, hoping to see movement on it. At work we still use Adobe, but at home I don’t. 

At work, I use GREP in styles Every. Single. Day. 
Many of my documents at home had GREP in styles built into them, back in the days when I used Adobe. All this was lost, coming to Affinity. Was moving to Affinity the right choice? Absolutely. Do I still wish GREP was implemented in styles. Absolutely. 

Any time you have repetitive, predictable, pattern-based formatting, that is a job for GREP in styles. Set and forget. Let the program do the mundane, allowing the human to focus on the parts the program cannot. 

Thanks, I was having the same problem and baseline grid was turn on for every new text frame I'd created. 
I absolutely hate baseline grid. I've never intentionally used it in my 22 years of Prepress work. Any way that this can be turn off permanently in the app? A default OFF instead of default ON?
Thanks!

This would certainly answer some of the things that I use GREP for,  but there is still a vast sea of application out there which it doesn't cover. One small example from a book that we printed from InDesign, which I then pulled into AP for testing.
Example: I have a "In Memorium" list from a club, and under each person's name, where applicable, it gives their official title in the club, if they held an office, along with the year served.
John Q. Public
Director — 2012
The paragraph style has after space to separate between the names, and the leading keeps the title/year up close to the person's name, via leading and a soft return.
I used GREP embedded in the Paragraph Style to look for every place where there is a soft return, followed by any text that ends with a 4-digit date, and then a paragraph return. To this found text, it applies a character style making it smaller and italic (similar to the John Q. Public example above). 
The beauty of this is that the entire list can be kept in one paragraph style, and the titles of each person, if applicable, get automatically formatted. Each quarter when we update this club directory, we can just drop in the new names, if any, and they automatically adapt to the same formatting rules. Kind of "set it, and forget it."
This is just one small example. I do massive documents where GREP is invaluable for looking for patterns in the text and auto formatting things that would take a lot of extra time/effort, and allowing me to focus more on all the other things.
——
Update: this particular example I gave here, I did just now figure a way to accomplish the same thing, by setting the title/date styling as the styling for the paragraph, and then applying an initial word character styling to everything before the name title/date. A different way of thinking of it, but it did work.

+1 for GREP in styles. Thanks