Floor

Hi @Floor,
Thanks for reporting this. 
I've been able to replicate this and have just gotten this logged with the Developers.  It could very well be related to AF-1162 from what i can gather from reading that bug report.  Either way, this has been logged as a crash is always unwanted behaviour. 
This thread will get a reply from the Serif Info Bot when this has been resolved and if theres any feedback from the Developers, i'll update here as well  

That's what font manager apps are for.
For example, on MacOS Ventura I use Typeface. Before that I was a longtime user of FontExplorerX.

For Mac users, I'll second Typeface.
I have Suitcase Fusion on my older Macs, but dropped them for newer Macs when they went full evil, er, I mean, subscription, though I did partially enjoy their humorous eMails trying to explain why paying them a subscription benefits my budget somehow.
After that, I switched to another font manager which I didn't find worked as well and ended up with Font Explorer X which wasn't bad but is no longer available.
So, now it's the Typeface App for me.
I'm not really weeding out any Postscript fonts but rather searching for their TT versions if available and switching.

I'm a recovering font addict myself. I switched to using Typeface recently and did a deep purge of my collection to weed out the old Postscript fonts that are being phased out. I'm happy with the app. It has a lightweight feel to it, but doesn't skimp on features. And it seems to have regular updates and improvements.

You can indeed 'use' variable fonts (the named instances) in Affinity apps, but they're not 'supported'. What this means is the following:
Affinity can load variable fonts: YES Affinity can use variable font named instances (regular/bold etc.): YES Affinity can adjust variable axes: NO Affinity can render variable font named instances correctly: NO The biggest issue is point 4: while you can choose a named instance of a variable font, it doesn't render correctly. See screenshot: left is Affinity, right is another app that renders variable fonts correctly. As you can see the tracking/kerning is incorrectly using the Regular values, instead of the values for the named instances. Font used: SF Pro variable.
The ability to adjust and tweak variable axes (point 3) would also be great, but rendering named instances correctly would already be a great improvement.

Hi folks,
I feel there is a big regression on selection precision and a very effective productivity killer.
The following is similar to this topic but applies more globally on my video.
This first video shows the selection process using Affinity Designer V1:
If I need the selection items inside a group or a shape, I'm pressing cmd. Please note that selecting the white rectangle works flawlessly whenever the pointer does not hover a text. This is all perfectly working.

Affinity - V1 Selection Behavior.mov    
This second video shows the selection process using Affinity Designer V2:
Here I'm trying to select the white rectangle. Even if my pointer clearly not overlap texts, those will select, making impossible to reach the white rectangle. It's like there is a huge invisible contour/offset around texts. Also, the tendency of the move tool to switch to text tool is super annoying.

Affinity - V2 Selection Behavior.mov   Hope this helps.
Regards.

I'm very excited about scripting support, can't wait to play with it! The previews look promising.
If there is one thing I could request it would be the ability to run/trigger a script from outside of the Affinity app UI. For example I'm the developer of a font manager app for Mac, and it would be great to be able to adjust fonts and text properties from within the external app. Currently using the macOS Accessibility api to do something similar, but with scripting it can be made much more user friendly.
Sketch includes a `sketchtool` binary that can run any plugin and pass some context (for example json). It's fine if the user would need to explicitly 'install' a plugin for security, but it would be nice if such a plugin/script can be triggered without any further user interaction. Another option would be an Apple Script handler that can kickstart a plugin/script and pass context, but that's not cross platform of course.

Thanks for all the mentions, I'm glad so many of you like Typeface app! I'm the developer — if you have any questions or want to migrate from FEX just shoot me a message. Happy to help.
Fun fact: much of the Typeface UI is designed in Affinity.

I really, really like Affinity software, but I do make a lot of errors because of this little icon, which I can barely understand when I'm looking directly at it. I end up unintentionally changing the aspect ratio of elements (or not), blissfully ignorant until I've already made a bunch of additional changes and I no longer remember what the correct aspect ratio was supposed to have been.
Can you please make the visual cue *significantly* more obvious?
Update
I've made so many mistakes in V2 and I couldn't remember how V1 even looked, so I looked it up. The old indicator was an embarrassment of riches. No wonder I'm so mistake-prone using V2!

 
 

Touché, yet I did search and computer said 'no'.

I asked for a similar question earlier.
Here's the answer given by TonyB:

Thanks for letting me know - I can't explain why I wasn't able to replicate this on my Intel based mac during testing but I will be sure to update the development log to include the above information now

Thanks for the further information provided here - in further testing this appears to be an M1/M2 based issue within Affinity, as I was unable to replicate this issue on my Intel based mac with Metal enabled, however with your document on our M1 MacBook Air I'm able to see this issue occasionally when zooming to 200%.
Therefore I will be logging this with our developers for further investigation now. I hope this helps

