lepr

.

.

.

.

.

.

I did test it but I was getting some odd, inconsistent results. Since I don't know if that was because of a bug in the app, something wrong in my installed copy of it, or something wrong with my testing methodology, I was hoping to get a definitive answer from the staff about how it works & what to do about any anomalous behavior I get on my system.

.

.

.

.

.
 

.
 

.
 

Except that you now cannot:
Select a pre-existing path. Select all of its Nodes. Mousedown on one Node and drag to snap that Node to the "guide." Snap the Transformation Anchor to that Node. (Transform Anchor is not available with the white pointer active, and black pointer active only lets you rotate by dragging bounding box handles.) Rotate the selected path by dragging one of its other Nodes and snapping it to the "guide." The core problem is that all of Affinity's interface for manually performing on-page rotations is based on bounding box handles (i.e., being selected with the black pointer), which quite often (in my use, most often) does not correspond to the selectable detail of the path which needs to be snapped to angular alignment. And entering the rotation value numerically in the Transform palette does not serve this common need either, because it also is based on the orientation of the bounding box (or the 9-point proxy), and because the program does not tell you the rotation or length of a temporary construction "guide" (straight, single-segment path) which was drawn by dragging the Pen in it Line Mode.
This fixation and dependency upon bounding boxes for transformations (i.e., absence of transformation tools) is one of the most debilitating foundational aspects of Affinity Designer's interface.
 
But that is a sub-standard throwback to the days before FreeHand allowed you to convert any path(s) to proper "Path Guides"; which nowadays is provided in other mainstream drawing programs. Proper guides (and pathGuides) are displayed as "hairlines" so their width is always drawn as thin as the display allows.
(Hairline stroke weight for ordinary paths is another feature that sorely needs to be added to Affinity Designer; one of many opportunities to surpass standard-fare. I get so tired of having to use a .25 pt (or smaller) stroke weight in Illustrator as a workaround for the needed hairline feature.)
JET

.

When scrubbing/dragging to change values in the transform pane, it really shouldn’t create a history event for every value it scrubs through. It should wait until the user lifts their finger.
I just lost basically all of my undos while playing with transform for a few seconds.

.
 

.
 

It's pretty pronounced in the demo file. I tried to rasterize it, add a layer effect to force it to resample, etc.
The only method I found that improves the quality is to apply the perpective filter at a higher resolution (initially avoiding downscaling to a small version), then scale down the screenshot (and rasterize if necessary).
But even then there are still some remaining anti-aliasing issues.
All of this seems to point at less-than-ideal re-sampling algorithms when down-scaling layers for lower resolution screen work.

.

.

.

Unfortunately, Affinity's boolean engine rears it's ugly head once again.
While I appreciate the effort, and the rest of the video, the method on the big shape leaves (at least when I did it) TEN extra nodes.... including a fully independent extra shape within the object. (all three nodes of the little triangle were on top of the top left corner)

For speed and accuracy I much prefer this method.... Faster and only () one extra node at one of the break points after recombining..... yet another recurring boolean problem, but at least it's just one . If ur unlucky maybe two.

(EDIT: if you try this on your own, please note that the original object was not closed. So I just hit that button first)
 

.