NathanC

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.

Hi @anto, I've logged this with the developers.

Hi @keiichi77, Unfortunately I don't have that exact model to test but i've not been able to replicate an issue with this on an Intuos BT S using High Precision Mode within Designer. However, I did find that in the Wacom driver Pen settings if I had the 'Tip Feel' slider all the way to the right hand side (firm) this would cause extreme variance on the stroke size, with the brush size variance being very similar to what's shown in your screenshot dependant on the pressure applied on the tablet. If I then set this Tip feel slider back to the middle position this gave me a good balance, so it may be worth checking what you have this set to. I'd also suggest checking the Pressure profile of the Size Jitter in the dynamics tab of the brush you're actively working on and trying a few different brushes for comparison.

Thanks to all for providing additional information and recordings, I've now replicated the issue and logged it with the developers.

The thread is tagged with the issue ref, so if there are any updates to the issue internally the Serif Info bot will automatically reply to this thread. 🙂

Hi @Hangman & @MikeTO, I couldn't find any reference to this internally, so I've now logged this inconsistency with the developers.

Hi @Jordan Becker, Many thanks for providing detail, i've logged this accent issue with the developers to look into further. 👍

Hi @David Battistella, The 'X' button highlighted in your original screenshot is used to clear the active page selection in the 'manage pages' dialog, to navigate out of the dialog you can do so via the '<' arrow at the top left hand corner, highlighted on the screenshot below.

Hi @Hangman, In V2 I wasn't finding that the app was immediately forcing a 'Save as' following a containing folder rename, this would only occur at the point at which I attempted to save the document, this was just using a basic folder in Documents that contained a few .afdesign files, are you getting this immediately? Is this working differently for you in V1? I've gone back to V1 to compare the behaviour on an .afdesign file and the folder rename in V1 works as expected, but attempting to modify and save the file following the folder rename forces a 'Save As' in a similar fashion to V2, albeit without reference to a ~lock file. This part is now handled better than it was in V1, if you were to open a file > rename the folder which contains the file > Try to use the 'Edit in' function the app prompts the below error for me and forces a document closure. In V2 you're able to still stay in the app and also 'Save as' Although I agree that the error that prompts in V2 could stand to be a little clearer. I do think how it's currently handled by prompting the 'Save as' option is expected when you attempt to save the file, and while looking into this I was also interested to see what PS and AI do with their respective formats, which I found following a folder rename and subsequent save both failed on the file could not be found or considered it 'read only' and forced a save as.

Welcome to the forums @TOMMIC2, I've managed to successfully recover your attached file and have PM'd you a copy of the document. Unfortunately issues like these can be tricky to replicate and therefore log and i've not been able to re-produce this via a focus merge. Issues like these can be specific to the local user environment so I've provided some general guidance below to help reduce potential file corruptions and crashes. Keep your app updated to the latest version (The latest version available is v2.4.0) Try toggling Hardware acceleration off under Edit > Settings > Performance and then restart for this to take effect If your documents are stored on an external location (E.G External Drive or a Network Drive) try opening and saving the document to local storage instead. If you're still able to replicate a crash and/or file corruption by following certain steps, it would be beneficial if you could provide us with some sample files along with the step(s) taken to result in the problem. Thanks

Hi @David B., Many thanks for providing a detailed explanation, i've compared the shortcut behaviour on iPad to Publisher on Mac made some observations below, my setup for testing these was a simple text frame containing three paragraphs. CMD + Left/Right arrow moves the caret to the end of the current line when the app shortcuts are set to Apple Defaults on Mac, however the Serif Default is that it moves to the beginning of the next word, which it appears that the iPad uses. These text input shortcuts can be freely re-binded on Mac however it doesn't appear to be possible on iPad currently as the changeable shortcuts are more limited, and there also isn't an option to change between the Serif and Apple Default shortcut sets currently, hopefully the current set of bindable shortcuts on iPad will be expanded. I can see that the CMD + Right Arrow does nothing on subsequent uses so I'll get this logged. Same as above this is down to a difference between Serif and Apple Default shortcuts, but I can see that the Right arrow fails to work on subsequent presses so i'll mention this on the same report. The Apple default on Mac is that ALT + Up/Down Arrow moves between the first line of each paragraph, and including the shift modifier highlights those respective paragraphs. I can see that this does work the same on iPad, but only for one single press and subsequent presses of the same key do nothing so i'll log this same as the above. For reference, CMD + Up/Down Arrow moves the text caret between the start and end of the text frame/story. I'm also seeing this failing on iPad but working on Mac so i'll log this separately.

Hi @Chris F, Many thanks, we can replicate the issue from scratch using your provided files so i'll add your files to an existing bug report we have logged internally regarding this profiling/banding issue.

Hi @Brian Alexander, Thanks for following up and providing the screenshot, the 'Tools' appearing at the top left hand corner with empty swatches is really strange. As Alfred mentioned above could you clarify what happens when you try and Disable Hardware acceleration in the clear user data dialog, is that window also freezing up and crashing? I'd also suggest following the below to factory reset the app's local settings manually for both MSIX and .EXE versions: Close All Affinity apps Press WIN + R to bring up run and enter the following: %APPDATA% In here there should be an 'Affinity' folder, rename it to 'AffinityOld' Press WIN + R to bring up run and enter the following: %USERPROFILE% In here there should be an '.affinity' folder, rename it to '.affinityOld' Launch Photo again If the above fails since we don't have any crash reports to work off, could you provide a copy of the Event viewer System and Application logs after encountering the app freezing and crashing? The FAQ below details how to find them. Once you have saved both to .EVTX files, if you could upload them here that would be great: https://www.dropbox.com/request/J57X2Hvsn0n5XPdWZE2f Thanks

Hi @wintermute, Is the Preflight panel Check set to 'Live'? If the Preflight panel is not live and a linked resource error was previously flagged on a manual check which has since been corrected it won't update until you either do another manual check or set it to Live. If it is already Live, we'll need some more details as Walt has mentioned above.