Closed smason closed 9 years ago
This issue is also present in Atom on Linux.
I've thought about this and one way to make the ligatures "safer" would be to "wrap" them in spaces so e.g. only `,
<,
=,
=,
>,
` get's recognised
But I don't know enough coding languages to know which ligatures could be "wrapped" in spaces.
https://dl.dropboxusercontent.com/u/3019777/Monoid-Regular.ttf should fix it, please test
Thanks for looking into this! I thought that there was some sort of finite state machine described by the font file. I thought that the table definitions could be reordered to "fix" this bug, but this is only my inference from looking at other similar projects. I've also tried using "Fira Code" and this exhibits what I would consider to be correct behaviour without having the operator surrounded by spaces.
I've just tried using the updated font and it works as expected…
@smason Monoid has a unique approach to ligatures (compared to e.g. Fira Mono and the fonts I've seen so far) in that I don't use ligatures but contextual alternates because I want the font to still be monospaced which e.g. Fira mono isn't.
Details here under "technical issues" : https://medium.com/@larsenwork/ligatures-coding-fonts-5375ab47ef8e
*Fira Code
fixed in 0.61
Hi, I've just been playing with Monoid and found that the character sequence
<==>
(i.e. four UTF code points—<
,=
,=
,>
) only gets rendered as the precomposed ligature:This is under OSX 10.10 and occurs within LightTable and the system program FontBook. I would have expected it to display the non-precomposed code points, or at least not loose the first '<' completely. I've not looked for further examples. This is a bit scary, but otherwise a great typeface! Cheers, Sam