Ligatures in the programming community are a controversial topic. Some people love them; some despise them. Editors seem to pick up ligatures from
liga but not
dlig. Therefore, our solution is to export ligatures on
dlig on the mainline font and to ship an alternative font family that exposes those same ligatures as
liga, ensuring that all editors that support ligatures can find them.
You can see my attempt to implement this strategy for Inconsolata in this commit. I’m using the Replace Feature (ahem) feature.
At first, I tried
liga;dlig, but that wouldn’t export correctly. After searching around on GitHub, it appeared the actual body of the feature is supposed to appear after the
;, so I pasted it:
liga;sub exclam equal equal by exclam_equal_equal.liga;
sub equal equal equal by equal_equal_equal.liga;
sub hyphen greater by hyphen_greater.liga;
sub equal greater by equal_greater.liga;
sub greater equal by greater_equal.liga;
sub less hyphen by less_hyphen.liga;
sub less equal by less_equal.liga;
That doesn’t seem to be working either. What’s the right syntax to add a
liga variant to a font? Can I set up a rule that copies the entire body of
Here is a good web site to help with writing feature code:
The feature code is fine - it works when a normal instance is exported. Rather the issue is that this CP doesn’t work as expected
Handbook on page 195 says,
Replace Feature string Replaces the content of an OpenType feature with the code specified. The first four letters must be the feature name (such as ‘liga’), followed by a semicolon and the new feature code. Works only if the feature exists in File> Font Info> Feature.
The feature exists, and the new feature code is correct, so this is a mystery to me
Are the glyphs actually called like that?
I’d guess that your glyph names still have the
.dlig suffix, e.g.,
less_equal.dlig. So, consider changing the feature code in the
Replace Feature parameter with those
.dlig names, e.g.,
sub less equal by less_equal.dlig
As you can see in this screenshot, the new glyphs currently end in
.liga, so I don’t think that is the issue. Should what I’ve written work?
You can also download the .glyphs file from the GitHub repo.
Nope; it exports, but the resulting font doesn’t give me usable ligatures. Pasting that same block into the
liga section of Features (minus the
liga; prefix) results in a font that works fine.
Our goal is to use Replace Feature to automate the conversion.
An alternative method to perhaps consider:
- Create the coding ligatures as
- Assuming that
dlig features are automatically generated.
Press the Update button in the Features tab of the
File > Font Info… window to have those features initially set up based on glyph naming.
- Create the coding ligature instance with two custom parameters:
Rename Glyphs with value set to list of:
Update Features custom parameter with the checkbox value checked.
Then, the source
.glyphs file is a bit more clear about initial intentions. This approach currently assumes that the
dlig features are automatically generated based on glyph naming.
I have not yet researched the issue in your particular
Thanks Jeff - that worked.