-
Posts
13,847 -
Joined
Posts posted by Dan C
-
-
Thanks for your report @Fritz_H!
15 hours ago, Fritz_H said:- when creating a stack the image orientation is not recognized. (stack is shown upside down, when opened seperately the images are shown correctly, pics taken with Galaxy S20+)
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.
15 hours ago, Fritz_H said:- when clicking on the "X"-icon a menu pops up ("mean", "median".. )- it does react to the mouse-scrollwheel,
but grabbing the scroll bar with left-click results in moving the stack-layer instead of moving the list.15 hours ago, Fritz_H said:- as soon as this happened, the pop up menu is "stuck" - you can move the application window around - the popup menu stays in place. Left-click makes the menu disappear.
I've been able to replicate both of these issues and I'm getting them logged with our team now - many thanks
-
2 minutes ago, thomaso said:
Note, the related bug AFD-5529
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
5 minutes ago, thomaso said:I initially mentioned above does not got a reply from the @SerifInfoBot yet. (I assume every fixed bug gets a post of the bot in the threads that have a related tag attached)
That's correct, the issue is still 'open' with our Developers at this time and is the above 'converted' report I've mentioned.
6 minutes ago, thomaso said:• What file path does your Resource Manager show for this file in Windows?
• And did you switch it to be "linked" – or got it initially placed with this setting?The below is a comment from this aforementioned report, following my testing in September -
QuoteThe behaviour of this has changed in V2, as has the ‘Linked’ location used on macOS.
For raster stock images, the image is Embedded, ignoring the "Prefer Linked" preference.
For vector stock images, the image is Linked. This obeys the "Prefer Linked" preference.
However, on macOS the Linked location is now also a ‘temp’ folder, matching Windows. This means that when using Vector Stock with document policy set to Linked, after saving, closing the app & reopening the document, the Linked resource is now ‘Missing’ and has to be re-added through the Stock panel.
I believe this should respect the document policy at all times - though I’m not sure of the exact location the app should use to link the file in this instance.
Regardless, it’s currently possible to add Stock which is then lost after restarting the app and this should be addressed
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
-
10 minutes ago, Return said:
Found it and it is one of your own posts.
2 minutes ago, Return said:Just tested with a linked stock file and saved>closed>re opened and it still has the issue of the resource not found.
I've bumped this issue with the team, including the latest beta versions as 'Affected' - thanks for letting us know
-
16 hours ago, R C-R said:
FWIW, because it is not intuitive or obvious, I think that instead of Layer > Geometry > Add resetting the rotation of a shape there should be a command explicitly to do this, perhaps as a separate item on the Layer > Geometry submenu named "Reset Selection Box Rotation" or some such.
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
-
6 minutes ago, Pšenda said:
Do you think that deleting a layer with a command that has nothing to do with "deleting" (on the contrary - the Add command should add something) is completely fine?
55 minutes ago, Dan C said:I do not believe that is a bug according to our developers.
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.
6 minutes ago, Pšenda said:If this command is designed only for "closed" curves, why is it offered for "open" ones as well? So shouldn't it be properly (by design) disabled to use this command that even deletes the layer? For example, by disabling the Add command (in the menu and toolbar) when selecting a layer with an open curve?
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.
-
12 minutes ago, Pšenda said:
So using the above command as the "official" (Serif recommended) way to reset the box is quite strange.
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.
1 hour ago, Pšenda said:For me (Win) deletes the curve layer 😞
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.
1 hour ago, R C-R said:In AD 2.2.1 on my Mac Geometry > Add does not reset the selection box for me either. Same with the new beta.
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
-
15 minutes ago, myclay said:
By any chance, do you have a link to the interview and could you kindly provide it?
I believe R C-R is referring to the following:
https://realsound.jp/tech/2023/09/post-1446012_2.html
Translated:
Quote--I think the next update will be version 2.3, but what kind of features are planned to be added in 2.3 or subsequent updates?
Ashley: We plan to release 2.3 by the end of the year. We cannot tell you about the specific functions that will be implemented at this time, but we are planning to provide a "cloud service" as a function that will be implemented in the future, which will allow us to share tool assets, color palettes, etc. across devices. It will be.
Additionally, there is a function using AI that we plan to implement in the future. In fact, we've been working on this for the past two years with a team dedicated to AI, and we're starting to see some features that we're excited about. I'm sure it will be a great product that will surprise all users.
We believe that we will be able to make some kind of announcement about either feature in the next 3 to 6 months. please expect to have fun and wait.
- Sonny Sonny, myclay, Mithferion and 8 others
-
3
-
8
-
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.
- pruus, GaMeOveR and Pixelplucker
-
3
-
Hi @Darner,
Thanks for your report!
19 hours ago, Darner said:Discovered that the settings in the batch window automatically reset every time batch is done, and without closing the app. Which means every time have to re-adjust same or similar settings.
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:
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:
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.
-
20 hours ago, R C-R said:
I have always been curious about how setting the RAM limit to more RAM than is installed could make any difference to the performance of either the app or the system. Surely, the OS would limit the app's RAM use enough that the system could never run out of RAM & of course the app itself could not possibly use more RAM than is installed, right?
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:
10 hours ago, khalifah iskandar said:this pc have 32Gb ram installed. thanks for the explanation @Dan C , cheers!
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
18 hours ago, TylerLFG said:The new Affinity update completely messed up my 75+ page document. Text boxes are messed up. Its like there are massive invisible objects in my documents that mess up my text wrapping, which i cannot fix because technically those "objects" arent there.
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.
18 hours ago, TylerLFG said:I tested my document on my old machine with Affinity 2.0.0, and it works fine.
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 -
SpoilerApplication: Publisher.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at <Module>.Affinity.FieldFormatController.IsFormattable(Kernel.Counted<Story::FormattableFieldGlyph const >*) at Serif.Interop.Persona.Tool.DoesTextSelectionContainFields(Serif.Interop.Persona.IDocumentView, Boolean ByRef, Boolean ByRef) at Serif.Affinity.Workspaces.Workspace.GetContextMenuForSelectionInView(Serif.Interop.Persona.IDocumentView) at Serif.Affinity.Services.UserInterfaceService.DisplayContextMenuForSelection(Serif.Interop.Persona.IDocumentView, Serif.Interop.Persona.ContextMenuType, Int32) at Serif.Interop.Persona.UserInterface.DocumentRenderControl.InteropService_ShowContextMenuNotification(System.Object, Serif.Interop.Persona.ShowContextMenuNotificationEventArgs) at Serif.Interop.Persona.Services.InteropService.OnShowContextMenuNotification(Serif.Interop.Persona.NativeWrapper<Kernel::NonCounted<Kernel::Notification> >) at Serif.Interop.Persona.Services.InteropService.HandleNotification(Kernel.Counted<Kernel::Notification>*, Boolean) at Serif.Interop.Persona.Services.InteropService.OnNotify(Kernel.Counted<Kernel::Notification>*) at <Module>.GetNotificationDispatch.<lambda_5110c3db91a5586d308facaff1f9cbcb>.()()(?GetNotificationDispatch@@$$FYA?AV?$function@$$A6AXXZ@std@@V?$Counted@VNotification@Kernel@@@Kernel@@@Z.__l2.<lambda_5110c3db91a5586d308facaff1f9cbcb>*) at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef) at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame) at System.Windows.Application.RunDispatcher(System.Object) at System.Windows.Application.RunInternal(System.Windows.Window) at Publisher.Application.Main(System.String[])
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?

Gradient not scaled
in V2 Bugs found on macOS
Posted
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:
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