lepr

You made it look more complex than it is by making it look wrong, lol.

But that is not like the desired result of a stroke aligned to either left or right of an open path. Your "in" and "out" examples have the stroke alternating left-right-left or right-left-right along the path, instead of remaining on one side along the path. Below illustrates the desired stroke alignments for open paths:

Not sure what the "sigh" is for. You've provided an excellent example of what I asked you to clarify. The original path with a one-sided (dual) stroke has been offset (twice) and (each) resulting path given a centre-aligned stroke.

Your example is of a closed path and shows the correct result for that closed path. This thread was about stroke alignment of open paths.

As an example, consider an open path with a left/inside-aligned stroke. Are you saying InDesign generates a path that is offset from the original path by half of the stroke width, and gives that new path a centre-aligned stroke?

The user would be free to stroke either side of an open path in exactly the same way as they currently are able to choose whether to stroke the inside or outside of a closed path - using the stroke alignment buttons. (Also, reversing a path will swap which side is considered left or right, of course.) The software already performs stroke expansion on-the-fly when a stroke's alignment is not supported by an export format, so I'm not sure where you see a complication or difficulty.

The warp arc result is much further from a true circular arc than the approximations created by the Ellipse, Donut, Pie, etc tools.

This has been discussed previously. A path has a defined start and end; therefore, as you travel along the path from start to end, the left and right are unambiguous. The software can be programmed so that, for example, the left side of any open path is regarded for stroking as equivalent to the inside of a closed path.

Sorry, missed that vital detail

Hi, please post screenshot of the Snapping options and the View menu.

It does seem to be missing. I never realised because I use period key to do the same.

Yes, by design. When a raster brush tool is active, colour controls affect the paint that will be applied to a raster object (Pixel or Mask or built-in mask of a Fill/Adjustment/Filter). When another type of tool is active, colour controls affect the fill/stroke of selected non-raster objects - a Fill is a non-raster object with fill, no bounds and a built-in mask.

One workaround is to use Document Properties to scale the document to 1 pixel wide, do the boolean operation, and then scale the document back to 210 mm wide.

Opt/alt-click when picking a Vector Brush to maintain current brush width.

As stated by others, Layer Effects are applied on, or around, an object's fill and/or stroke; therefore, if an object has neither stroke nor fill then its Effects will not be rendered. The Fill Opacity control (not to be confused with object/layer Opacity control) is for reducing an object's fill and stroke visibility without reducing visibility of the object's Effects. It is near bottom-right of Layer Effects panel and, in version 2, also near top-right of Blend Options window. In your example of an orange-filled ellipse with green Outline Effect, simply set Fill Opacity to 0% to make the fill disappear while the Outline Effect is still rendered.

Yes, that's exactly what I was talking about.

Aha, the document was OK! The overlay was a correct display of regions separated by column guides. (Who would've thought there could be horizontal column guides in addition to vertical column guides. Surely columns are a vertical concept by definition, outside of Affinityland.)

You're welcome, and Happy New Year!

Yes, and if you delete the Pixel object then the tiled "overlay" persists in an empty document.

There isn't a bug in your example. The initial filter is mask-nested in the triangle, therefore it is shown when the parent is collapsed. The duplicate filter is clip-nested in the ellipse, therefore it is not shown when the parent is collapsed. If you drop the filter on the thumbnail, instead of the name region, of the target, then the filter will become mask-nested instead of clip-nested, and so it will show when the parent is collapsed.

The document appears to be corrupted in some way that results in it being displayed with a tiled cloudy overlay (see the 9 tiles with a slight gap between the tiles in your initial screenshot). The "overlay" temporarily disappears while I scroll the view. If I copy the Pixel object then do New From Clipboard, the new document displays correctly. Edit: No bug - it was a Column Guides overlay

still broken in 2.0.3 on Intel Mac

Affinity has two variants of raster mask: Mask - this has a 'white' infinite surround and is initialised with size equivalent to the document size. Empty Mask - this has a 'black' infinite surround and is initialised with no size (or possibly size 0 x 0 pixels). To get a mask in Affinity as you had in Photoshop: make selection add Empty Mask fill with 'white' while the selection is still active Edit: altered description of Empty Mask

I agree that the inherent mask of the filter should control coverage of the filter only and not the mask that is being filtered, and so the current (2.0.3) behaviour is a bug. However, there is a workaround until the bug is fixed: instead of using the inherent mask of the filter, nest another mask in the filter.

VS now has a Flatten command to perform transparency flattening, but it currently disregards blending modes of the source objects when calculating the colours of the resulting fragments, making the result wrong except for when source objects have Normal blending mode.