Dan C

Thanks for your report - I can confirm I've been able to replicate this here on macOS and I'm getting it logged with our team now
I'm also separately logging the platform difference between Windows and macOS, as when 'Toggling UI', macOS retains the Status Bar and Windows does not - though this might be an intentional decision.
I hope this helps!

Welcome to the Affinity Forums @bnd.lettering
Apologies, I'm not entirely certain why your post was split to a new topic as in my opinion it seems to suits the original thread you posted in - however as this post is now erring on the side of Feedback, rather than a direct question, I'm going to move this thread to the relevant section of our forums. (Feedback & Suggestions)
This will allow our devs to see and consider your post, hopefully improving the usability of brush creation in Affinity apps, in the future.
I hope this helps!

Thanks for your report @n_shcherbakov!
I can confirm I've been able to replicate this issue here and I've logged it with our development team for you now.
I hope this helps

Thanks for your report - I can confirm I've been able to replicate this here on macOS and I'm getting it logged with our team now
I'm also separately logging the platform difference between Windows and macOS, as when 'Toggling UI', macOS retains the Status Bar and Windows does not - though this might be an intentional decision.
I hope this helps!

I SORTED THE ISSUE!
1. I had chosen Bleed option on KDP when my photos didn't use it on the page. So, I chose No Bleed on KDP and assigned 0 to Bleed on Publisher.
2. I deactivated Facing Pages on Publisher. It seems KDP has issues with photo books using Facing Pages.
3. For Export, I used PDF (Print) rather than PDF (Press Ready).
4. Changed Color to CMYK as it's a print book and not an eBook.
With all that changes done, Amazon preview looked fine and i am good to go.

This.
The scripting devs are going to have to dedicate a significant amount of time towards documentation. We can't expect our docs team to document the ins and outs of an API (technically multiple APIs), it's simply not fair or realistic. Besides, we'd have to tell them what to write, which would mean pretty much writing the documentation anyway. Sure, they'll be able to present it in a way that looks good and integrated with the normal app documentation, but the devs are going to have to provide much of the content.
We're planning to use one of the many available documentation tools to do most of actual generation for us. The current favourite is Doxygen, largely because most of us have had at least some exposure to it.
Please remember too that the scripting team sometimes has to do bits of work away from scripting development. As the dev who wrote the DWG/DXF importer (and now exporter - see here 🙂), I tend to be the one tasked with its fixes and improvements. The same goes for Move and Shape Data Entry. Everyone in dev could put in those fixes, but it makes so much more sense if I do them because I'm most familiar with the code and should be able to do the work faster. The members of the scripting team do spend most of their time doing scripting work, but it's not 100%.

Thanks for trying the beta and providing these images!
The only difference I can see is the presence of the Alpha channel, in the Paint saved PNG.
When exporting your image from Affinity, as there is no transparency present in the PNG, it is saved as a 24bit image.
When exporting your image from Paint, the Alpha layer is included, even though there is still no transparency in the image, this is then technically a 32bit image.

Therefore I have opened your image within Affinity and removed a very small section of the bottom right hand corner using the Eraser Tool - introducing Transparency into the image. This means when exporting from Affinity, the image is exported at the 32bit depth, matching Paint.
Can you please try importing the below image into your simulation app and let me know if this is displayed as expected?
decals affinity export file.zip

Currently that's correct, introducing any sort of fully or partial transparency somewhere in the file will mean the PNG is exported with the 'Alpha' channel included
However this is logged with our development team as a requested improvement, in order to offer the user the option of exporting a 32bit PNG including the Alpha channel, even with no transparency present in the file itself - so I'll be sure to add your 'vote' to this option now

I had it happen with various images on my Mac that I wanted to crop. I don't remember if they were from Teh Interwebs or some of my own scans though.
Also, it wasn't just the crop alone, but upon opening an image, any initial interaction like inpainting brush, curve adjustment etc. remained invisible until briefly zooming in/out and causing a redraw.
Also, Metal acceleration was/is active. Haven't tried without yet either. 
I'll report back when I have something new to report…  

