Working with zero-width glyphs can be tedious. Especially unencoded ones that Glyphs can’t set to zero on export. If I open a batch of them from the font tab then I have to insert some dummy character to work with the outlines. I suggest adding a button under the preview area that would render the zero-width glyphs as if they had positive sidebearings.
All you need to do is to manually set the subCategory to Nonspacing. That would make them marks in the GDEF table, too. Would that be a problem?
I think it could be a problem. There isn’t a complete list of how layout engines process glyphs listed as marks in GDE. So it could make troubleshooting problems with those glyphs harder. And it’s a hack that’s hidden from users unless they actually open the category menu. So if someone else has to work on the file years later they might not know that or why the glyphs are configured that way. This could be remedied by added a mark to the font tab or into box to indicate that a glyph’s data has been customized. Which is probably a good idea anyway 
I think a padding button would be more useful. With Kannada subscript forms, or Devanagari’s ue and uue matras, it’s useful to have a width of zero to see how they’ll work without having to export the font. But being able to quickly give them widths would make it easier to select them or add other glyphs around them without having to manually change the width.
Georg, I know we have different ways of working with nonspacing marks, and I’m never going to want to give them any width, as I need to see them in situ so I can adjust bases’ outlines or kern accordingly. But I can see why some people might want to pad them.
However, rather than add width to nonspacing marks, it sounds like the problem here is that the UI doesn’t allow easy selection of nonspacing marks. Georg, as I suggested before, wouldn’t it be simpler just to have selection be based not just on the pointer’s x-position in relation to glyph sidebearings, but whether there is any black below the pointer (ie it takes y position into account too)?
Then we need a other way to do the selection. Double clicking is used for other things and if there is another glyph behind, you switch to it unintentionally.
Would shift-double-clicking or something similar work?
Do you have an example of a glyph behind a mark?
Not a glyph behind a mark. Any glyph that overlaps.
I don’t think I’ve seen that. But still, there would always be parts that don’t overlap, I think, so if the wrong glyph is selected, it would just be a matter of clicking a different part of it.
The problem is not when you try to select a glyph but when you double click to do something else (like to select a path) but miss.
Then there is the problem when you have several zero width glyphs and they overlap heavily.
The best solution I can think of is to do proper mark positioning in the preview. Then you could add spacing and still could see the final result at the same time.
I see. I can’t quite visualise your solution, but anything that puts marks in the correct places would be extremely helpful for me. (Though as I think I’ve shown you before I need to see how they work in real words to make sure they don’t bump into the next glyph, so I’d prefer not to have an advance width in any situation.) How about a toggle button for the edit view, that either puts marks in the correct places, or can give them virtual padding without affecting sidebearings, so people can choose which way to view them?
I meant the preview area at the bottom of the window. The edit view would have them next to each other but the preview would show them attached.
That works when inputting glyphs individually. It won’t be so helpful when selecting twenty glyphs in the font tab and opening them all at once.
1 Like
Also, if you want to export to UFO or VFB at some point, you’d have to manually collapse the advanced width, reposition the marks, and risk problems where they are referenced as components.
2 Likes