Bryan Rieger

I am locking this thread and will hide it soon. It is NOT what we want to see when users come with a genuine well explained problem.
The interactions in this thread have resulted in a new user leaving the forums. Saying they should be using other settings, or showing V1 is unaffected (the users screenshot shows they are affected in V2) or that "Serif don't care so why say anything" miss the point that there is a simple icon issue that needs addressing in Designer on Mac.
Please do not reply like this, especially not to new users.

Please guys when you add nice new features could you put them in the UI as well as hotkeys. I cannot remember hotkeys so keep not being able to find features I vaguely remember. Even if experts use hotkeys, more casual users find the UI much more discoverable and recallable.
For example: The new features around Alignment in 2.4. The right/left option could easily have been a tick box on the existing Alignment drop-down dialog. Selecting a reference object could have been initiated by a button on the dialog with a prompt to click on the object.

The option+click to pick the key object should really be listed in the help bar across the bottom of the window too.

Hi @Bryan Rieger,
A couple of us here in the office have been able to replicate this with the States panel not showing.  Bit tricky to constantly replicate as it appears to only happen after first updating from 2.3 to 2.4
I've just logged this with the Developers and have left link back to this thread so the Serif Info Bot will update here when this has been resolved  

So, lots of pressure here on Affinity to do this. I just want to comment a bit on something. And please note, this is from the perspective that I personally love variable fonts, have made a bunch of them, and can’t imagine personally paying to license any general design tool today that does not support them decently.
Variable font support is NOT trivial
It isn’t just a matter of enabling something. And no, switching out their back-end font engine for Harfbuzz would not be trivial, and even if it were, that would not solve the problem! Don’t get me wrong, either supporting Harfbuzz or supporting variable fonts in their own engine is a huge amount of work. So many assumptions need to be thrown away, in either case. APIs reworked... agh.
But the other huge deal is: user interface aspects of variable fonts are a huge hassle. The names and contents of axes are completely arbitrary and not known in advance by app developers. What is the most axes a font can have? 64K. Maybe the app has some arbitrary limit lower than that. How fine should the stops be on an axis? How many predefined instances should they support per axis? How do they expose predefined instances for variable fonts and how do they make those interact with user-defined instances? Do they just use sliders for everything? Do they support decimals in axis positions or only whole numbers? Manual input of position coordinates, or only the sliders? And on and on.
Without going into the same detail, impacts on layout are similarly huge.
 
Writing this as former fonts product manager at Adobe (until December 2008), later product management for font management and web fonts at Extensis, and CEO of FontLab
Anyway, I am eager to see this support in Serif’s Affinity products, but please understand it is a heck of a lot of work!
(Is that enough italics and boldface for one post, or should I throw in some more gratuitously here?)

Um, yeah, sure… FWIW if Serif ceased support for iPads I (as a designer and illustrator) wouldn't be using Affinity products at all. I get that some folks really want a DAM, and some folks really want {insert your product/feature request here}, but please let's not minimize others priorities because they don't align with yours. 
At the end of the day it all comes down to Serif's priorities for their products, and their business.
 

I will get random crashes with Hardware Acceleration enabled and Display set to Metal. I turned HW acceleration off and set Display to OpenGL to avoid issues and I find the performance is fine. If you're having problems it is best to keep those off. This might not solve all your problems but it should solve some of them.

Digital Asset Manager.
Not "DPM" = Digital Photo Manager.
Because "DPM" is what y'all talking about when requesting "a Lightroom alternative".
Which, again, would only be of use to a subset of Serif customers.

Hi @Affinity-Inspiration,
I can confirm that Layer States are a function of Affinity on Desktop only at this time, our apologies.
You can check this for any new feature on the 'What's New' page of the Affinity site, as each feature has a Desktop/iPad icon to the right of the title to indicate support, and then an individual app icon (ie Designer and Publisher) when expanding the feature in the list.
I hope this clears things up

