CM0

Any updates on this issue?

I have addressed this substantially in the past. I have logged a substantial number. Each one often becomes a battle with the mods or others on the forum to even understand the issue, which I'm certain would be immediately understand by a dev. It is time consuming and exhaustive. Furthermore, Affinity has no priority system. They have no idea what is the most important items to fix. You cannot properly extract this information from a public forum. You need a proper customer facing tracking system. FWIW, development processes was part of my day job, so yes I'm opinionated here. If I have a hundred bugs, Affinity has no idea which ones are the most important to me. Since the likelihood of any ever being fixed is already nearly zero, if I submit them all then then chances of the most important ones being fixed first is even less likely. Therefore, I started only just mentioning the absolutely most painful. Start fixing the ones I've already submitted is the best way to fix this. Then you have ensured it is worth my time to submit the rest.

I have a log of so many bugs I've never even reported because I lost faith in them ever being fixed.

Any updates on this?

So, implying that Illustrator seemed to handle it ok? BTW Inkscape uses Python for scripting. Not sure if you have tried that.

I want a high performant scripting language that uses JIT. Affinity has always prioritized performance. I've never considered the Affinity app as intended to be scientific level of accuracy or any other application in its class. What is the end user use case? Does Illustrator support the use case(it uses JS)?

It is the Python Decimal module. However, it is still done in software. So it's performance is slow in comparison. It is not useful in general for graphic applications. This kind of accuracy is for mostly scientific purposes.

Spline runs in the browser - https://spline.design/#features Graphite runs in the browser - https://graphite.rs/ Modyfi runs in the browser - https://www.modyfi.com/ Don't worry, this is not an issue.

I just checked and this still is not fixed in RC1. It is very disappointing that af-399 was marked fixed, but in reality it was only a partial fix. All that needs to happen is the same fix applied for erase mode. I fear it will never be fixed if not addressed while we had attention on this issue.

I couldn't agree more. There are so many bugs that don't even have work arounds. Fixing bugs is like getting new features. You can do things you couldn't do before.

I have made this same comment so many times. I also emphasized this on every user survey. Fixing all the bugs is like getting new features because some things are so broken they can't even be used. It is so frustrating. One of the long standing bugs that was important to me was finally marked fixed this release. I was was so excited, but then I tested it and it wasn't fixed. Reported it as not fixed, so now there is a new bug logged that probably won't get fixed. I would really love a major dedicated bugfix only release.

Any updates on this one? Really hoping it can get included as the fix af-399 was targeted for this, but missed this use case. Hopefully the same fix is straightforward to apply.

Sure, attached is the same example switched to using erase mode as a mask. passthrough mode blending using erase.afpub

This was marked fixed; however, it is not fixed for erase mode. When using erase mode as a mask, the passthrough problem still occurs.

Please note this is not fixed for erase mode that I documented above. If you use erase mode as a mask, this problem still occurs in passthrough mode.