Now, of course I don't necessarily need Fira Code to make a change in order to implement this in my own way, in a different font. Recursive without ligatures and Recursive Code with ligatures). However, because I'm working on this specifically for Google Fonts, they have asked me to not make two separate versions of the family (e.g. Because it is a somewhat general-purpose font, I can't have code ligatures on by default. I'm making Recursive, a variable font for code & UI.
UI suggestion: This feature should be off by default. This feature covers those ligatures which may be used for special effect, at the user’s preference.Įxample: The glyph for ct replaces the sequence of glyphs c t, or U+322E (Kanji ligature for “Friday”) replaces the sequence U+91D1 U+66DC U+65E5. UI suggestion: This feature should be active by default.įunction: Replaces a sequence of glyphs with a single glyph which is preferred for typographic purposes. Used in script typefaces which are designed to have some or all of their glyphs join.Įxample: In Caflisch Script, o is replaced by o.alt2 when followed by an ascending letterform. If all code ligatures on by default, it prevents a font from having some ligatures which are more subtle (for instance, a joined & or a respaced ||) and others which are more complex – but still useful for the iniated (like the >=).įunction: In specified situations, replaces default glyphs with alternate forms which provide better joining behavior.Therefore, they should probably require deliberate action to enable – similar to discretionary ligatures like the decorative "ct" connection in fonts like Adobe Caslon. Even if 20%+ of coders love them, anyone who is unfamiliar with them may find the more-complex ligatures confusing ( >=, !=, etc).I definitely think code ligatures are really nice for those who want them (part of why I helped get Fira Code onto Google Fonts 🙂), but I also think they don't quite fall into the stated purpose of calt – better joining for connected scripts, and I don't think they should be on by default for two primary reasons:
Screenshots of apps with Fira Code, no default settings changed (Click to expand) Microsoft Notepad, Windows While this may be nice in Fira Code, which has a fairly specific purpose, it makes code ligatures difficult to support in any more general-purpose fonts.
#G docs ligatures mac#
The issue with using caltĪ main issue with using calt is that in many contexts it that is enabled by default, including in general text editing on Mac (Keynote, Text Edit, Sketch, etc), Windows (Notepad), and web browsers (both Mac & Windows).
#G docs ligatures free#
If it is documented, please feel free to send a link! If not, I'm hoping you'd be willing to share your perspective and insights on this. I've searched around the issues here, but couldn't find documented reasoning around this. I imagine you probably have a good reason for using calt, but I wanted to clarify my understanding of why. Hey Nikita, I am looking into implementing code ligatures in a font of my own, and as I'm thinking through it, I've come to a question: might it make more sense (and fit the OpenType spec better) for code ligatures to use discretionary ligatures ( dlig) rather than contextual alternates ( calt)?
0 kommentar(er)
