lepr

Yes, enable Transform Mode in the context toolbar of Node Tool. That draws a bounding box and transform handles around selected nodes, and then the Transform panel can also be used for rotating and shearing in addition to always being usable for translating and scaling. There is an adjacent button for Enable Transform Origin. However, the TO is buggy in 2.0.4 and 2.1.0 beta, with its location becoming offset when transforms are performed. The TO behaves correctly in In 1.10.6.

The alignment menu commands default to using the selection bounds, but they will observe a key object. To mark the key object, opt/alt-click one of the selected objects after initially selecting it. That can be done after all of the selection is made, or at any moment during the selecting process. The key object is displayed with a thicker than normal outline. Normally, the key object can be marked in the document view or the Layers panel, but there is a current bug in the macOS apps which prevents marking in the document view when "Allow selection to consider items in a Group" is enabled.

Thanks for the file. The file is very unlike your opening example. It contains no "Unassociated Alpha" channel, and instead contains 4 hidden text objects (the numeral 8s) which I presume are supposed to mask or clip the blues Pixel object. Anyway, we can work with that. To get a straight RGBA TGA or PNG export from Affinity, the alpha needs to be a raster Mask at the top of the layer stack in Affinity. You are going to convert the 8s to a raster Mask. Enable visibility of the four text objects then press cmd+G to group them (do not include the Pixel object in the Group). With only the Group object selected, do Select > Selection From Layer And Delete. The 8s will vanish and marching ants will appear where their edges were, indicating a pixel selection. Ensure the Pixel object is not selected in Layers panel because, when a Mask is added, we want it at top of the layer stack and not nested inside an object. Do Layer > New Mask Layer (or use the mask button at bottom of Layers panel) to create a raster Mask from the pixel selection. Optionally deselect the pixel selection by pressing cmd+D. A raster Mask will now be stacked above the Pixel object and a TGA or PNG can be exported. I have attached an Affinity document with history that you can rewind and step through, and an exported TGA. dignumber8.afphotodignumber8.tga

Use the little button at bottom left of Layers panel to disable Edit All Layers, and then the Artboards will stop stealing the "global layer".

Then attach a TIFF, as I requested. I want to show you with one of your own files so there are no ambiguities.

That is because of the additional channel named "Unassociated Alpha". Affinity's RGBA TIFF output is going to be premultiplied, anyway, which is of no use to you. I can give you a workaround if straight RGBA output to TGA or PNG format is acceptable (even if not ideal) to you. Attach a problematic TIFF if you want to know more.

No, Affinity insists on adding the Mask above a selected Adjustment. The mask placement options in the Assistant make no difference when the selected object is a Mask or Live Filter.

@Guillermo Espertino: By now, you should be doing your own experiments to ascertain or discredit my (and others) claim that Affinity is not storing premultiplied RGB values in pixels and is instead only setting RGB to zero where alpha is zero while storing straight RGB values when alpha is any other value. If you are struggling to do so, I can try to help.

There are people who wish to use Affinity for "doing some channel packing stuff for games."!!! Those people are frustrated by Affinity setting RGB to zero where alpha is zero (which is not the associated alpha (a.k.a. premultiplied alpha) that you keep writing about) except when particular unintuitive workarounds are employed.

Your example is deeply flawed. You have chosen to use one of the only eight RGB colours, out of the available 16,777,216 RGB colours, that will be faithfully restored by the division following the multiplication. @NotMyFault was correct. Check the attached file which uses a gradient from black to red instead of your solid red. gradient multiply divide.afphoto

Nowhere did I say Affinity never performs multiplications. That would be ridiculous. It's late here and I'll be busy during the day tomorrow, but tomorrow evening I will provide evidence of Affinity setting RGB to zero where alpha is zero while it is doing nothing to RGB where alpha is greater than zero.

Filling an unfilled region of the source objects results in the generated shape being placed at the very bottom of the document or Artboard's layer stack instead of just below the lowest source object. Not sure that's an actual bug, but it seems wrong to me.