No need to apologise
I've not noticed a report before, but I've noticed the problem for years. It's particularly annoying in Photo because of its effect on the view of blend modes and live filters. 
Yes, I should have reported it, but many reported issues have been neglected for years so I often lack motivation and just move on.

Thanks for your reply! The document is included in the original post, see 'pixel-square.afdesign'
I'm aware of pixel-alignment of artboards and objects, which can be annoying as well for UI work. But it's not what I try to demonstrate in this report
Main use case is UI work, so I don't care about physical measurements or print size. The only thing I care about is that the pixels I create are mapped to exact (multiple of) screen pixels. The document uses 100x100 pixels — which is 50x50 screen points on a retina screen. That's too small, so I zoom to 200% to get the correct size.
See attached screen recording for details — I pinch then press Command-2 to go to 200% zoom. This is on a Retina display, but the same happens on a non-retina display.
Artboard1 = original rectangle objects
Artboard2 = 100x100 png of Artboard1
Artboard3 = 200x200 png of Artboard2 (scaled 50%)

Screen Recording 2023-03-24 at 13.47.33.mov

Hi Floor,
I have logged this with our developers to be fixed in a future version.
Thanks
C

I tried to activate Athelas via creativecloud and got exactly the error you mentioned (already exists). Renaming the font is a good workaround but I think this isn't the way things should be.

Yes agreed—unfortunately that is a macOS problem. I'd recommend to send your feedback to Apple to let them know about your use case: https://www.apple.com/feedback/macos.html

Athelas is indeed a 'Document-support' font. That means that it is a macOS system font that is always activated, but it is hidden from font lists. You're not supposed to use that Apple provided font for new documents, but existing documents that already use the font can (and should) still display correctly.
In Monterey the Affinity apps showed all Document-support fonts in their font pickers, which is technically incorrect. They shouldn't have been visible.
In Ventura the Affinity apps don't show the Document-support fonts anymore in their font pickers (this is correct behaviour). That means you're not able to pick the system Athelas font anymore. But it should render correctly for existing documents. So the RTF text document which you created manually should indeed display correctly, like it does in TextEdit. Since it is an existing document it should use the system Athelas font. This seems to be a bug in Affinity apps.
 
To solve this you'd need your own version of Athelas.
The problem is that you can't simply install/activate your own version of Athelas, because that would create a conflict with the system version. Both fonts have the same (PostScript) name, so they cannot be activated at the same time (even though the system variant is technically hidden).
The solution is to rename the PostScript name field of your own version of Athelas. That allows you to activate your own version next to the system version.

1. Open the font in FontForge
2. Choose Element > Font Info
3. Rename the 'Fontname' field to something else (e.g. 'Athelas2-Regular'), this is the identifier for activated fonts
4. Change the 'Family Name' and 'Name for Humans' as well, so you can differentiate between your own version and the system variant in font pickers (just makes it easier to see)
5. Choose 'TTF Names' from the sidebar
6. Change 'Preferred Family' to the same value as 'Family Name' in PS Names (see step 4)
7. Press OK
8. Choose File > Generate Fonts...
9. Set the type to TrueType (or OpenType CFF if the font you're converting uses CFF outlines)
10. Press Generate (continue on warnings)
Then you can activate your new font file (using a font manager, or manually in ~/Library/Fonts).
This will show up in the Affinity font picker with the new name you've chosen.
 
Note that converting/renaming font files may be against the font license. Make sure to check the license first before editing fonts.
 

The layer names in the layer panel are cropped when the Font UI Size is set to Large. The descenders are not visible.
Steps to reproduce:
Enable Preferences > User Interface > Font UI Size > Large Create a new layer named 'typography' Result:
'typography' is shown in layer panel, but descenders are cropped off, see screenshot
 

I can confirm. When setting 'Font UI size' to LARGE as @Floor described, labels get truncated elsewhere, too.

Hi @Floor
We are aware of this issue and it has been passed over to our devs for further investigation.

The layer names in the layer panel are cropped when the Font UI Size is set to Large. The descenders are not visible.
Steps to reproduce:
Enable Preferences > User Interface > Font UI Size > Large Create a new layer named 'typography' Result:
'typography' is shown in layer panel, but descenders are cropped off, see screenshot
 

Version 1.8 of OpenType was released in 2016, it included Variable fonts. The feature is mature and widely used nowadays. 
It would be great to have support for variable fonts. 

I'm the developer of Typeface app for Mac — would love to integrate with the Affinity suite to get better support for font collections. Currently it's possible to drag and drop from Typeface to Affinity, but it would be nice to have your custom tags/sets in the font picker as well. Fingers crossed for a plugin system in v2, that would be amazing