The text box possibly needs a text alignment option.
Doing centred text is not possible if you want to keep it editable. Text objects don’t trigger View - Snap to Smart Guides. There’s no restriction on dragging them around.
After Convert to Curves, the object is able to be optically centred and Snap to Smart Guides works, with red guidelines appearing and magnetic drag restrictions.
Usability thoughts
This is one of those complicated choices.
Ideally, keeping text editable doesn’t involve compromise in the overall object editing paradigms. But, to make alignment by the bounding box work, you then need to have horizontal and vertical text paragraph alignment within the box.
One option is to build in Arrange by Curves as an option where you automatically convert editable text to Curves and use that representation for positioning, with it stashing an offset to adjust the position of the Text object bounding box.
Otherwise, at least adding horizontal paragraph alignment comes closer to working for most layout.
Improving Convert to Curves
Quick thought whilst playing with this, having noticed that converting adds the curves in reverse order (so Try adds layers where “y” is the top and “T” the bottom)…
How about naming the new paths after the text, so the layers panel would at least read
“y”
“r”
“T”
BTW thanks so much for your in depth feedback and thoughts, it’s super helpful!
- Adding smart guides to text boxes would be easy
- Adding smart guides to the text characters themselves wouldn’t be too hard… I’d need to make sure it didn’t affect performance too much.
- At the moment, text boxes are pretty much a fake. They’re stored as the text’s origin point, plus a scale factor for horizontal and vertical, and the box is derived from the size of the actual text characters. So it’d be hard to do alignment within a box (unless I build ‘real’ text boxes with their own actual width/height), but I could fairly easily make the text origin point be the centre of the text rather than the left, for example.
- FWIW, the vector editor in McKinley is designed to be reusable, and in my other sample app that uses it I do have real text boxes with actual size, paragraphs, etc. I didn’t bring them to McKinley because I figured people wouldn’t be writing longform text inside a symbol. So the work has been done, if we decide that that’s the best UX approach.
So I think the decisions to take are:
- keep the text origin/scale approach, or bring in real text boxes (with all that entails, e.g. text overflowing its box)?
- for horizontal alignment, shifting the origin point to left/ctr/right of the text string would do it (in the sense that as you enter text, it would appear to be centred etc). Is that sufficient?
- for smart guides, I can have the text origin point be a smart guide snap point quite easily. Combine that with the centred text approach above, and you’ve got a way to snap text to the centre of a rectangle. Is that sufficient, or do you want other smart guide snap points for text? I could also do the edges of the derived text frame being snap points.
- Snapping to individual text glyphs is possible, but there’d be loads of snap points so it might have performance issues, and also the usability of dragging with loads of points trying to snap might not be great. I suggest skip this, but I can investigate further if you want.
Your other thought: naming new paths after the text: a no brainer, I’ll do that 
this one is in version 1.2.
1 Like
I agree that adding text to SFSymbols (*) is a bit of a fringe case, very unlikely to ever be more than a few characters. So I think changing the default to optical centering works fine. I agree bringing in the whole can of worms with full rich editing isn’t worth it.
In Touchgram, I have truly dreadful hack where, because wanting newlines in the text but having only a single editing field, I replace carets with newlines. Some editing contexts draw them with a unicode visual newline (bent arrow). It was supposed to be a quick hack to get a version out for a startup competition and uhhh, things have kept been pushed on the stack above fixing it.
(*) For general app icons, it’s a different story as:
It’s a valid (old-fashioned?) graphic technique to have tiny text in the background or as fill.
- App Icons get blown up to 1024x1024 and it can be a gimmick to have something witty and actually readable there, which can still be squinted to see in the other sizes.
1 Like
Hi Andy,
Text alignment (including centring) is in McKinley 1.3.1.
Amy
