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

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 current official download from Apple provides SF Pro as a variable font. Affinity does display the named instances of this variable font in the font variant dropdown, but that still is a single font file. Apple uses CoreText for font rendering, which does support variable fonts. You may not be able to manually tweak the parameters of a variable font in Pages, but it does render correctly because the underlying text layout engine knows about variable fonts and applies the correct glyph spacing for each named instance. As far as I'm aware Affinity uses a custom text layout engine, which apparently does not apply the correct font properties of variable fonts.

That's related to variable font support. SFPro is a variable font and Affinity doesn't support those. The information in the font that determines the spacing between the glyphs is not applied correctly.

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

Any app that uses Rich Text (RTF) is supported out of the box. You can test that by copying some text from the vector app to for example TextEdit. Does the pasted text have the same font & weight? Then it should work with Typeface. If that doesn't work (the app might only support plain text), then Typeface needs a specific plugin to communicate with the app and change the font. Currently supported apps are listed here: https://typefaceapp.com/help/articles/font-switch

Make sure your text layer is active such that you see the blinking cursor. You can double click on the text in your document (not in the layers panel) to do that and make the text editable. Then drag and drop a font from Typeface to Affinity. Typeface will change the font for the entire text layer to the new font. The app needs permission to do this, you can learn more about that here: https://typefaceapp.com/help/articles/font-switch/affinity-designer Edit: in your video the layer is selected, but the text is not in the edit state yet

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.

Auto Activation is included and works natively for the Affinity apps. Not sure about v2 of course, I don't have access to the super secret internal beta unfortunately... eagerly waiting for the 9th like all of us!

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

Some small issues that you're probably already aware of: - Choose new color picker tool > hold mouse button > loupe is incorrectly positioned in bottom left corner of application (only after moving the mouse the loupe snaps to the position of the mouse) - View > Customise Tools... : Contains some duplicates (Move Tool / Artboard Tool) and missing icon for Donut Tool. (that cat tool though... :D)