Chris B

Thanks for the update. I will test the fix once I get a build. Hopefully, you won't need to worry about all this. I will let you know as soon as I can.

Hey @Art51 I think I have reproduced this. On an 8bit document with OpenGL enabled and Metal Compute disabled I see similar to what you are seeing. Changing some of the brush settings can make the result vary slightly. I was using our XP-Pen Artist 12 and tilting the pen with very light strokes seems to be the trigger for me also. Keeping the brush upright does not display the issue. It's almost like it's just choosing random pixels and filling them with a darker shade than the majority of the other pixels. I will log this with dev and see if they have any idea what's happening.

Hey @Art51 I will try to investigate this next week when I can access similar hardware to yours. I haven't been able to reproduce this on my M1 MacBook so far. I will report back once I've tested this thoroughly.

That might be an idea - especially for large documents like yours. We only deleted the index at the end - the document was too big for us to go through all of it so we just chopped the last x amount of pages off. I have just looked at the bug report I made and a developer has already began some work on this so hopefully if we get a beta build, we can re-test this soon.

I've passed this back to the developers for you. Apologies that this was not responded to by staff.

We just deleted the index and then added a single page to move the Author page to the right side. It looks like the crash was occurring whilst the index was updating itself after inserting the new pages so I am surprised it still happens when the index is no longer present.

Scratch that - it does crash on Windows. However, we have found that the crash seems to relate to re-doing the Index after adding the pages. We simply deleted the Index pages, added the page where you wanted it and re-did the Index and the file was fine. Can you give that a go and see if it works for you? This file will still need logging with the developers though.

Thank you for the file. I managed to reproduce the crash on macOS - it seemed fine on Windows so I can probably try and add the page and send it back to you and see how you get on. This will need logging with the developers though. As for AF-279, I have bumped the bug report with the developers for you.

Hey @philipt18 Here is a private Dropbox link that only development can access - https://www.dropbox.com/request/gsgQbTlp45hgQ7XX4LgH Please let me know once you've uploaded the files as I do not get notifications for Dropbox - thanks!

Hey @DigitalVisuals It seems to be working as expected for me - any chance of a screen recording or a screenshot of the workspace so I can see what settings you are using?

Hey Affinity-Inspiration, This has been a long-outstanding issue since V2 was released for iPad. I think your argument for not being able to see the values gives it some more weight. I will add your feedback to the existing report. Thanks for posting.

Thanks. The logo is 16,667 x 1,892 pixels which isn't grossly enormous, however, it is 970dpi which is where I think it is falling over. I would perhaps go through the Resource Manager and rasterise any instance of this logo and then once rasterised, drag that to the Assets Panel and use that for any future logo placements.

Hi anto, You can override this by holding Ctrl but without the modifier, your mouse is against the middle of the stroke and of course, will make the width of it narrow. Or is your issue with this the fact that simply dragging down narrows the width and you are expecting nothing to happen?

We should be coping or warning before we crash. Would it be possible to share this with us privately? If it is possible to share it with us, I've created a secure Dropbox folder that only the development team can access: https://www.dropbox.com/request/l8wLSNzchLOMfzo0akJj Thanks

What kind of visual are we talking about? High DPI or resolution image? Was it File > Place or did you use the Place Tool?

I believe the cap issue is already logged so I will update that. I'm just looking at the other one again now.

Hey @Port3f9 welcome to the Affinity Forums. Would it be possible for you to share your file with us at all? We would be looking for the native Affinity file format. Or at the very least a screenshot of your export settings. I have made you a private Dropbox folder to upload the file to: https://www.dropbox.com/request/miJiN8v3kaqiu8MUw7Ha Thank you.

Nope that's a legit bug report - little details matter Thanks Hangman, I'll pass it on (and probably get shot)

If it only affects the Beta, which might be due to the recent changes to Expand Stroke (regressions, etc.), log it in the usual beta forum. Expand Stroke is not a new feature so it should be reported in Other New Bugs and Issues in the Betas. If it affects Release and Beta, please log it in the usual Release forum depending on OS. We are in 'Other New Bugs and Issues in the Betas - For testers to report any new bugs that don't affect the release build, and which are unrelated to the new functionality.' So you should be able to post here. Thanks!

Thanks Hangman - I missed this one 😔

Fair comment. I will log this - ta

I'm still not seeing that with your recipe. I had done an app reset this morning though...

Thank you. I have been able to reproduce this so I'll get it logged.

As per usual, if you have any issues outstanding with Expand Stroke, please create a new thread with the title of the issue, steps and files to reproduce.

Can we please keep this thread on topic. This thread is about the Stroke Width Tool, not about what is still broken or fixed with Expand Stroke. I've moved the Expand Stroke discussion to a new thread