Floor

Fix confirmed on Beta 2.4.2-2356 — thanks!

I'm a macOS developer working on integration with Affinity apps using drag and drop. When using the macOS NSFilePromiseProvider api to drag a promised file to a document in any of the Affinity apps they'll crash immediately on drop. It seems like Affinity v2 doesn't handle promised files correctly. See attachment for sample crash report. The issue can be reproduced consistently by dragging from any app that offers file promises without also providing a direct url using `public.file-url`. Examples: Contacts 1. Open a document in Affinity Designer 2. Open macOS Contacts app 3. Drag a contact to the open document => crash ForkLift - https://binarynights.com 1. Connect to a remote location 2. Drag a file from remote to open Affinity document => crash Typeface app - https://typefaceapp.com 1. Drag a font to an open Affinity document => crash Sample Code Project for NSFileProvider See https://developer.apple.com/documentation/appkit/documents_data_and_pasteboard/supporting_drag_and_drop_through_file_promises 1. Build and run 2. Drag image to window 3. Drag image from window to open Affinity document => crash Drag and drop from macOS Photos app works fine, because in addition to a file promise it also offers a url to a file on disk (`public.file-url`) and its contents (`public.jpeg`). That seems to work, but is not possible for apps that deal with data that does not exist locally yet. For my specific use case (Typeface app) it would be great if a file promise of type `public.directory` could be rejected by the Affinity apps, because dropping folders is not supported anyway. This could for example be done by refusing the drop when implementing NSDraggingDestination Possibly related to `af-1162` ? Affinity Designer/Photo/Publisher 2.4.0 macOS Sonoma 14.3 crash.txt

Can confirm, copying text when the system language is set to Japanese sets the following invalid rtf data to the clipboard: public.rtf {¥rtf1¥ansi¥ansicpg1252 {¥fonttbl {¥f0 ArialMT;}} {¥colortbl;¥red0¥green0¥blue0;¥red255¥green255¥blue255;} ¥pard¥plain¥fs229 Test¥fs0¥lang1024} Instead of the proper rtf syntax: {\rtf1\ansi\ansicpg1252 ...

What macOS version are you using? I believe that since macOS 13 Ventura the list is significantly smaller and not *all* Noto fonts should be visible. It's similar to the last screenshot—just 5 Noto fonts. If you're using an older macOS version you may be able to hide some of the (supplemental) Noto fonts using a third party font manager. That is not possible anymore on Ventura and later, but in that case the font list is smaller by default.

This might already be included in this report/fix, but just to be sure: when pressing Command and clicking on a text layer (Move Tool activated), the second click will change to the Text Tool. That makes the selecting workflow a bit cumbersome, because I have to change back to the Move Tool each time. Activate Move Tool Cmd-click on text layer A (-> layer A selected) Cmd-click on another text layer B (-> layer B selected + Text Tool activated + curser inside text) I'd like to keep the Move Tool active, in order to select/move another layer. Now I have to press Escape to get out of the text field and press V to switch to the Move Tool again. I'd expect a double click on a text layer to activate the Text Tool, but a single click (with or without Command) should only select the layer. (The Option-click workaround only works if the text layers are all in the same group. If they're not in the same group Option-click will select a group instead of a single layer.)

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.

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 @Dan C for looking into it, much appreciated! I can confirm this as well. I can reproduce the issue on Intel (Ventura + retina screen, Monterey + non-retina screen) and on M2 (Ventura + retina screen), using the same sample document. So I don't think it's limited to M1/M2 devices.

Ah apologies if this has already been reported before, I couldn't find similar posts when searching in this AD2 topic. It's indeed interesting that it's inconsistent, looks like some kind of caching issue. And it does also happen at 100% zoom if an inserted image itself is scaled to 200%. Weird!

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

Thanks for the details! I'll take a look at mipmaps. I assume mipmaps are deterministic? If they are, why does this issue happen occasionally, after repeatedly zooming and switching to 200%. It's not *always* blurry at 200% zoom. To reproduce: pinch to zoom, then press Command-2 to switch to 200%. About 50% of the time the image is blurry on screen. At 100% zoom everything is pixel perfect for this particular document. The main reason I'm using 200% zoom is because this is a non-Retina document that I'm viewing on a Retina display. In order to get the projected size the same as on a non-retina screen I need to zoom to 200%. Alternatively I can make the document 144dpi and use points instead of pixels. In that case 100% zoom on a Retina display will show the correct projected size. The document will have more underlying pixels, that's all fine. Now if I insert a non-retina 72dpi image into that 144dpi document, I'll have to scale that img up to 200% to get the correct projected size. In this case the exact same issue pops up at 100% zoom. See attached document. This is the same doc as before, but it's 144dpi and the image in Artboard 2 has been scaled up by 200%. pixel-square-r.afdesign

Hmm I just noticed that the images I uploaded here show the same behaviour in Safari. So the uploaded images themselves are blurry because they're scaled (retina -> non retina). Now I'm not sure if this is expected, and I just don't understand how this works...

Images may become blurry when zooming in at 200%. This doesn't happen always so it's a bit hard to describe and to give the exact steps to reproduce. See attached sample document — at 200% zoom the middle image (which is not scaled) sometimes becomes blurry. May need to zoom back and forth a bit to reproduce. But the issue does happen when switching to 200%. See screenshot (note that the small square is expected to be a solid grey in Artboard2, since these are half pixels in the original.) This might be due to View Quality: Bilinear. When changed to Nearest Neighbour the image stays sharp. But Nearest Neighbour has other artefacts if 'Pixel view mode' is enabled (see second screenshot). Therefore not a solution in many cases. With Bilinear on I wouldn't expect a perfectly zoomed in image to be blurry — there should be no interpolation since every document pixel perfectly matches screen pixels. High Quality retina rendering enabled Happens on both retina and non-retina screens Ventura 13.2.1 Affinity Designer 2.0.4 pixel-square.afdesign

Create a new document Create two artboards Create a rounded rectangle Enable 'Absolute sizes' for fixed size corner radius Choose Document Setup Adjust document size or DPI to something else and apply Expected: corner radius is still similar to before Observed: corner radius becomes 0 -> square corners corner radius is preserved if there is only one artboard and Objects will: Anchor to Page is selected if there are multiple artboards or Objects will: Scale is selected then corner radius is removed Affinity Design 2.0.4 MacOS Ventura 13.2.1

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