Welcome to screaming into the void.
If you're lucky someone from Serif might log the issue for the developers to fix, maybe, at some point in the distant future…
In the meantime, random folks will appear to tell you "you're holding it wrong", or give you a series of complex workarounds, or go on about some arcane reference that has nothing to do with your original post.
Welcome, and enjoy.

Welcome to screaming into the void.
If you're lucky someone from Serif might log the issue for the developers to fix, maybe, at some point in the distant future…
In the meantime, random folks will appear to tell you "you're holding it wrong", or give you a series of complex workarounds, or go on about some arcane reference that has nothing to do with your original post.
Welcome, and enjoy.

Nicely, of course. That's what I've been doing since many, many years, having scanned literally thousands of images. (Definitely since Epson killed its PPC-only scan app compatible with my scanners.)
Other than that, there are quite a few easy workarounds via ImageCapture "Scan To", Automator services, Folder Scripts etc.
My point is that even though the Acquire Image mode in Affinity isn't crucial for my workflow, there's definitely something broken with it, and no one has been able to put their finger on it so far.

There are new features in 2.4, but by beyond layer states, and DWG/DXF export the rest are largely minor improvements.
Serif tend to keep pushing the number up without actually adding any of the long-standing feature requests and bug fixes that folks have been asking for—often for many years. I'm usually 'happy' (I don't expect anything BIG from Serif anymore) if the next version doesn't introduce too many new bugs, or break existing features.

Yes, you can do this in Affinity Photo from the application menu, Layer -> New Pattern Layer… (or New Pattern Layer From Selection). You'll then be prompted with a dialog allowing you to set the width and height of the tiled area, which will then be shown as a grey square outline on the layer itself. You can then draw anywhere on the layer and the pattern will update in realtime.

Not to nitpick this in particular as it's just one such example, but it would be much easier to simplify processes wherever possible so as to have to avoid having to recall these little nuances. For a vast majority of users, nuances have almost no meaning and often induce additional headaches where one can't figure out that such a simple functionality actually involves additional complexities. Especially coming from other programs, this can be really be a hurdle to migrate when that person is having to unlearn the software form of "muscle memory" so to speak. I say this so it can be shared on the backend if it would be productive. While commitment to design philosophies are admirable to a point, long-term little these tensions multiply and add up to a poor user experience. Even for volunteers also, who have to constantly reframe how things work for new/onboarding users because we have to constantly remind ourselves (and others) what the user should actually be troubleshooting, versus focusing on what they should be attempting to do. I imagine this is tedious for staff also? It's also a headache to user test because as you've also seen, it's very easy to get these little nuances mixed up when trying to just give practical input. It can impact giving quality feedback because the expectations are often laid so far out of the box, so much so we start looking for nuances and troublesome snafus out of habit when we needed to look for simplicity! Recent example, a few of us were trying to help a user with getting Artboards sorted and apparently we had to learn that Power Duplicate doesn't work on Artboards. He solved his issue by hitting the "Insert Artboard" button. (Genius!) If it's making supposed veterans prone to simple user errors, then that's a problem. I don't think it's because the user is an idiot or that staff doesn't know the programs. I think it's because this "by design" approach is inherently antagonistic, often requiring a ton of memorization, and that's the complete opposite of an organized and efficient user experience. More akin to a developer mindset than a user-driven one.

