Exporting dlig as liga

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 dlig into liga?

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.

Do you get any error message? This might help: https://glyphsapp.com/tutorials/troubleshooting-a-font-that-does-not-export

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:

  1. Create the coding ligatures as .dlig glyphs.
  2. Assuming that liga and 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.
  3. Create the coding ligature instance with two custom parameters:
    Rename Glyphs with value set to list of:

    and the 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 liga and dlig features are automatically generated based on glyph naming.

I have not yet researched the issue in your particular .glyphs file.


Very nice idea Jeff!!!

Thanks Jeff - that worked.