Dan C

Thanks for your report! The 'new' Gradients shown in your screenshots above have additional handles as the Gradient has been scaled with the object. These are called 'Correction Paths' and are covered in the following helpfile page, under "Transforming objects with linear or radial gradient fills" - https://affinity.help/designer2/English.lproj/index.html?page=pages/Clr/gradientEditor.html?title=Gradient and bitmap fills You can double click on a Correction Path node to remove it from the Gradient, if they are no longer required following the scaling of the object with the Gradient applied. _____ This however doesn't exactly answer why the gradients in the original objects in your file are not scaling when transforming - as they appear to have similar properties to a newly created Gradient, though do not show the aforementioned 'Correction Paths' after scaling the rectangles, indicating the application is aware they are not being scaled. I have managed to find a fix for these specific gradients - if you select the object, the open the Fill dialog from the Context Toolbar and double click the 'End' gradient node to simply select it, the Gradient is then correctly scaled with the object and shows the 'Correction Paths' as expected: 2023-10-27 13-04-53.mp4 In my testing I've not yet been able to discover the exact reasoning behind this behaviour in your file, or a workflow to trigger this to occur with a new Gradient. If you have any further ideas as to how this file ended up in this state, please let me know and I'll be happy to log this with the team

Thanks for your report @Fritz_H! I'm not seeing this with my test images, can you please provide a .ZIP of these, such that I can try stacking here? If you'd like a private upload link, please don't hesitate to ask. I've been able to replicate both of these issues and I'm getting them logged with our team now - many thanks

Just FYI, I've just converted this to an 'AF' issue, meaning it can now be found under AF-964 (unfortunately the automated system replaces any old 'AFD' tags with the new 'AF' tags when converting) so you'll need to adjust your Tag search as such That's correct, the issue is still 'open' with our Developers at this time and is the above 'converted' report I've mentioned. The below is a comment from this aforementioned report, following my testing in September - I hope this clears things up!

Hi @JohnKAR, Welcome to the Affinity Forums & sorry to hear you're having trouble! Can you please open the original iPhone image within Affinity Photo, then select the Pan (Hand) Tool. On the Context Toolbar above the canvas you should here see the Colour Space and ICC Profile used for the document. (ie RGB/8, sRGB IEC61966-2.1) Can you please confirm the information that is provided here for this image? When viewing the exported image on your iPhone, are you simply using the 'Photos' app to view this, or a different app please? Many thanks in advance

I've bumped this issue with the team, including the latest beta versions as 'Affected' - thanks for letting us know

There is currently an improvement request logged with our developers specifically for this and our team are looking into adding this as a dedicated option. I've 'linked' this thread to the request, so that our team can see how many users are requesting this. I've also explained that previous to 2.2 there was a known workaround with Add, but since this has been lost due to unrelated Boolean fixes, the dedicated option is more wanted than ever

Unfortunately as I'm simply a member of the Technical Support team, the decisions regarding the apps are not mine to make - hence the wording choice used above. I can only (and have previously) make convincing arguments to our developers to suggest what I (or our users) believe should be the expected behaviour of the Affinity apps, but the developers who write the code have the final say in these things. As I understand it, using the 'Add' operation on an Open Curve with a Fill will Close the curve, which is expected behaviour. If no fill is present, the curve is deleted. This is the behaviour that R C-R confirms above. At this time, the 'Add' operation does not check the object to see if a fill is present, disabling the option when one is not applied- this would make for a good Feature Request post for our devs to consider in the future.

The linked comment above from my previous post only officially recommends using the Cycle Selection Box option, unless I am misunderstanding the Staff post you're referring to? Further within the linked thread, a different user suggests the 'Add' option as a workaround. As I understand it, Boolean operations are only technically designed for Closed Curves. Using Boolean operations on Open Curves can result in the curve layer being removed and I do not believe that is a bug according to our developers. It appears as though this previous workaround has been inadvertently removed, due to a semi-related Boolean fix in 2.2 - this has been reported as a bug here, but is still currently awaiting confirmation from our team: I certainly understand the usefulness of using 'Add' to reset the bounding box, so hopefully our devs will agree and recognise the above report as an issue to be resolved - but I believe the only officially supported method is to use the Cycle Selection Box option, which is only a temporary change for the Bounding Box of the layer. This option is still working as expected for me in both 2.1 and 2.2

I believe R C-R is referring to the following: https://realsound.jp/tech/2023/09/post-1446012_2.html Translated:

It's certainly possible that the Clipboard contents are causing the crash - which is equally why Clipboard managers can cause similar behaviour. Are you able to upload a copy of the .docx file, containing the text that was on your clipboard at the time, so I can test further with this here?

Hi @James Beatte, Welcome to the Affinity Forums & sorry to hear you're having trouble! Can you please confirm for me: Does this crash occur in any document, including a New file - or only in a specific file? If you disconnect the Wacom tablet, does this crash still occur? If you select the Knife tool from the left hand toolbar, rather than using the keyboard shortcut, does the app still crash? Many thanks in advance