No, premultiplying is not happening in that situation. Affinity sets RGB to zero where alpha is zero in several of its operations (possibly to improve data compressibility, but Serif haven't commented on the reason as far as I know) which you have wrongly assumed to be the premultiplying of RGB by alpha. Affinity's TIFF export with transparency does premultiply after the document RGBA composite has been rendered without premultiplication. You won't circumvent that with the mask on top trick, of course.

The destination document has physical units, namely millimetres. We have been told that its PPI is half that of the source document. In the video, the object's physical size is being correctly maintained because the destination document has physical units. However, its top left corner physical coordinates are being scaled by two, as if the destination had pixels for document units. I've now tested the pasting behaviour in Designer 1.10.6, 2.0.4 and 2.1.0 beta. All are misbehaving in the same way. When the destination document has pixels for document units, pixels size and pixels origin of a pasted object are correctly maintained. Good so far. However, when the destination document has physical document units, physical size is correctly maintained for a pasted object, but the object's physical origin is scaled by the ratio of source PPI to destination PPI because its pixels origin is maintained by mistake.

When destination document units is pixels, the pasted object should maintain size and top left location measured in pixels. When destination document units is physical, the pasted object should maintain size and top left location measured in physical units (in Designer and Publisher, but not in Photo). There is a bug when the destination document units is physical and the source and destination have different PPI: the pasted object's size is correct but its top left location is wrong. See my next comment for further information. Edited once again: there is a bug.

Not my problem. I told you how to do it with TGA and PNG. I don't know what format you want to do it with.

LOL You wrote: I proved you wrong with your own example document. There is no need to "perturb" the alpha channel to avoid alpha zeros when you know how to export intact RGB with alpha zeros.

There is no need to avoid alpha zeros in either 8 bpc or 16 bpc if you intend to export to TGA or PNG. The key to making Affinity export intact RGB where alpha is zero in TGA or PNG, is to have the alpha as an object at top of the layer stack, as you did with the mask. You could have put zeros in the mask instead of using a tiny value; an exported TGA or PNG would still have intact RGB. Try exporting TGA and PNG from this version of your 16 bpc document with zeros painted across the mask: RGBA new.afphoto Alternatively, try exporting from this 8 bpc version: RGBA new 8bpc.afphoto Open the exported files in Affinity and fill their alpha channel to reveal the intact RGB, even where alpha was zero.

Here's another workaround. Better than nothing until the bug is fixed. Convert the Mask to a greyscale Pixel object and give it an intensity-to-opacity mapping in Blend Options (see screenshot). That Pixel object will act as a mask when mask-nested in an object. Any adjustment can be nested in the "mask", with the adjustment affecting the "mask's" colour channels instead of directly affecting alpha. Test workaround 2.afdesign

It's certainly a bug. A workaround in your example document is to stack the Levels above the Mask instead of inside the Mask. Test workaround.afdesign

The arrow ends can be a separate clipping shape containing a set of staffs Symbols. A minor complication that's outweighed by the convenient editing enabled by a live contoured path. The attached document, loosely based on yours, is much more easily edited, in my opinion. new ade_score_clipped_stroke_symbols.afdesign

Contour Tool significantly simplifies that workflow by providing a live expansion of a base curve: no need to keep a duplicate base curve for future editing no need to do an expansion no need to move clipped objects from inside an old shape to inside a new shape no need to delete an old shape

You're welcome! I added a document to my message above.

Your yellow clipping object appears to be an open path with no fill and a yellow path with stroke set to "Draw stroke behind". Alternative solutions (use one or the other, not both): use Expand Stroke command to convert the path to a yellow-filled unstroked shape, and put the purple staff inside it use Contour Tool to give the path thickness, and swap fill and stroke colours (and optionally set stroke width to zero although it will now have no colour anyway) The advantage of the latter solution is the original path is retained and is easier to edit than the shape created by Expand Stroke. staffs.afdesign

If that change were made, it would create an inconsistency between object dragging operations and guide dragging operations. Then it could be argued that making the same change for cmd-dragging of objects would also improve consistency on two levels: creating consistency within object operations and restoring consistency between object operations and guide operations. Actually, I'm happy with how cmd-dragging and opt-dragging an object has been working for years, and similarly happy that exactly the same modified dragging is now available for guides. My vote would be for leaving cmd-dragging as it is in the initial beta for 2.1.