Hi please find attached, zipped whcih are named accordingly
 
exported and mspaint files.zip

Can you provide some small PNG exported from Afinity, and then the same opened and saved in mspaint, which then displays differently in the simulator? Ideally packed in a zip so that the files are not modified by saving to the forum.

I believe R C-R is referring to the following:
https://realsound.jp/tech/2023/09/post-1446012_2.html
Translated:

Hi @ttl,
Thanks for your report!
I can confirm I've been able to replicate this issue here and it's logged with our development team to be resolved asap.
I hope this helps

An interesting question as to whether it is reasonable for the software to remember the transform origin for every arbitrary selection of objects.
In your example what would happen if I decided to not to select one of the objects? Would the transform origin still be honored for the rest?
Or if I selected an additional object? Then what?
How about if the object has been the member of two arbitrary selections? And what if it already has its own transform origin, is that forgotten?
Am not trying to be argumentative, it just seems to me to be a non-trivial problem, to which I don't immediately know the answer.

Thanks, I will try that complicated coding, which in Indesign (sorry to mention this application again) is an included user friendly option. Also "Alt" is available in the URL part of hyperlinking.

Thank you Dan C
It's what I suspected. I'll go read the specs for a Windows install then.
Andrew

I'm not asking you to debug the apps - I'm asking for more information and further proof of the issue to try and determine the cause. Without a cause, we cannot fix anything.
This is why I personally have tested the issue across multiple machines (including my PC outside of the office) and even asked a member of a different team to confirm the behaviour I'm seeing, which they have done. Across these multiple tests, from multiple Affinity staff members, we have been unable to replicate the issue.
We're more than willing to continue testing the issue, but require more information and a narrowed scope of possible causes on the only machine where the issue is consistently occurring, according to your reports.
The screen recording in the first post of this thread is incomplete, your full Layers studio is not fully shown - it appears to be cut off on the right edge, as the scroll bar for the Layers Studio cannot be seen. This means I can't verify that you're scrolling through all available layers in your file.
This is not strictly an assumption, this is a corroborated confirmation between myself and every other member of the technical support team here at Affinity.
We're a small team that deal with every customer post, report and question for the retail Affinity apps - meaning we can be almost certain if an issue has been raised previously, and certainly if one is being reported by multiple users consistently.
Having checked with our team, and even by extension our QA team, no one is able to replicate this issue internally, or has yet received reports of this from other Affinity users.
This doesn't necessarily mean the Affinity app is not at fault, and at no point in this thread have I completely dismissed the app is causing this -  but all currently available information, testing and proof points towards your machine being the only one capable of replicating the issue, which would usually indicate a localised problem and not a wider bug with all Affinity apps, but I have certainly not dismissed this as a possibility.
Somewhat off-topic, but as this post was created in the Feedback section of the Forums, it's likely someone was 'thanking' you for the suggestion - but in either case this is purely conjecture and does not assist with our replication or resolution of your reported issue.
Thank you, this would certainly help our further investigations of the issue. Please be sure to include the full screen / Affinity app within this recording if possible.
I'm sorry to hear you feel this way, I have not attempted to 'point my finger' at anything, as I simply don't have enough information yet to draw a conclusion and therefore have not made any decisive statements.
Once again I'm asking for you to do these tests locally to narrow down the scope of our investigations, on the only machine that is showing this issue currently. The results of your test can help us know where else to check for a possible cause/trigger of this issue - as in all of my internal testing currently, this issue has not occurred.
If you don't wish to complete these tests, that's certainly understandably - but as above if we can't replicate the issue, then we can't report the issue to our team, and subsequently cannot fix it. Your tests would continue to help our efforts of replication, which then means we can proceed with logging the issue, etc.
At this time, no other Affinity staff member can replicate this issue and I have personally spent multiple sessions trying to trigger this issue, as well as keeping an eye out for it during other testing/uses of the app. Should we be able to repeat the problem reported in this thread internally, then we can investigate the cause of it within Affinity.
In order to replicate the issue, we need to rule out all possibilities, including the possibility that this is only occurring on your machine - which the current testing results are indicating.
We can only action anything based on the verifiable proof our team have.
All of our current testing does not yet indicate this is an issue within Affinity for all users, or all documents or all actions - otherwise we (and other users in this thread above) would have replicated this already in testing.
Therefore we must narrow down the possible cause of this issue, at the easiest way to narrow down the cause is by testing alternative options using the only machine that is yet to replicate the issue - yours.
Again, you are certainly not required to perform any further testing for us, but we unfortunately cannot make changes to the application based on an issue we cannot repeat internally.
What further testing would you like me to conclude internally?
We have tested this issue across multiple devices, Affinity apps, OS versions & documents - and none of which have shown this issue.
I will of course continue to keep an eye out for reports of this from other users, and also for this occurring 'naturally' during other document testing, but unfortunately I'm not certain what more you would like us at Affinity to do at this time, without further information or tests on your end, considering all of the above.