Following the release of Affinity 2.1, which updated the PDF export library that Affinity uses, our team have discovered an issue in all Affinity apps on all platforms. When exporting an RGB document to PDF, if the export setting is set to 'Use Document Profile', the PDF will be assigned the sRGB2014 profile incorrectly. For users on Windows, Manually specifying the correct profile in the export dialog (instead of the 'Use Document Profile' option) should export the PDF with the specified profile as expected. Unfortunately this workaround does not work for macOS. If your document contains 'Placed' (ie Embedded or Linked) images, when exporting to PDF using the RGB Colour Space, the images will always use the 'sRGB2014' Colour Profile, within the PDF. From our testing, this issue can occur with any Affinity document using the RGB Colour Space, and still continues when converting the image colour space during export. To workaround this issue for 'Placed' images, you can convert the 'Placed' Image layer to a Pixel layer will correctly export/convert the images colour profile in the PDF. To do this, please select the 'Placed' Image layer, right-click and select Rasterise... This issue has been logged with our development team as a high priority issue and we're working to resolve this ASAP. Our apologies for any inconveniences caused due to this in the meantime.

Hi @Darner, Thanks for your report! I can confirm that this is currently expected behaviour - as named each operation is a 'New Batch Job...' and therefore the Batch settings are reset each time. I'll move this thread to the Feedback section of our Forums, for our team to consider adding an option that retains the previous settings used, for example. I hope this clears things up

Hi @meIT666, Welcome to the Affinity Forums & sorry to hear you're having trouble! We've seen reports of this previously and it's usually caused by either outdated GPU drivers, or G-sync. Therefore I'd recommend ensuring that your GPU drivers are fully up-to-date, directly from Nvidias website. I'd also recommend performing a 'clean install' for these drivers, as covered here: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-install-an-NVIDIA-Quadro-display-adapter-device-driver.html Once these are updated, does this stop the flicker issue for you? If not, please try disabling G-sync for the Affinity apps, using the following steps: https://www.howtogeek.com/902169/how-to-turn-off-g-sync-for-specific-or-all-games/#:~:text=That's it!-,how to turn off g-sync for specific games,-Disabling G-SYNC I hope this helps

Thanks for your report @earl_grey! I can confirm I've replicated this issue here and I have logged it with our development team to be resolved ASAP. I hope this helps

Thanks for these Dave, looking at these DMP files it appears as though the issue may be caused by low disk space - which could explain why the same behaviour was seen in the second user account. How much free space do you have available on your internal hard drive please?

I can confirm this issue is still logged with our developers at this time - my apologies. I have 'bumped' this issue to bring it to our teams attention once again and requested that this is investigated further, ASAP. Unfortunately I'm unable to provide any estimated timeframe for this to be resolved but I certainly hope this fix is made available in an upcoming beta for you. I hope this clears things up.

This has been covered previously by NotMyFault here, essentially the app will begin using virtual RAM if the physical RAM limit has been reached on the system, but the Affinity app's slider is increased beyond this point: No problem at all, thanks for confirming that for me! Hopefully the above changes should help with your issue, but we're happy to help if you have any further questions or issues

That's certainly interesting behaviour, thanks for the further information provided also! I've double checked this on my Intel iMac running Monterey, and an M1 MBP running Sonoma and I'm not seeing the same issue, so its possible this was a temporary rendering glitch which has resolved itself. Please do let me know if this returns, or if you find a consistent way of triggering the issue

Hi @yok2293, Thanks for your feedback here! I can confirm this is a bug in the iPad apps, as you should be presented the Gradient controls when setting the Outline FX to use a Gradient. I'll be sure to 'bump' this issue with our development team to bring it to their attention once again. I hope this helps

Thanks for raising this @anto - there is certainly something interesting going on here. The result you're seeing on Google appears to be for the V1 helpfile, though searching for this page directly, or using the menu system does not show this helpfile page listed. In the V2 helpfile, this pages does not appear to exist at all, either through searching or the menu system, and therefore it doesn't appear as though these functions are covered at all. I'll be logging both of these with our Help team now, for V1 and V2 helpfiles

Hi @Garehard, Welcome to the Affinity Forums I can confirm this is a known issue, which has been fixed in our latest beta version! You can either wait for this update to be released (we have no exact timescale for this yet) or download and install the beta alongside your retail version using the information below: I hope this helps!

Just to confirm, I've logged this as a bug with the development team as I would expect this view to scroll in the Pages Studio. If you are dragging a Master Page, the Masters section will scroll, if you are dragging a Page then the Page section will scroll, but seemingly if you are dragging a Master in the Pages section, or a Page in the Master section, this scrolling stops working. I hope this helps

Welcome to the Affinity Forums @TylerLFG We're certainly sorry to hear this - though I'm unsure of the exact issue you're experiencing currently as I have not seen this reported by other users since releasing 2.2.1. As above, a screen recording or screenshots showing this issue may help us to investigate further. I'd like to request a copy of the document that can be opened in 2.0.0 without issue, but shows this error within 2.2.1 - can you please upload a copy of this document here for me? If you'd like a private upload link for this file, please don't hesitate to ask. Many thanks in advance!

Thanks for providing that for me and your continued patience here! Your latest event viewer shows the crash is certainly occurring due to the app trying to draw the right-click (context) menu -see the below excerpt - though our team aren't able to decipher much more information as to the cause of this issue, from said log - Therefore they've requested a .DMP file, which can be force generated through Task Manager, as I understand the app is not generating one when crashing. If you can please open the Affinity app and just before triggering this crash, right click on the Affinity app in the Task Manager and select Create dump file. Then, trigger the issue by right clicking and quickly return to Task Manager, to try and create a second dump file before the app fully closes. Can you please upload these manually created dump files here for me, so that we can continue our investigation?