NathanC

Hi @AlexDlg, No updates to share i'm afraid, but the thread is tagged with the issue ref so if there are any updates the serif info bot will automatically reply.

Hi @Spectrum999555, Thanks for your sample files, I can confirm i'm also seeing this and it does appear to be a bug, for reference I created an identical document back in V1 for comparison and these redraw and export issues are not present. V1: V2 (some zoom distances were better than others, but the export was still not great): As shown, as the displace strength is increase the effect begins to offset itself on the page, this is a separate bug logged internally but is likely related to this undesired harsh lines appearing on export and at different zoom distances. I'll get this logged with the developers. Having 'Scale to Fit' turned off does work does reduce the redraw issues and harsh lines, but comparitively isn't as effective as the strength is increased.

Welcome to the forums @JavyJar8, Prior to printing from Affinity using your custom dimensions, are you able to define your custom page dimensions in your Printer Driver? According to the Print Manual, you should be able to do this in the HP Printer Properties under the 'Paper/Quality' tab. Once this has been set for your custom size, try restarting the app and printing again.

Hi @AffinityFan2k19, Just to initially confirm, have you tried disabling Hardware Acceleration? This can be done outside of the app by following the below: Close all Affinity apps Hold down CTRL and launch the app while still holding CTRL A 'Clear user data' will prompt, tick 'Disable Hardware Acceleration' Press 'Clear' and the app will now launch If the crashes persist, could you provide us with a couple of recent crash reports since the issue started happening? The FAQ below details how to find these.

Hi @evtonic3, I'm not seeing this behaviour. In the Colour panel, if you set the fill colour well to have no fill via the 'Quick Colours' menu again and then try drawing with the pencil, what happens? RPReplay_Final1711375488.mp4 If it still persists, could you try defaulting the tool via the Document menu > Defaults > Revert?

Hi @chirpy, This behaviour doesn't appear to mirror how desktop works, as on desktop the quick shape tool is persistent with the last shape used even when the active object selection is changed. As such, I don't believe the current iPad behaviour is expected and i'll log this with the developers. After amending the pen tool settings (E.G Stroke width, Cap, Join) You can save these new properties as the global default for the tool with it selected by going to the 'Document' menu at the top left hand corner -> 'Defaults' -> 'Save'. https://affinity.help/designer2ipad/English.lproj/pages/ObjectControl/objectDefaults.html

Hi @anto, This issue is currently logged with the developers, i've now updated the issue to reflect that it's still outstanding in 2.4 and bumped it with your report. 👍

Hi @Adiemask, RAW support for the A7CM2 was added in the 2.4 update so it should be possible to correctly open and develop RAW images from this camera using the standard Serif labs RAW engine. Could you describe what's specifically happening when you're opening these RAW files?

Hey @FranckV, This is a known issue currently logged with the developers, I've now bumped the existing issue with your report.

No Problem, not that I'm aware of currently unfortunately, image layers retain all their original data such as the resolution and colour space so you'd have to scale those images down before placing them in Publisher. You could also rasterise your images to pixel layers, but this will severely affect the quality of the images since they're rasterised at the Document DPI.

Hi @Desloover Pascal, This does sound like it would be most efficient to create a data merge template in Publisher for this if you have the product data collated on a spreadsheet for use as the data merge source. I'd recommend reading through our help guide articles as well as the video tutorial to get a better understanding of how it works since it's an advanced app feature. https://affinity.help/publisher2/English.lproj/pages/Advanced/dataMerge.html There are also plenty of tutorials on data merge provided by third party creators from basic to more in-depth analysis on YouTube if you search for 'Data Merge'.

Hi @Gatada, This definitely looks like a bug, so I've now moved this thread over to the bug section of the forums. I can confirm I've also replicated this so i'll get this logged with the developers, thanks for letting us know. 👍

