Multiple dash characters look weird about operator-mono-lig HOT 8 CLOSED

I think I've mastered the contextual substitutions!

Fira Code actually does some really funky stuff to support both caret position as well as ensuring ligatures don't repeat undesirably.

Basically it uses a feature in OpenType call contextual substitutions. You create a table with backtrack, input, and lookahead glyphs to tell the renderer which glyph to ultimately use. What Fira Codes does is replace the component glyphs of the ligature into LIG (placeholder) glyphs. Once it has chained enough of those placeholders, does it output the actual ligature glyph. It also checks to see if you are repeating the start or end of ligatures and prevents the ligature replacement from occurring. This way if you have a chain of =, +, or -, the ligatures won't occur since it's no longer stand alone.

Here's the table for the <!-- ligature. B2-B0 are the backtrack glyphs, IN is the current input, and L0-L3 are the lookahead glyphs. You can see how the first 2 rows check for repeating glyphs that would cause the ligature to be skipped.

The rest are simply the placeholder LIGs that are built up until you get enough to output the actual ligature. As you can see, this follows a predictable pattern, so I wrote some code that will generate these tables automatically for any given ligature.

I'm hoping to have a test version of the new font done this weekend. I'll let you know when you can check it out.

Thanks!

from operator-mono-lig.

The context aware feature has been pushed to the features/contextsubst branch. The ligature will no longer repeat once you exceed a vaild ligature. It will simply revert to the individual characters.

from operator-mono-lig.

I did notice this as well, every two dash's get lumped together, but do not touch.

from operator-mono-lig.

Yes, this is a known "issue". This is basically the hyphen_hyphen ligature (--). Ligatures are not context aware. Therefore anytime there are 2 hyphens, it will display the ligature.

Now as in the carat spacing issue #35, Fira Code obviously uses some advance OpenType features to handle this. Unfortunately, I'm not very experienced with this, so not sure where to make the changes. Again, if there are OpenType experts out there, please feel free to point me in the right direction.

Thanks!

from operator-mono-lig.

I think the following might allow us to fix this. I'm just not sure how to do it yet. :P

Conditional Features. OpenType and Apple fonts both provide contextual features. These are features which only take place in a given context and are essential for typesetting Indic and Arabic scripts. In OpenType a context is specified by a set of patterns that are tested against the glyph stream of a document.
Contextual features - FontForge
https://fontforge.github.io/editexample6-5.html

I've been doing a bit of practice with FontForge over the last little while, but I'm not sure yet how to do this. I keep reading little snippets about contextual regex options being available in OpenType. But it's all way down the list of things to figure out for me right now.

Note: the above link is for the old fontforge. I'm not sure if it's 100% relatable to the newer versions. I included it as a reference point for what to look for in either application.

from operator-mono-lig.

I ordered this book: Fonts & Encodings

It has a section on substitution tables that hopefully will point me in the right direction.

See Search result

from operator-mono-lig.

@kiliman freat news! Looking forward this update.

Thanks for the hard work!

from operator-mono-lig.

@kiliman I'm up for testing as well if you need an extra set of eyes!

from operator-mono-lig.