Thanks for your post @Timespider!
I believe the Triangle Tool is currently working as expected, and is correctly described in the Help file, as @Aammppaa covers above:
The default preset, with the Top Point set at 50%, will create an Isosceles Triangle.
The preset manager for any Quick Shape object is designed to save custom shape values the user has set - as the Triangle Tool only supports the 'Top Point' as a customisable value, this is the only property that will be retained with your saved preset.
This is why you are unable to create an Equilateral Triangle preset, as the Top Point will remain at 50% and this has already been added as a default preset.
I'll move this thread to the Feedback section of the forums for our team to see and consider your suggestions for the Triangle Tool itself - but at this time I'd recommend using the Polygon tool for Equilateral Triangles, as required: 
2024-01-11 12-53-57.mp4
I hope this clears things up

Note though that it (both versions 1 and 2) still accepts multiple email addresses separated by a semicolon (the delimiter might depend on regional settings?) so it is not just the number of addresses as parameters, but possibly a deliberate omission of cc and bcc fields (probably not very often needed, though bcc can be quite convenient sometimes).

I'm not personally aware of any changes between supported Email Hyperlink properties between V1 and V2, however testing the same email hyperlink shown in your above screenshots fails to be accepted in 2.3 - it appears as soon as there are multiple '@' symbols within the Hyperlink, Publisher deems this invalid.
I'm getting this logged with the team now, as it may be an oversight of the panel, rather than a decisive removal

My apologies, in further testing it appears as though this issue is dependant on the Tone Curve Develop Assistant setting - which I had not realised was different in my beta version compared to the retail version.
Setting the Tone Curve option to Take no action will stop this occurring when developing to 32bit, as shown below:
2024-01-11 11-01-51.mp4  
I'll be sure to update the development log with this information now, as clearly further improvements can be made by our team. Thanks for letting us know

I'm not personally aware of any changes between supported Email Hyperlink properties between V1 and V2, however testing the same email hyperlink shown in your above screenshots fails to be accepted in 2.3 - it appears as soon as there are multiple '@' symbols within the Hyperlink, Publisher deems this invalid.
I'm getting this logged with the team now, as it may be an oversight of the panel, rather than a decisive removal

The mailto link needs a slightly different format( "email address"?subject="subject", using %20 for 'space' characters in the subject), as shown below:
email@address.here.com?subject=This%20is%20a%20test
 

Which when clicking on the link in the exported PDF, provides the following in Outlook for me:

I hope this clears things up

The mailto link needs a slightly different format( "email address"?subject="subject", using %20 for 'space' characters in the subject), as shown below:
email@address.here.com?subject=This%20is%20a%20test
 

Which when clicking on the link in the exported PDF, provides the following in Outlook for me:

I hope this clears things up

The mailto link needs a slightly different format( "email address"?subject="subject", using %20 for 'space' characters in the subject), as shown below:
email@address.here.com?subject=This%20is%20a%20test
 

Which when clicking on the link in the exported PDF, provides the following in Outlook for me:

I hope this clears things up