Hi @Cloudfactory, I've opened your file on Desktop and similar to the OP's file it far exceeds the available memory of a Gen 4 iPad Pro (8GB) as after it finishes loading it's using around 16GB of RAM on Windows/Mac. While you don't have nearly as many pages the significant number of high-res high DPI image layers that have been placed on each page have contributed towards this high memory usage which the iPad evidently can't keep up with, so similarly the file certainly needs splitting down to be workable on iPad. I've split your document down into three .afpubs on Desktop using the 'Add pages from file' function (Unfortunately this function isn't available on iPad currently), to which i'm now able to keep all three files open for editing on iPad without any subsequent problems, I've PM'd you a link to the now split file.

Welcome to the forums @BigMike18Ike, Unfortunately this issue is still outstanding with the developers, I've bumped the issue with your report. If there are any updates the Serif info bot will automatically reply to this thread.

Hi @Javier Luna, Thanks for sending the file over, I've inspected your file and it doesn't appear to be recoverable in this case unfortunately, when inspected in a hex editor the data in the file is missing throughout the entire file (Indicated by the '00' on each line). We do usually log these files with the developers however in this case there isn't any data left in the file to recover or investigate sadly. I can only suggest reverting to a backup if any are available.

Hi @Like, would like more if…, I was originally under the same understanding that when a previously captured state is updated both the layer scope updated to include any new layers as well as any visibility changes made, so when the state did not update the scope with the new layers I logged this with the development team. However I have since been informed that this might be by design and that the current functionality of the update button is only intended to update the layer state for those that it originally captured in the scope when that particular state was created, however I'm still waiting to hear back from dev to confirm. For now I'll bump the existing issue with your report to bring some more attention to it. If this is by design I'll be logging this functionality to be added, as you pointed out it can become frustrating to delete, re-create and maintain previously captured states when new layers have since been added so hopefully this will be considered so update captures any new layers as well. Not sure, but I agree that it is unusual that it doesn't appear to be possible, I'll log this separately.

Hi @Javier Luna, Unfortunately the 'File type not supported' error when opening .afphoto files is typically an indication that the file is corrupt to the point where the app no longer recognises the document as a valid file type. If you could upload the file to the link below (if you don't wish to share it publicly) we can determine whether or not the file can be recovered by any standard methods. https://www.dropbox.com/request/hXYpEiAoPOSAw4VQJkBt Many thanks

Hi @SamMN, Could you possibly send over the Publisher documents from both examples so we can look into this further? I have included a private upload link below. Since you've used external resources, so we can access these files could you possibly save the document as an .afpackage file? This can be done via File > Save as package > Save to an empty folder in finder > Compress the folder to a .ZIP > Repeat for second document. Upload link: https://www.dropbox.com/request/I6carFP1tAXo1CQdpbWm Thanks

Hi @PerryM, I can see you have also posted about this plugin/app crash in the thread below, have you been able to get the plugin working within the app? If not, can you provide a bit more info on where you're getting stuck and provide a screenshot of your app Settings > Plugins Window?

Hi @JPipe, Quite the strange issue, we don't have a Cintiq Pro 16 but we do have a Cintiq Pro 13 to which I've never experienced an issue like this on Photo Mac when using it. I'd suggest trying the following: - Disable Metal Compute and set the 'Display' to 'OpenGL (Basic)' In Photo 2, this can be done via the App Settings > Performance, once the box has been unchecked and the display setting changed, close the dialog and restart when prompted to before trying again - Try completely removing the Wacom Drivers and then perform a complete re-install of them to refresh your existing drivers. - See if the issue happens in Designer 2's pixel persona when using raster brushes, as I'd be interested to see if it really is just limited to Photo 2. If none of the above works, could you see if you can capture the issue occurring on a screen recording? The FAQ below details how to record if you're unsure. Many thanks

Hi @Dr_No, As far as I'm aware there isn't a way to delete multiple LUTs out of a category concurrently, as left clicking them will always just load that select LUT into the adjustment window immediately so a shift + left click highlight selection is not possible, so I think they'll just need to be removed singularly unfortunately.

Welcome to the forums @andreasr1505, We are still looking into issues relating to the 'Fail to save' error following the 2.2 file handling improvements, as Walt's mentioned if you can provide any further information with regards to what location these files are being opened from and saved to (E.G a network drive, cloud drive, external drive etc.) and if the problem can be replicated by saving locally we would be grateful. Thanks

Hi @PaoloT, I have to agree with Walt here it isn't entirely clear as all the keys appear to be unlabelled in the screenshot. It appears to be almost the exact same keyboard layout to my Windows 80% size keyboard, if I use this keyboard on Mac with the same shortcut config the Home/End keys both work as expected for first/last page shortcuts. I'll try a few different keyboards when possible for comparison.

If I recall correctly while testing the folder rename in V1 I'm pretty sure I ran into a 'Access to the file was lost' at least twice after renaming the folder which forced me to close the doc without me actioning anything within the app, however in V2 I did not encounter this error. It's possible that allowing this may help in certain scenarios as you say.

Hi @Hangman No worries, to be honest i'm not sure (I use both OS's but tend to gravitate towards Windows, where we are not given such luxuries 😅) but based on that it is the standard behaviour on MacOS i'll log an improvement for this file/folder renaming functionality and see what I get back.