Today we came across a need that Glyphs couldn’t meet, I think. Our Thai extension was drawn with positive sidebearings on the marks, to make editing easier (thank you to Rainer for the mark preview plugin, everything is now a lot better than my old way). When exporting UFOs and OTFs, the marks are zero-widthed by collapsing the left sidebearing onto the right sidebearing (at least, that’s what it looks like when opening an exported OTF). This is generally fine.
In our situation, however, the rest of the font (Latin etc) in the master files have the marks drawn on zero width, with their _anchors on the x=0, and the client requested the Thai be done the same way. We patched the UFOs to collapse the sidebearings onto the _anchor, rather than collapsing the lsb onto the right one. Unfortunately, although the actual position of the mark on a base is determined by the anchor and not the sidebearings, a rather convoluted investigation showed the mismatch between the OTF’s feature code and the UFO’s patched outlines resulted in every mark getting positioned in the wrong place. @Mark is now spending quite a lot of time to readjust the UFO outlines to be in the same position as the mark feature expects.
It would be very beneficial to have options for different zero-widthing strategies, either to collapse the lsb onto the right, or to collapse both onto the anchor, or maybe to also centre the mark on x=0. I know the automatic behaviour is usually helpful, but not being able to adjust it is not helpful.
I appreciate that these kinds of requests may not be applicable for everyone, but we’re having increasing problems collaborating with clients who need to incorporate our work in larger projects, who are working in different ways with different editors. Figuring out what might go wrong and troubleshooting is taking quite a bit of time, even when working with extremely knowledgeable professionals. Allowing access to settings like this would ease the burden considerably.
That was the way it was done in the other scripts. I can ask if there was a particular reason from their side, but from my perspective, what the client wants is the only reason that really matters (unless they’re being unreasonable
Other fonts do it this way (Helvetica Neue, Palatino);
Easy to work with in a font editor [I’m not sure how other editors manage this]
Clear to see when marks are not working right.
I think the bottom line is that people do things differently. Our normal approach of collapsing the LSB works very well for the Southeast Asian scripts, because if for some reason the shaping engine can’t apply the mark positioning rules, marks will float in approximately the right place above consonants. But drawing marks as spacing glyphs and doing the zero-widthing on export does mean we need the extra functionality of the mark preview plugin…other editors may not be so adept at handling this kind of thing.
One thing you could do is to move all outlines and anchos so that the anchors are on the RSB. That way you still can edit them in Glyphs and when the LSB is moved to the right, the anchors are where they should be.
Why? That’s what we do/did so far, and for me the plugin works just well. Did I oversee something here?
Good idea. In the meantime I rewrote the UFO export script to collapse the marks onto the RSB instead. Since this is (hopefully) doing it the same way as Glyphs does on export, that should do it for us.
We where also referred to have a look at GlyphsLib, but compared to my 40-lines-script that’s a freaking monster. Looking at the repository I feel like I don’t even wanna touch that thing. And it has many issues open. I saw your remarks about that it’s just putting patches and hacks everywhere. I kind of agree.
Precisely. Without the mark preview plugin it would not be easy to work on these scripts. Other font editors may not have the same functionality and so it may be easier to use different spacing techniques when drawing the mark glyphs. Before the plugin was made, I was myself drawing the marks on zero width in Glyphs so I could judge them in their correct places. My point was that drawing marks as spacing glyphs requires this plugin.
Yes, that’s effectively the same as what we ended up doing. Moving stuff around or writing scripts to adjust Glyphs’ automatic behaviour takes more time. In starting this thread I was hoping for ways to save time, by just allowing those automatic behaviours to be controlled.
Doesn’t the existence of GlyphsLib highlight the need for better interchange between Glyphs and UFO formats?
The glyphsLib is made to be able to do something with .glyphs files outside of Glyphs. So e.g. the client of yours could adapt his scripts (quite easily) to use your .glyphs files directly instead of requesting .ufo files.
.ufo files are used for so many things, that is impossible to make everybody happy.
