Jump to content
You must now use your email address to sign in [click for more info] ×

NathanC

Staff
  • Posts

    2,738
  • Joined

Posts posted by NathanC

  1. 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.

  2. 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.

    image.png

  3. Hi @Like, would like more if…,

    21 minutes ago, Like, would like more if… said:

    I notice that the number of layers has not increased in the original states to match the number in the final added artwork - is this the issue? Shouldn't an update to a state capture all the content of the document?

    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.

    image.png

    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.

    21 minutes ago, Like, would like more if… said:

    Is there a reason why you can't rename a query or captured state? 

    Not sure, but I agree that it is unusual that it doesn't appear to be possible, I'll log this separately.

  4. 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

  5. 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

  6. 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

  7. 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

  8. Hi @PaoloT,

    11 hours ago, PaoloT said:

    I use this keyboard. You can clearly see that it has a Home key!

    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.

  9. 17 hours ago, Hangman said:

    I was curious as to whether this may (or may not) help in situations of possible file corruption and/or 'failed to save' error messages by allowing the problematic file and/or containing folder to be renamed while the file is still open effectively creating a live copy of the original?

    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.

  10. 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.

  11. 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?

    22 hours ago, Hangman said:

    Folder renaming with open files is allowable on macOS and works without issue in v1 but of course that was before the introduction of lock files

    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.

    image.png

     

    22 hours ago, Hangman said:

    So subsequently the file can't be opened in the other Affinity Apps using Edit in...

    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.

    image.png

    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.

  12. Welcome to the forums @TOMMIC2,

    I've managed to successfully recover your attached file and have PM'd you a copy of the document.

    On 3/10/2024 at 3:14 PM, TOMMIC2 said:

    Bug reproduction steps:

    1. It seems that the processes induced the crash are a little bit complex, but are normal. (One is Focus merging with 3 images, the other one is Sharpen filters)
    2. When I start the process, the Photo suddenly dies with no responce. I have to manually close it.
    3. I re-open the Photo and re-upload the .afphoto file that saved earlier. The Photo uploads it and the image and layers are shown as usually, but then it called 'This file seems been broken, we must close this file now.'
    4. When I press the 'Close' button, the .afphoto file closes and nothing can be done. It means this file has been destroyed.

    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 

  13. 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.

    On 3/6/2024 at 8:16 PM, David B. said:

    • [cmd]+[right arrow] should move the cursor to the end of the current line. Instead, it does nothing or moves the cursor to the beginning of the next word (and then does nothing on subsequent uses).
    • [cmd]+[left arrow] should move the cursor to the start of the current line. Instead, it moves the cursor to the beginning of the previous word (identical behaviour to [alt]+[left arrow], which works as intended).

    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.

    On 3/6/2024 at 8:16 PM, David B. said:

    • [cmd]+[shift]+[right arrow] should select text from the cursor's current position up until the end of the current line, while moving the cursor there as well. Instead, it only selects text and moves the cursor to the beginning of the next word (and then does nothing on subsequent uses).
    • [cmd]+[shift]+[left arrow] should select text from the cursor's current position up until the start of the current line, while moving the cursor there as well. Instead, it only selects text and moves the cursor to the beginning of the previous word (identical behaviour to [alt]+[shift]+[left arrow], which works as intended).

    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.

    On 3/6/2024 at 8:16 PM, David B. said:

    • [alt]+[up arrow] should move the cursor to the start of the current line, if the cursor is not already at the start of the line. If it is, it should move the cursor to the start of the previous line. Instead, it moves the cursor to the very beginning of the whole frame text / artistic text (identical behaviour to [cmd]+[up arrow], which works as intended).
    • [alt]+[down arrow] should move the cursor to the end of the current line, if the cursor is not already at the end of the line. If it is, it should move the cursor to the end of the next line. Instead, it moves the cursor to the very end of the whole frame text / artistic text (identical behaviour to [cmd]+[down arrow], which works as intended).
    • [alt]+[shift]+[up arrow] and [alt]+[shift]+[down arrow] have the same problem (with selection, respectively).

    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.

    image.png

    On 3/6/2024 at 8:16 PM, David B. said:

    • [ctrl]+[d] should act like the [del] key (removing the character immediately to the right of the cursor). Instead, it does nothing.

    I'm also seeing this failing on iPad but working on Mac so i'll log this separately.

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.