Sean P

Hi Vehmann, I was actually re-testing this fix yesterday and unfortunately I'm still not 100% happy with the fix. It is now working if you use the 'Colour Handling: Performed By App' option within the Print dialog (which is the default option), however switching to 'Performed By Printer', it is still problematic, so I've had to reopen the issue. You should see the partial fix in the upcoming 2.4.2 build (keep an eye on the Beta forums if you wish to try it out), however as I said above, there are some instances where it is still incorrect, so it has been reopened for further investigation.

You're more than welcome! If you're using the Vector Flood Fill Tool then it is definitely worth learning about the Appearance Panel, as depending on your VFF options, you can end up with multiple fills on an object, so that certainly sounds like what happened here.

I suspect the Bitmap Fill would have created a second 'Fill' in the Appearance Panel, leaving the original colour present. You can delete the empty fill from the Appearance Panel which will select the red fill allowing you to edit it. Alternatively you can click the red fill in the appearance panel yourself to select and it it (the white dot should be present next to it letting you know its the actively selected fill).

Hi Anto, Your crash reports were passed onto development, but the supplied reports were not able to provide sufficient information into the cause of the crash (and no ChatGPT doesn't say anything new that isn't already in the crash reports). Unfortunately without a recipe, there is nothing that we're able to do, to really identify the cause and solution to your crash. Unfortunately this is often the case with one off, non repeatable crashes - the reports cannot always identify a cause. It does seem like you keep doing similar things, so its worth trying to try and narrow down what you're doing to get a reproducible recipe, but realistically without that, there isn't anything development are likely going to be able to do. For example in this thread below you have given us ZERO (not even what part of the app you were using) information on what you were actually doing at the time of the crash. Whilst crash reports can help narrow something down they don't make people into mind readers. As we have said numerous times before please try to give us much information on what you were doing at the time. We don't ask for this information for no reason, and unfortunately sometimes we're just unable to reproduce the crash you're getting - its not that we don't believe you, but attempting to fixing a crash that cannot be reproduced makes things a lot harder, let alone one we have almost zero information on.

My apologies - I thought you meant you had seen the issue listed on the list of issues fixed in 2.4.0 (the thread I linked to), but in context with your last post I understand that is not what you meant. As tzvi20 has mentioned above, the issue is still an open issue in our issue tracking software and is still with the development team to be fixed. Unfortunately, we do not have any control over what issues get fixed by development, and in what order. However, what we can do is keep track of the amount of reports each issue gets which then gets used as a factor for deciding which issues require fixing. Again I can only apologise that this is still an issue for you, I will bump it again with development and try to bring some attention to it.

Hi Satopian. Which issue in the fix list are you referring to? This issue is still currently with development, and I don't see any reference to it here:

Hi bbrother, This is something we're aware of and is logged with development to be fixed. Regarding Hangman's video - the only reason the length affects the Stroke Width is that Hangman has 'Scale with object' enabled in the stroke panel, so when the object is resized, the stroke is scaled relative to that to try to ensure the scale of that stroke is maintained with the resized object.

Hi Eelco, Welcome to the Affinity forums. As Hangman points out this is a known issue and occurs when the caret is placed in the Layer Name field. Selecting any of the other checkboxes will cause the app to crash. If you press Return after using the layer name field it will accept the value and prevent the crash when using the checkboxes. With that said the crash has been fixed by development and will be included in 2.4.1 This tick box will cause the same crash as the regex one if the caret is placed in the name field as mentioned above.

Thanks anto - this is still with development to be fixed. I've linked this with your original report, if you click the tag on this post you should be able to find your original issue.

Thanks Anto, We have since been able to reproduce this and the set up to reproduce has been a little bit finicky - however I've updated the issue with a new recipe for 2.4.0.

You're welcome! I have actually been able to reproduce it 2.4.0 unfortunately, but have found the steps to be picky and also had to force the external screen to be 'Main Display' and without doing that I wasn't able to reproduce the issue.

Hi Petar, There have been some changes in this area regarding 2.4.0 and we believe some of the ways to trigger this issue has been fixed. Would you mind retrying it for us and letting us know if this is still an issue for you please?

Provided you've not downloaded the app from the Microsoft Store you can. Please see the links below for the relevant installers, though you will have to first uninstall 2.4.0: affin.co/designer2-win-dl affin.co/photo2-win-dl affin.co/publisher2-win-dl If you have used the Microsoft Store, you can register your purchase against an Affinity ID and then use the builds above to sign into that ID and run those builds. For mac readers/users the equivalent links are: affin.co/designer2-mac-dl affin.co/photo2-mac-dl affin.co/publisher2-mac-dl

Hi AlesMZ, Thanks for letting us know. I can confirm that this is something we're aware of with canvas rotation and is logged with development for improving. However unfortunately I am unable to give any timeframes on any potential fixes.

Thanks Anto, I'll get this bumped - its not a new issue, but occurs when both are floating in the same area - the Tools Panel should really have 'Keep on Top' enabled but it doesn't, so when focus changes to the document window it appears on top.

It is nothing to do with GIFs as far as I can tell. Whilst the file appears to have come from EZGif it is a JPG. However I can reproduce it when printing regular JPGs on a CMYK document.

Thanks for the document! I can indeed reproduce it with your document and would agree with it being down to CMYK. I'll get it passed along to development to be fixed. Unfortunately I'm not syet ure exactly what has changed to cause the regression. Thank you for taking the time out and letting us know.

Hi Vehmann, I've just tried it using an RGB/8 document with an sRGB profile and they appear to be fine for me when printing in 2.3 and 2.4 (I don't have a scanner so you'll have to make do with a photo, where I've tried to reduce the glare). Note on the zoomed in picture, 2.3 is on the left and 2.4 is on the right). I've attached the afphoto file I printed using a Sharp MX-2651 Colour Laser Printer. Could you save a copy of the Affinity document you're printing and attach that please? PrintTest.afphoto

Please create a separate thread for this in the bugs forum and attach a video demonstrating the issue please.

Hi Vehmann, What printer model are you using? Could you attach a copy of the file that is printing incorrectly for you please, and if possible a picture of the results you're getting.

Unlike a Group a Layer object is never selectable on the page, instead it will always select the contents inside it, so the Layer will not be clickable from your design. And because Edit All Layers is off it will mean you can't select anything outside of that layer.

Hi Vehmann, The red tint on the print dialog means that your document is too big to fit the page size set by the printer. I would check your printer drivers to see what the default page size is, alternatively you can change it using the Layout > Paper Size option (like I did in the second screenshot below). Alternatively you can use 'Fit Type: Fit to Printable' to resize it so it fits the defined paper size. A4 document with page size defined by printer driver A4 document with Paper Size overridden to be A5 - note the tint as the A4 is too big for A5.

Hi Jhtucker100 Welcome to the Affinity forums, thanks for letting us know - we've reproduced the issue and it is now with development to be fixed. It is worth also noting that unfortunately an Undo doesn't bring the missing strokes back in this instance, so you would have to reload your file.

Please try to include a video of the entire screen as we like to be able to see the whole picture (for example I cannot see what your Move Tool Auto Select settings are), however by what you've described and from what I can tell from the Layers Panel it sounds to me like this behaviour is as Designed. You have disabled 'Edit All Layers' - this means your selections will be restricted to objects on the same Layer as the current selection, so if you have a object inside that layer selected, you will only ever be able to select other children inside that Layer, which is likely making it appear as though the selection has broken. EditAllLayers.mp4

It is only once for the whole suite!