Inconsistent handling of "closed" ligatures.

I noticed something funny with italic “ff” ligatures today. When the two letters are joined at top and bottom, the white space enclosed by the ligature is sometimes rendered as black in Scrivener. So far, I’ve only found this with the Georg Duffner version of EB Garamond 08; the italic “ff” is screwed up, while the enclosed space in the top half of the regular “ff” is fine and both italic and regular “ff” ligatures are fine in Duffner’s EB Garamond 12. I’ve attached a screenshot; top row is in Scrivener, EB Garamon 08 at left and EB Garamond 12 at right; bottom row is the same in Word.

A better test would be to try this same setup in TextEdit, which like Scrivener, is also a fully native Mac program using the same exact text engine. Microsoft Word isn’t really a good counter test for anything on a Mac, since it uses its own code for much of what it does.

I’d also try downloading the font again, and maybe looking around for a newer version of it while doing so. It could be the designer only tested it in Word initially, and has received feedback from other users that would improve it on other platforms.

I would not be surprised if the Word one looks okay, b/c Word is “faking” the italics — as it has historically done — by just programmatically tilting the underlying non-italic typeface. Scrivener italics is the real thing — the letter forms from the italic variant of the font.

The Mac OS text rendering engine (not Scrivener) has the job of translating the font’s letterform instructions to the screen. But since the algorithm for rendering text is not letter-form specific and given that the rendering engine successfully renderers innumerable other fonts, I would say it is unlikely the problem is in the rendering engine. Which just leaves the font itself, like Ioa suggested.

The two curves which would cut out the interior of that ligature each have a “direction” which must be the opposite of the direction of the composite curve which represents the outer edge of the letter form — in order to function as a cut out. It appears the italic ligature has the direction wrong, resulting in a fill effect.

After poking at it a bit more, I’m noticing that if the font is set to italic and I type “ff”, it creates a proper ligature. If I hit the spacebar after typing “ff”, it fills in the ligature. Other letters after the ligature are fine, a tab after the ligature is fine, but a space after it is no good. And you can’t “trick” it by, say, having a trailing space after your text so that you don’t have to hit the spacebar. If there’s a space after an italic “ff”, it fills in the “ff”; Another other character, including a carriage return, after “ff” and it’s fine. Luckily there aren’t a whole lot of words that end in “ff”. The last name “van der Werff” is the example I’m running into at the moment; “Carl Orff” is the only other I can think of. It behaves identically in TextEdit and Scrivener. I hadn’t realized the font rendering doohickey was something built into the OS rather than part of Scrivener.

BTW, I think you can see from the image that Word is not merely tilting the letters. For whatever reason, Word is able to correctly render this font. If whatever’s screwing up Scrivener is external to Scrivener, maybe there’s not much to be done about it, though. Also, for what it’s worth, the font is no longer under development. Georg Duffner’s version of EB Garamond, especially the 08, is wonderful, but he was not able to continue working on it. It’s since been taken over by people who have dropped the 08 and apparently done their best to expunge any lingering character from the 12 so that it is as perfect and bland as every other Garamond out there.

I also can’t see this problem using the EB Garamond OTFs released by Octavio Pardo (the ones commisioned by Google). But that is based on Garamond-12. I also tested in TextEdit as I do still have Duffner’s 0.16 version (though not activated by default):

[attachment=1]Screenshot 2021-03-13 at 07.55.42.png[/attachment]

This is most likely a bug in the font itself. As Duffner says "This is a work in progress, so expect bugs! ". Word may work around this, I can confirm it works there:

[attachment=0]Screenshot 2021-03-13 at 08.14.33.png[/attachment]

It does seem there is some recent activity still on his Github, so you can post an issue there (, and hope someone with skills can fix it. Another idea is to try the TTF version or OTF and see if the bug only exists in one or the other? TTF and OTF use different curves and perhaps the bug is only seen in one of them?

Pardo’s version for those interested:
There is also a compatible maths version if someone is interested:

OK, the TTF version (still 0.016 release) doesn’t exhibit this bug in TextEdit:

[attachment=0]Screenshot 2021-03-13 at 08.25.11.png[/attachment]