(I'm not expecting a response btw, just leaving this out there)

I completely agree with this for non-contiguous Artboards with whole pixel dimensions (no matter where they are "placed") and it would avoid most of the problems created by the flexibility to place them where you choose... BUT you would still have problems when artboards touch each other and are non-pixel aligned widths/heights.
I ALSO feel the artboard tool should always default to creating pixel aligned and whole pixel widths and overriding would require a conscious choice.

The 'Clear Menu' at the bottom under a separator is standard on macOS. The 'More…' isn't—and because it is directly under 'Clear Menu' I've inadvertently selected 'Clear Menu' when I intended to select 'More…'. The current design is very error prone, and as 'Clear Menu' doesn't prompt 'Are you sure?' it's very easy to clear all recent docs if you're not paying attention.
'Clear Menu' should stay, keeping in-line with macOS guidelines, but the 'More…' below it could use a rethink. As it's more of a visual browser of recent docs than just a listing, perhaps it should be hoisted from the 'Open Recent…' submenu to it's own 'File' menu item, possibly as 'Browse Recent…'? 
File
Open
Open Recent…
Browse Recent…

The 'Clear Menu' at the bottom under a separator is standard on macOS. The 'More…' isn't—and because it is directly under 'Clear Menu' I've inadvertently selected 'Clear Menu' when I intended to select 'More…'. The current design is very error prone, and as 'Clear Menu' doesn't prompt 'Are you sure?' it's very easy to clear all recent docs if you're not paying attention.
'Clear Menu' should stay, keeping in-line with macOS guidelines, but the 'More…' below it could use a rethink. As it's more of a visual browser of recent docs than just a listing, perhaps it should be hoisted from the 'Open Recent…' submenu to it's own 'File' menu item, possibly as 'Browse Recent…'? 
File
Open
Open Recent…
Browse Recent…

The 'Clear Menu' at the bottom under a separator is standard on macOS. The 'More…' isn't—and because it is directly under 'Clear Menu' I've inadvertently selected 'Clear Menu' when I intended to select 'More…'. The current design is very error prone, and as 'Clear Menu' doesn't prompt 'Are you sure?' it's very easy to clear all recent docs if you're not paying attention.
'Clear Menu' should stay, keeping in-line with macOS guidelines, but the 'More…' below it could use a rethink. As it's more of a visual browser of recent docs than just a listing, perhaps it should be hoisted from the 'Open Recent…' submenu to it's own 'File' menu item, possibly as 'Browse Recent…'? 
File
Open
Open Recent…
Browse Recent…

Thanks. I never realized that 'Recent' was in the File -> New… dialog. I usually just type in whatever settings I need and ignore everything on the left.

The 'Clear Menu' at the bottom under a separator is standard on macOS. The 'More…' isn't—and because it is directly under 'Clear Menu' I've inadvertently selected 'Clear Menu' when I intended to select 'More…'. The current design is very error prone, and as 'Clear Menu' doesn't prompt 'Are you sure?' it's very easy to clear all recent docs if you're not paying attention.
'Clear Menu' should stay, keeping in-line with macOS guidelines, but the 'More…' below it could use a rethink. As it's more of a visual browser of recent docs than just a listing, perhaps it should be hoisted from the 'Open Recent…' submenu to it's own 'File' menu item, possibly as 'Browse Recent…'? 
File
Open
Open Recent…
Browse Recent…

The 'Clear Menu' at the bottom under a separator is standard on macOS. The 'More…' isn't—and because it is directly under 'Clear Menu' I've inadvertently selected 'Clear Menu' when I intended to select 'More…'. The current design is very error prone, and as 'Clear Menu' doesn't prompt 'Are you sure?' it's very easy to clear all recent docs if you're not paying attention.
'Clear Menu' should stay, keeping in-line with macOS guidelines, but the 'More…' below it could use a rethink. As it's more of a visual browser of recent docs than just a listing, perhaps it should be hoisted from the 'Open Recent…' submenu to it's own 'File' menu item, possibly as 'Browse Recent…'? 
File
Open
Open Recent…
Browse Recent…

WOW, thank you Bryan and Carl123 too.

I can't begin to express the number of times I accidentally click on 'Clear Menu', and chaos ensues. I implore you, please, just relocate it somewhere else. This small adjustment would bring enormous joy and significantly reduce frustration among all of us in the office.

Unfortunately Designer doesn’t have a replace fonts ‘feature’ (baffling, I know), but Publisher does.
Seeing as they both use the same file format (just different file extensions), you can workaround this by opening the file in Publisher to fix/replace the fonts, save, and then you should be good to go opening the file in Designer.