I would like to add new feature to Glyphs: snapping to components. It would make my work much easier if the guidelines and other nodes/objects would snap to the components. My ideal interpretation is the components would temporarily behave LIKE vector objects. So the nodes or straight lines of each component would allow snapping of nodes or lines of the objects I manipulate with. Thanks!
Georg, I already mentioned this, but support from other users may put this feature to the top of your list
Example 1: I am working on a geometrical typeface right now. The letter O could be composed out of two components: arch and stem. So I place two arches and two stems on an O glyph and put them together. I have to zoom and carefully place the components to baseline (or overshoot line) and carefully align them together. If the components would snap to each other, baseline etc., it would take seconds not minutes to build a glyph out of components.
Example 2: When building diacritics, I want to make sure all accents are in perfect harmony. So I use global guidelines to align certain elements to the same position. Unfortunately guides do not snap to components so I have to zoom in and be extremely careful when placing guide. (Many accents are components, circumflex = mirrored caron, acute = mirrored grave, dotaccent = shifted dotaccent.cap etc.) Snapping guidelines to components would make working with components significantly more efficient, especially because the components looks little bit blurred and it is not easy to align a guideline to them.
Example 3: In a geometrical font I am working on, I also combine components with vector elements. For instance the letter C is composed from two arches (components), one stem (component) and two additional small rectangles (vectors). Another similar example is ogonek: Sometimes the ogonek must by slightly adapted to the base letter and then aligned with the base letter (component).
The snapping of components, guidelines and vector objects to components would let me build glyphs in my workflow faster are more reliable.
I copy caron to caron.cap position. I adjust the design, the caron.cap is often more flat than caron. I then make global horizontal guides matching the size of caron.cap.
I use the bottom or top global horizontal guideline to consistently align other diacritics, ie. accents made from components (dotaccent, dieresis, macron…).
The snapping makes sense here: I can drag dotaccent-component in the dotaccent.cap glyph to the position of the bottom guideline and then move by 10 units upwards. I can quickly repeat this with dieresis: snap to certain horizontal line + move certain number of units.
Without snapping to guidelines, it is simply more time consuming process, I have to carefully check if it aligns with the guideline or check the X value. Snapping would give me more natural way of controling the position of the component without additional steps required to be sure that the component / vector object is placed at the same horizontal level.
Agree with mekkablue. The destination might be clear, though the origin (the point where you started dragging) isn’t.
For case 1 and 3, you can simpy use alignment at the bottom of the pallet, no?
For case 2, “perfect harmony” doesn’t necessarily mean perfect alignment.
I don’t want to see things this complicated just to make one specific project efficient, but do want to see the solution that’s more general. For example, I suggested that measurement guidelines shall pick up components too (measurement tool does), which gives you the distance by numbers, thus I won’t have to zoom in to check alignment anymore.
I think it is not really necessary. I would not recommend positioning components using guidelines in the first place. You have many more advantages if you use anchors. Plus, the bounding box of a component is not necessarily what you need to align to.
However, we will look into this and try it, but chances are we find the snapping to be more in the way than helpful, so I cannot promise anything.
The geometrical workflow you described as an example makes sense to me. But you will admit that this is an exceptional way of working. And even there, I would rather implement something that respects self-defined snapping points with anchors named “_snap_1”, “_snap_2”, etc., so you are not stuck with the bounding box. How about that?
Think of this: Two rectangles exactly aligning on one side could confuse the Remove Overlap algorithm, so you may want to add some overlap to be on the safe side. In that case, snapping to the bbox is not what you want.
speaking of snapping: would it be possible to turn the auto-snapping to the background off? i often have a hard time to pull handles or points out of their position (or along a snapping point). this is mainly a problem when i am quickly drawing (with the mouse) different versions or changes. worst case is when you have an autotraced shape in the background. it is usually very rough with a lot of points and makes it a pain to draw smoothly over it.
and opposed to that, wouldn’t it be nice to enable a point snapping to the points of a component in the background? also just as an option, not by default. this could help a lot during earlier design stages.
Mekkablue, I use anchors but usually in the more final stage of my design process. I do not use guidelines as a substitution of anchors!
Let me give you another example. During the initial stage of designing fonts, I experiment with descender length. Imagine I play with the letter “j” I made of two components: i and “top” (I recycled the top part of f and longs). As soon as I am happy with the position, I mark the temporary descender line using a global horizontal guideline. To make this little task efficient, I would simply love the guideline would snap to the bottom of my component bounding box.
Now I check how this descender works in other glyphs and I possibly change it again. So I go back to the letter “j” and snap the component to the new position of the global guideline.
A useful feature would be to display nodes (not so important but BCPs would be good) of a component so that alignment would be simplier especially in the case of aligning extreme nodes to paths and other components.