,,,

C, M, Y & K to CMYK.afmacro

Yes. One way is to use the Channels panel to transfer the lightness of each monochrome image to the respective L, A and B channels of a new Pixel object. Place the three monochrome images into a LAB document and use Rasterise command to convert them to Pixel objects. Name the Pixel objects "L", "A" and "B" (without the double quotes). Run the attached macro which will generate a composite Pixel object named "LAB". L, A & B to LAB.afmacro

I know what it says and does and doesn't do. I was responding to a specific comment by @prophet, and even quoted the comment to make that clear.

Yes, it is a new feature in the v2 apps. Note that it should be named "Allow Selection to Consider Nested Items" since it makes clip-nested objects be directly selectable, in addition to group-nested objects. The button only appears in the context toolbar of the Move Tool, and only when something is already selected. In my opinion, the button should be in the main toolbar since we might want to toggle that selectability when using any tool that can select objects, and we shouldn't need to already have a selection in order to access the button.

Good point, although it's likely to be something that hasn't been implemented yet, rather than a bug. Exactly the same problematic lack of control over the candidates for 'select same' has been pointed out by other users. Hopefully, there will be improvement sooner rather than later.

You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform. There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound. Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded. When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.

Thanks! I'll take a look later today and come back to the thread.

Yes, that's how AD1, AD2 and APub1 work, but APub2 is broken. APub2 currently always maintains the pixels dimensions and changes the physical dimensions when PPI is changed, regardless of the document units being pixels or physical. APub2 currently does not allow the user to maintain the document's physical dimensions when changing PPI. It seems illogical for that loss of functionality to be a design decision of the developers, therefore it's most likely a bug. As I said earlier, AD and APub do not resample Pixel objects when the document's pixels dimensions change, therefore there is no "document crippling" and no reason to mention resampling. Instead, these apps nondestructively scale Pixel objects when the document's pixels dimensions change. Only Photo destructively resamples Pixel objects when the document's pixels dimensions change, and there is a Resample checkbox in Photo.

Selecting a Layer never directly selects the member objects. It is sufficient for changing the fill and stroke of members of the Layer because the app has been coded to propagate such changes to the members of the Layer. In the first reply of the thread, Walt told you how to quickly select all members of a Layer: with Edit All Layers disabled, select a Layer (or a member of the Layer) then press cmd+A (ctrl+A on Windows) Edit: anto has posted good videos now

All the following in AD2 on macOS. Both your documents: subtracting rectangle from text -> good geometry result (but old bug of fill wrongly set to none needs to be fixed) subtracting rectangle from "Windows curves from text" -> messy geometry result If I manually convert your text to curves (which happens on the fly, anyway, when using text in a Boolean operation): subtracting rectangle from "macOS curves from text" -> good geometry result (and correct fill) So, this is a further example of the garbage Boolean output appearing to be provoked by something about the text-to-curves output of the Windows apps only.

The TIFF contains two versions of the image: 1200 x 800 px, 16 bits per channel, sRGB 300 x 200 px, 8 bits per channel, no profile Looks like Affinity loads the first image, but regards it as having no profile, and so Affinity assigns your default profile for 8/16 bpc RGB documents - AdobeRGB in your case. When AdobeRGB profile is assigned to an sRGB image, the image will appear oversaturated. You can assign sRGB profile to the document to get it back to where it should be. Important: I deliberately wrote "assigns", "assigned" and "assign" rather than "converts", "converted" and "convert". There is a significant difference between assigning and converting.

If you apply fill colour, stroke colour and other stroke attributes to the Layer, these properties will be propagated to the members of the Layer, and the Layer will remember the properties. Next time you select the Layer, the remembered properties will be displayed in the Colour and Stroke panels (although you may have changed the appearance of individual members in the meantime). You can apply a new appearance to the Layer and that will be remembered and propagated to the members, as before. The same is true for Group objects.

Same here. I've only seen the problems happen in the macOS apps if a file contains curves converted from text by the Windows software. My inexpert suspicion is something is crucially different about the output of the text-to-curves code in the macOS apps versus Windows apps.

Hopefully, the following will make clear what is working and broken (red text) in the 3 apps. Versions 1 & 2 of Publisher and Designer (in Document Setup window) Broken in Publisher 2 only - to maintain document physical dimensions when changing PPI: set document units to physical then change PPI To maintain document pixels dimensions when changing PPI: set document units to pixels then change PPI Versions 1 & 2 of Photo (in Resize Document window) To maintain document physical dimensions when changing PPI: ignore document units, enable Resample then change PPI To maintain document pixels dimensions when changing PPI: ignore document units, disable Resample then change PPI