lepr

It's a redundant non-functional button because there are only 4 channels (R,G,B,A) in your document. Version 1 had the same 5 channel buttons, but the buttons that were redundant for a given document colour format weren't so distinctively shaded.

PTT was one of the most useful additions during the AD 1 period, in my opinion. Thankfully, its multitude of modifiers are shown in the status bar. My favourite tools so far introduced by AD 2 are the Shape Builder, Knife and Cut Curves With Key Object. Of course, these tools are built on the greatly improved (other than a few teething problems) boolean operations of AD 2.

You still need to use Flip Horizontal, then the procedure with PTT is essentially what you're doing in your own method, but it doesn't need a helper line and the rotation will snap the objects together precisely.

Point Transform Tool (f) easily solves the problem without needing a helper line and messing around with rotation values and calculations.

Problem occurs for me without adjusting stroke after creation of Warp Group.

OK, I manually rasterised the Warp and got the correct result. Didn't try export to JPEG. Now when I try no manual rasterise and export to JPEG the output is also correct, so I do not know why there is a problem for you.

You can convert the source document (the one from which you will copy pixels) to the colour format and profile of the destination document, and then do the copy and paste.

Definitely happens in AD on macOS.

I am 100% certain you did not follow my instructions correctly.

That's going to look even worse if the Warp is already applied before stroke expansion. The Warp bounds are initialised to contain the paths of objects, not the extents of the strokes on the objects.

The problem affects the rendering of the stroke or outer-FX of any object, not just text.

Workaround: Before creating the Warp, clip-nest the stroked object (text in the example) inside a Rectangle with no stroke and no fill which is large enough to enclose the entire appearance of the object Apply a Warp to the Rectangle Now a rasterisation of the Warp should look correct

Nest the Mask for the left panel inside that panel instead of keeping it above all panels.

Only the Filters and Adjustments which affect alpha will have an effect on a Mask, and Halftone Filter does not affect alpha. Let us know if you still need help because there are workarounds.

Yes, your pixel values were coming from a gamma-encoded colour space and going into a linear colour space without the transform that would be necessary to maintain the appearance of the pixels. Do you still need help to work around that problem?

The 'bleaching' is what I would expect if copying pixel values from an Adobe document to a HDR document.

If you don't mind the swatches becoming rasterised when the document is exported, simply overlay the array of R=0 swatches with a rectangle which has blend mode Add and has the required red value for the page. For example use a rectangle with RGB(240, 0, 0) as the Add overlay for your page 12. I have simulated that in Photo, as shown below, but use a similar red rectangle in your real Publisher document.

Try 'Rasterise To Mask' instead of 'Rasterise...'

A solution with Compound vector object as mask: editable vector mask.afdesign

Your AD app window is too narrow to show it, but there is a Use Fill option in the context toolbar of the Pen. The automatic setting of fill to "none" happens when that option is disabled. Click the double chevron at right hand end of context toolbar to access controls that do not fit inside app window.

My results using the supplied ARW, using Serif engine and hardware acceleration enabled, on an Intel iMac running Monterey 12.6.2: AP 1.10.6 = 2 seconds AP 2.0.3 = 7 seconds

Look at right hand end of the context toolbar for the brush - you need to untick the Protect Alpha to allow the brush to affect a mask.

Workaround is to scale the document to 1 pixel wide, do the operation, then scale the document back to original size. That should give the devs a clue.

Affinity currently does not even attempt to solve the problem under discussion - non-centred stroke alignment on an open path - so how can Affinity be doing it wrongly? Affinity produces the correct results for non-centred stroke alignment on a closed path. I think you've misunderstood the thread.

The latest VS release notes say that blending modes are now respected when flattening transparency. Haven't tested it yet.