Kal

The 'More' button is more than little easy to miss! Would love to see the UI improved here. Once found, it works well though.

Hi Sean. I'm not sure I quite understand what you're saying. I do understand that the text frame resizes as you type (to fit the width of text), but I'm not sure why it can't resize about the centre of the text (if the type is centred) or the right of the text (if the type is right aligned), etc. I mean, currently that's what it appears to do… But it's only when you have precise requirements that you notice it might be out by a point or two. I guessed (as per the title of this post) that it's because the centre of the type doesn't match the centre of the text frame for some reason. I think the expected behaviour for most users would be that it matches, which is why I called it a bug. What do you mean by 'the align status is not remembered'? Do you mean, if you switch alignment, the text frame stays put and the point of reference moves? For example, in Illustrator it's the opposite: if you change the alignment of type (without a frame), the anchor point stays put and the type moves accordingly (which I think is the preferable behaviour, but that's possibly just because I'm used to it.) Unless I've misunderstood, I don't agree that the chosen node in the transform panel should affect the alignment of type, as this might conflict with the paragraph alignment settings. I see entering type as quite a different activity to transforming an object.

I just think we need the developers to fix it. :-)

Yep, I'm using the Artistic Text tool. The equivalent in Illustrator (clicking with the Type Tool, rather than clicking and dragging) doesn't have this behaviour. In Illustrator, you can see the centre point, and it stays put when retyping. I just followed your (much simpler!) example, observing coordinates in the Transform panel while changing a zero character to a one (using 50 pt type). The error varies depending on whether the type is left aligned or centred: Movement of left aligned type: 0.1 pts Movement of centred type: 1.8 pts So only the tiniest of errors when left aligned, but a huge error when centred. Strange.

This odd behaviour is a little difficult to describe in words, but is easily seen by following these steps: Draw a symmetrical shape (say a circle) and elsewhere, type a symmetrical character (say the number zero). Select the text character and set the paragraph alignment to 'Centre Align'. Select both objects and align their centres using the 'Align Horizontally > Align Centre' option from the toolbar. Now, select the text character and change it to an asymmetrical character (say the number one). Repeat step 3, and observe that one of the two objects moves slightly. The movement, observed in step 5, should not happen, because the two objects were already centred, and the text itself was also centred. This suggests that the centre of the text does not properly align with the centre of its containing object. I would consider this unexpected and undesirable behaviour.

Hi Chris. What's the 'alt + backspace issue'?

Ha, no worries. You're still right in calling it a bug. Am I right in observing that AD has quite a lot of bugs, and that some of them are particularly long-standing ones? I really want to like Designer as an Illustrator replacement… and in many ways I do like it… Working with pixel-based layouts seems to work much better than it ever did in Illustrator. But other things I find frustrating… Window management, aligning/distributing objects, undo issues and really sloppy handling of colour swatches. Overall it feels more modern and responsive than Illustrator, but then all these little usability issues just take the fun out of it for me. Does anyone else feel like this?

Thanks for the suggestion @αℓƒяє∂, I've tried Alt + Backspace (or as us MacHeads would say Option-Delete) and every possible combination of the modifier keys, but unfortunately nothing deletes the point without corrupting the curve. @Aammppaa, I agree. I'd call it serious bug for a professional drawing program. Even though the deviation from the desired curve is minimal in my example, that's exactly what makes it dangerous—you might not notice it. Depending on the angle of the control handle before snapping, the results can be far more obvious though. When you say, 'Whenever nodes are joined by snapping together AD insists on making them Smooth', in what way is the result smooth? As seen in the screen-capture, it's still a corner point—it's just missing one of the control handles. Please let me know if I've misunderstood something.

Indeed, that's exactly what happens. In fact, if I'm not mistaken, the result looks exactly the same as I described in my original post, when I dragged one point to snap to the other. The handle on one side disappears, and the curve flattens slightly. There seems to be no way to simply join the two points without corrupting the curve!

Thanks αℓƒяє∂. Yes, I guess that is why the 'Join Curves' command fails! I'm not used to having two different commands for merging end-points, depending on whether they're on the same curve or not. Pretty sure I did try the 'Close Curve' command. In any case, I tried it again and it didn't merge the two points. When I drag the point, it turns out that both points are still there, joined by a segment. So I'm still back to needing to snap the points together. And that's when the handle disappears as previously described. PS. While on this topic, do the 'action' button icons (Break Curve, Close Curve, and Join Curves) make any sense to you? I tried to make sense of them so I don't always have to roll over them to remember which is which, but for the life of me I can't decipher the logic.

I need to join two endpoints, resulting in a single corner point that closes the curve—a pretty common requirement. Even though the points appear to be perfectly aligned, the 'Join Curves' command fails, so I first need to ensure that the points are perfectly aligned by snapping one to the other. I select one of the points, move it away, and then move it back until it snaps to the other—but in the process, the control handle from the point I moved disappears, altering the curve slightly. (See attached screen-capture which illustrates vanishing handle.) Affinity Designer disappearing handle issue.mov

Great suggestions Aammppaa. I do agree with metajake in principle though, that non-destructive actions (like deselecting an object) shouldn't be added to undoable history. Without thinking too hard about how or where this catches me out, I know it does from time to time. As I said on metajake's other post: "Some people may remember that with InDesign CS3, Adobe started including non-destructive actions (switching to preview mode, showing and hiding guides, etc) in the undo/redo stack, and it was a nightmare. People hated it, and Adobe restored the previous behaviour. In Adobe apps, I like that the relevant selection comes back when you undo or redo." The Adobe behaviour provides the best of both worlds I think… You can safely deselect an object without losing redos, but if you do undo or redo, you get your selection back.

Yes. Thanks for that. I see the devs have acknowledged it as a well-intentioned, 'long standing bug' and talked about fixing it. But that was back in 2016! Yikes. I guess I shouldn't hold my breath.

I agree that deselecting an object shouldn't be part of the undo/redo stack. I wouldn't necessarily call it a bug, but it certainly bugs me! I do like that you can press the space bar in Designer to preview without selection bounds, but I still think undo/redo should be reserved for destructive actions. And sometimes space bar doesn't work—say, if there is focus on a text field like Swatches > Opacity. Some people may remember that with InDesign CS3, Adobe started including non-destructive actions (switching to preview mode, showing and hiding guides, etc) in the undo/redo stack, and it was a nightmare. People hated it, and Adobe restored the previous behaviour. In Adobe apps, I like that the relevant selection comes back when you undo or redo.

I've been noticing that as I work on complex artwork in Designer, I invariably end up with unwanted duplicates of various objects. Since each object is perfectly aligned with its duplicate, I don't notice unless I try to edit, move or delete one of them, or unless I happen to notice them in the Layers panel. I've been clueless as to how these duplicates are being created—I just assumed something about the way I work isn't jibing with the Designer way. (I never had this problem in Illustrator.) Now I think if I've found the likely culprit—at least one of them anyway. I notice that if I copy an object by option-dragging (a single action), it takes not one but two undos to restore the status quo. The first undo doesn't delete the duplicate object—it just moves it back to the precise location of the original! (See attached screen-capture.) Is this the intended behaviour or a bug? I can't imagine why anyone would want a single action to require two undos, particularly given the potential for duplicates as I have discovered. Affinity Designer duplicate undo issue.mov