Zero width marks from the imported Thai source are getting zerowidthed on the wrong side in the exported font:
Add an anchor called *origin (with the asterisk) on the baseline, and where you want the zero-width position.
Thanks. It’s a bit of a drag having to go through every glyph in every master and add an anchor for something that was always automatically correct before. What’s the reason for this change?
The code for auto-correcting the component positions was overly complex (think transformed or mirrored components) and there were complaints about Glyphs auto-calculating ZWRO.
I see. Doesn’t this approach just shift the complexity to the font designers? I can’t think of many situations where a mark would want to appear above/below the next letter rather than the previous letter. I didn’t have problems with Glyphs’ auto calculations before, and I tend to make quite complex fonts (with flipped components). Could this be reconsidered?
EDIT perhaps a user preference to zero marks to the left sidebearing or the right one?
Run this in Macro Window:
zwroOffset = 10
for glyph in Glyphs.font.glyphs:
if glyph.script in ("latin", "thai") and glyph.category=="Mark" and glyph.subCategory=="Nonspacing":
for layer in glyph.layers:
if layer.isMasterLayer or layer.isSpecialLayer:
if layer.bounds:
x = layer.bounds.origin.x + layer.bounds.size.width + zwroOffset
anchorPosition = NSPoint(x, 0)
anchor = GSAnchor("*origin", anchorPosition)
layer.anchors.append(anchor)
print(f"⚓️ {glyph.name}, {layer.name}: added {anchor.name} at {int(x)}x 0y")
1 Like
Thanks! Now to go through all the fonts with this update 
Mark positioning is done through the mark and mkmk GPOS features, so this situation should not occur, and it should not matter where you put the zero-width.
However, there are some age-old bugs in renderers unlikely to be fixed anymore, most notably for Thai on the Mac when there is a nonspacing mark on the last letter of a line, that can be circumvented with ZWRO. So, for Thai, ZWRO is the better option, best applied with a script like this.
PS: discussing internally if we add *origin by default for Thai marks.
1 Like
I’m thinking of situations where a user, for whatever reason, wants to put a mark above a letter in a nonstandard combination, like a Thai vowel on the letter x for example. The x won’t have an aboveright anchor, so the position of the mark would be determined by its relation to the zero, or no?
Then this will happen:
Unless you have both in the same font, then you have Star Wars:
2 Likes
Ok, take a sequence that’s not invalid, let’s try a character without a specific script
Here’s multiplication sign with saraIi in the old export:
And now:
- I like my example better, I must admit.
- It won’t work in an RTL environment.
- Not sure what a valid user expectation is in this scenario, but if you really want to support this in your font, just add the anchors for all marks in all non-marks.
1 Like
Lol yeah I get it, just feel like this is a bit of a backward step for the font makers.
Another example I’ve just tested. Apps like Affinity don’t have proper shaping for complex scripts, but it’s possible to get fonts working in a very basic way (like if we just want to typeset a word or sentence, perhaps needing some manual intervention with the glyph palette) if marks appear in approximately the right positions without mark positioning. With this change, the marks are sitting on the following letter, so even that basic/broken functionality is lost.
I’ll think about this. The *origin anchor is a (tedious) solution. I’ll see if we find a better one.
1 Like
BTW the *origin anchor destroys the (essential) mark preview plugin
The *origin anchor also messes up completely the mark positioning in variable exports.
Can you try the latest version of if still causes problems with the preview?