lepr

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

Nope. Doesn't help, not the subject of this thread, and likely to cause confusion. The Scaling controls determine what is to happen to objects in the document when the document dimensions change. (By the way, the resample method there is redundant - when scaling happens, it is nondestructive and involves no resampling. Photo is the only Affinity app that destructively resamples Pixel objects when a document has its pixel dimensions scaled.) Whereas, this thread is about Publisher 2's broken means of preventing the document changing physical size when DPI is changed.

[deleted - sick of arguing]

Use your partially transparent "vignette" layer as a mask on an Exposure Adjustment, and put the masked Exposure Adjustment as the topmost object inside the Layer (or Group) containing the pieces of frame. That will restrict the adjustment to just the content of the Layer (or Group). FrameAnswer.afdesign

Publisher 2 just needs to do the same as the current Designer 2, which is what both Publisher and Designer did in v1. That is, honour the user's choice of whether physical size or pixels quantity changes when DPI is changed, as was the case until version 2.

You're looking at the help for Photo, but this thread is concerned with broken functionality in Publisher. A Resample checkbox is appropriate for Photo because that app destructively resamples Pixel objects when the document's size measured in pixels is scaled. A Resample checkbox would be inappropriate for Publisher (and Designer) because these apps non-destructively scale Pixel objects when the document's size measured in pixels is scaled.

As far as I know, no version of PDF supports Erase blend mode, but I'll be happy to be corrected if wrong.

OK, so explain precisely what you need to be in the PDF.

Yes, same result as you. However, attached is an alternative PDF. Is that the export you expected? test-6 alt.pdf

There is yellow rectangle with Erase mode nested in the grey rectangle in Layer 2.

Designer 2 is OK and the same as v1 - it does not resize physical dimensions when changing DPI of a document with physical document units. It is Publisher 2 that has changed since v1 and now incorrectly performs physical resizing when changing DPI of a document with physical document units.

From the app's help document:

When the shift key is depressed to constrain angle, the intersection-snapping for the second node is dependent on the mouse button being depressed while the pointer enters the vicinity of the desired intersection. In my opinion, that dependency should not exist, but you can work with it: ensure both shift key and the mouse button are depressed as you move the pointer close to the required intersection, and only release the button to create the node when the snap is indicated. (I think Paul was successful by pressing the mouse button to create the first node of a line and then not releasing the button until the snap was indicated for the second node.)

You misunderstood me.

I am in agreement with GarryP and don't understand why you can't stop pestering me.

Not on my computer or the computer of others in this thread. APub2 (2.0.3 and 2.04 on macOS) is behaving correctly only when document units is pixels. When units is physical, a change of PPI is wrongly resulting in a change of physical size because the quantity of pixels is not being changed, which is the behaviour expected (and correctly happening) when units is pixels.

The expected behaviour: If document units is pixels, changing PPI should not change the quantity of pixels, but the document's physical size should change. If document units is physical (for example, inches or millimetres), changing PPI should not change the document's physical size, but the quantity of pixels should change.

The app is misbehaving, and not only does stroke scaling of the pasted objects wrongly differ, depending on grouping versus non-grouping, but the stroke scaling also wrongly differs, depending on the 'Scale with object' state of the strokes. In all cases of pasting, the ratio of line length to line weight should be maintained. Lines should not become fatter or thinner looking when pasted, regardless of grouping and regardless of stroke 'Scale with object' state. When pasted into a document with physical (for example, millimetres) document units, the lines should maintain their physical length and weight, and therefore their pixels dimensions should be scaled by destinationPPI/sourcePPI. When pasted into a document with pixels document units, the lines should maintain their pixels length and weight, and therefore their physical dimensions should be scaled by sourcePPI/destinationPPI.

Best to post an example Affinity Designer document to ensure there is no ambiguity.