,,,

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.

Enable Transparent Background in the Colour tab of Document Setup to get a checkered background. (Also, an Artboard needs to have no opaque fill or the checkerboard will still be hidden.)

If the selected masked object is a Group (or Layer), an Export Selection Only is as large as the entire Group. If the selected masked object is not a Group (or Layer), an Export Selection Only is just large enough to contain the masked region of the object. That difference seems illogical to me, and I think the export should be the size of just the masked region in both cases. In other words, the output of Export Selection Only of a masked Group (or Layer) is wrong currently, in my opinion.

Yes, clearly there's more similarity between Smart Objects and Affinity embedded/linked documents than there is between Smart Objects and Affinity Image objects or between Smart Objects and Affinity Pixel objects.

The problem you refer to no longer exists in v2: now the user can freely nest and access objects within mask-nested objects to an arbitrary depth. However, there are bugs in the rendering of nested objects, which may or may not affect your particular work.

A Smart Object is like an embedded or linked document (Affinity document or PDF) in an Affinity document, rather than the less functional embedded or linked Image object, since a SO can contain multiple layers and it can be opened for editing by double-clicking its thumbnail in the Layers panel.