Hasklig style ligatures

[i-am-the-slime]

This'd be so cool:
https://github.com/i-tu/Hasklig

[metaskills]

Agreed, was the first thing I looked for in this project.

[GauthierPLM]

I'm looking for that too. But not only for Haskell related ligatures (a big part of Hasklig ligatures are Haskell specifics), but for more general programming ligatures as available in FiraCode who have a lot of ligatures available, and a big part of them are common programming symbols.

[chrissimpkins]

For those who aren't aware of ligatures in source code typefaces, see the Fira Code site which has a nice set of images that show the ligatures compared to the actual glyph combinations.

I have been torn on the standard ligature issue. While it works very well in circumstances when you are working in an editor with the typeface and know that the ligatures are present, it misinforms readers when the typeface is used to display source code to others (print, websites, presentations, embedded in pdf's, embedded in applications). You can imagine a scenario where a developer who is new to a language attempts to use a Unicode leftwards arrow ← rather than a < adjacent to a - because that is the way that it was displayed in the location where they learned it. In these cases, the type interferes with the message. IMO, this limits the scope of a font with standard source code idiom/char combination ligatures and my goal is to maintain the main branch of Hack as a general use face for source (including display and embedding).

The OpenType discretionary ligature feature (off by default, explicitly activated) would be ideal, but it isn't supported by any desktop source code editor to my knowledge so it would not address your request. On the web side, the CSS3 spec includes support for them, but I do not believe that this is widely supported by browsers at the moment either. This does not appear to be a good approach for now.

This would be a great feature for a working font designed for a select group of developers and I think it would warrant a separate build from the general purpose main branch of Hack to support it.

My understanding from the Fira Code and Hasklig documentation is that standard ligature support is spotty at best across current versions of commonly used text editors. I guess this begs the question whether this is worth the effort until that situation changes.

[GauthierPLM]

For editors in Java (like IntelliJ), the OpenJDK have a bug who prevents from rendering ligatures. An issue on the JetBrains bug tracker (https://youtrack.jetbrains.com/issue/IDEA-127539) have been opened to support ligatures into the IDE and a guy from JetBrains has reported the bug to the JDK team.
If it's solved, we can hope that IntelliJ and others IDE in Java should support Ligature.

Currently, I only know 3 OS fonts who provide ligatures for coding + Pragma Pro. It could be a good feature in your font, especially because it's a coding font. Having a separated branch is a good idea or the possibility to customize the font (as with Monoid) could be a good idea, with a warning to suggest users to not use ligatures in their articles.

[alerque]

@chrissimpkins I agree pretty much tit for tat with your analysis here. This can be great for somebody that know exactly what was going on but is a probable source of trouble for anybody unfamiliar with both the programming language and the font features involved. In other worse it would be nice to have but only in the context of an off-by-default feature.

The only thing I can really add is that browser support for CSS3 features that enable alternate ligature sets and other OpenType features is actually pretty broad already and can be used in most scenarios. That's a viable way of providing the feature not only on the web but in a lot of editors that are browser based. Some of them are buggy at the moment but I don't think it will be long before accessing alternate ligatures is viable in a lot of editors.

Terminal based editors (where I live) are another matter. It might take a second version of the font to make that viable at all.

[lozandier]

I also agree with the original poster of this issue for ligatures to be supported.

Regarding the thread about the usefulness of ligatures @chrissimpkins @alerque has started, ligatures are a no brainer to have on by default as ligature by definition enables *monospace *typeface to better communicate the intent of two or more characters than they could by themselves. In the context of code, enable better understanding of the intent of the code

Being a monospace font, editors that can't support them should have no problem having Hack being used like any monospace font.

In other words, they gracefully degrade. It shouldn't be "off" (efforts that deliberately not allow the ligatures to be used out-of-the-box like any other Openttype typeface) as it would break the principle of least surprise as far as the OS. Editor's often by convention make it a opt-in feature since the developers of editor's may find it worthwhile to accommodate users of a non-monospace typeface that may

It's more of a matter of a serious effort be made, more than anything else. If ligatures of a monospace typeface makes the intent of a set of characters in the fixed-width space they occupy more confusing for development (it's a monospace typeface after all), then that typeface has failed the users of that typeface.

This feature is extremely important for languages that encourage or enable functional or async programming paradigms as needed for applications often such as Haskell, Swift, Go (esp. CSP), JavaScript, & etc.

In 2015, it should increasingly be the norm.

[alerque]

I'm sorry @lozandier but I don't buy that line of reasoning. Here's why.

First, OpenType ligatures being off by default is quite normal. Lots of fonts have a few of the more subtle possible ligatures enabled and many more of the possibly disruptive or unexpected ones off by default and behind discretionary flags. The same goes for stylistic alternative glyphs. Usually the more generic glyph is the default and the fancy-pants ones are behind a discretionary flag. This is normal. Nothing about doing this violates least surprise principles.

Second, source code ligatures do not always easily decompose into their component parts. Your typical ligature for fi is barely distinguishable to the untrained eye and it would hardly cross anybody's mind to type anything but an f and an i to get it. On the other hand nothing about seeing what looks like ≠ in my document will make me thing to type ! then = to get the glyph unless I am familiar with the underling programming language's syntax and the relation of that syntax to the meaning and to the ligature glyph. In this sense enabling such ligatures by default for a general purpose font would violate the principle of least surprise.

Third, for a general purpose font that is not aware of it's context, such ligatures would necessarily b wrong in some contexts. You cannot go wrong with the component glyphs but you can be wrong about when a ligature should be rendered. Maybe a code comment was giving an example from another programming language. Maybe something the character sequence is in the terminal for some reason other than being part of source code. Changing this behavior by default across the board would be frustrating for people that didn't know what was happening or how to fix it because it's not normal behavior. On the other hand folks that knew the language they were coding in and that they wanted to see fancy ligatures should have no problem adding the option flag to their font config.

Lastly not all programming languages will be compatible with the some set of ligatures. Whichever ones you enable by default would invariably end up being wrong for some language. On the other hand if you create ligatures and tag them in the appropriate font features table it's possible to create sets that would include all the appropriate ones on a per programming language basis. This would enable power users familiar with a language to enable ligatures for it in their editor for those files without screwing with their minds for languages whose syntax is new to them.

I look forward to having ligatures as an option, but think trying to make them on by default would be a huge mistake for a general purpose font even if it make perfect sense for a language specific or specialty font whose primary purpose was to provide this feature for a known scenario,

[lozandier]

I meant attempting to have workaround that would disable them in contexts
they normally would be enabled by default.

For editors, they would be turned off by default; it would break the
principle of least astonishment if they were all of a sudden on by default.

On Mon, Sep 7, 2015 at 4:08 AM, Caleb Maclennan notifications@github.com
wrote:

I'm sorry @lozandier https://github.com/lozandier but I don't buy that
line of reasoning. Here's why.

First, OpenType ligatures being off by default is quite normal. Lots of
fonts have a few of the more subtle possible ligatures enabled and many
more of the possibly disruptive or unexpected ones off by default and
behind discretionary flags. The same goes for stylistic alternative glyphs.
Usually the more generic glyph is the default and the fancy-pants ones are
behind a discretionary flag. This is normal. Nothing about doing this
violates least surprise principles.

Second, source code ligatures do not always easily decompose into their
component parts. Your typical ligature for fi is barely distinguishable
to the untrained eye and it would hardly cross anybody's mind to type
anything but an f and an i to get it. On the other hand nothing about
seeing what looks like ≠ in my document will make me thing to type ! then
= to get the glyph unless I am familiar with the underling programming
language's syntax and the relation of that syntax to the meaning and to the
ligature glyph. In this sense enabling such ligatures by default for a
general purpose font would violate the principle of least surprise.

Third, for a general purpose font that is not aware of it's context, such
ligatures would necessarily b wrong in some contexts. You cannot go
wrong with the component glyphs but you can be wrong about when a
ligature should be rendered. Maybe a code comment was giving an example
from another programming language. Maybe something the character sequence
is in the terminal for some reason other than being part of source code.
Changing this behavior by default across the board would be frustrating for
people that didn't know what was happening or how to fix it because it's
not normal behavior. On the other hand folks that knew the language they
were coding in and that they wanted to see fancy ligatures should have no
problem adding the option flag to their font config.

Lastly not all programming languages will be compatible with the some set
of ligatures. Whichever ones you enable by default would invariably end up
being wrong for some language. On the other hand if you create ligatures
and tag them in the appropriate font features table it's possible to create
sets that would include all the appropriate ones on a per programming
language basis. This would enable power users familiar with a language to
enable ligatures for it in their editor for those files without screwing
with their minds for languages whose syntax is new to them.

I look forward to having ligatures as an option, but think trying to make
them on by default would be a huge mistake for a general purpose font even
if it make perfect sense for a language specific or specialty font whose
primary purpose was to provide this feature for a known scenario,

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[i-am-the-slime]

How about having two versions of the font? Hack and Hæck. So people can choose themselves whether they want Ligatures or not.

[lozandier]

That doesn't seem to be efficient al all, if the ligatures tables can be in
the font file as any normal font file & then they're disabled (which they
often are ). Why have to files for something that can be represented in one
file?

Even editors that support ligatures wisely make you opt-in of having them
enabled; it's also a usability issue when they both are installed in
systems that have a wide variety of fonts to the extent they need a font
manager app to selectively disable & enable fonts: It's seems excessive to
account for two variants of the same typeface when the only difference is
ligatures.

On Sun, Sep 13, 2015 at 6:26 AM, Mark Eibes notifications@github.com
wrote:

How about having two versions of the font? Hack and Hæck. So people
can choose themselves whether they want Ligatures or not.

—
Reply to this email directly or view it on GitHub
#35 (comment).

Kevin Lozandier
lozandier@gmail.com lozandier@gmail.com

[chrissimpkins]

Thanks to all for the feedback here. I really like the idea of ligatures with the caveats that I expressed in the thread above. I wanted to provide an update on this issue. I reached out to Tal Lemming (@typesupply) and Ellen Lupton to see if they would be willing to lend their expertise on this and a number of other type design related issues with the project. I think that the concept is great and the question is how we execute this without interfering with the information contained in the source.

For the proponents of ligatures, might I ask that you do a bit of research into the breadth of support that there is for these in widely used source code text editors (including for discretionary ligatures) and the level of difficulty that there may, or may not, be with settings to activate or inactivate the ligatures? I know that Andreas Larsen did a bit of work on this for his Monoid project and we can begin by validating and extending the information that he provides in the README on his Github repo. With this information, we can decide whether we need to clamor for more extensive support by the developers of editors and/or improvements in settings / ease of use of settings to take advantage of these OpenType features. This will allow us to have an informed discussion about ligatures in a working font. We can decide from there whether this is more appropriate as a separate build or within the main release.

While use as a working font in source code editors is the most common application of the typeface at this point, it is not the only one. We need to take this into consideration with developments that (1) may not be attractive to all groups of users and (2) could limit, or eliminate, its use for other purposes because we force users to either use new features like ligatures or introduce an inconvenience that they must design around to avoid use in cases where this is optional (e.g. the CSS web font examples provided above). This does not exclude the possibility that we could be creative in our design and create something that addresses these concerns. I am very open to more feedback and will continue to keep an eye on the discussion here.

[alphapapa]

My two cents, if I may: Hasklig-style ligatures are pretty, but they are by no means intuitive in this context. If a user types two characters on the keyboard, and they suddenly turn into a single character that may or may not actually resemble the two characters put together, it appears as a bug in the font or editor.

If a user is learning a new language, and he's reading the docs, and he sees that inequality is written as !=, but then he looks at some code in his editor and sees a ≠, he is going to be confused. Unless he practically has all the ligatures in the specific font memorized, he is likely to be confused.

What if someone wants to search for a symbol? If one is searching for !=, but seeing ≠, he must remember to type in not what he sees, but the hidden symbols behind what he actually sees.

And in this "Unicode age," where nearly every symbol imaginable has an actual code point and character in some system font, how does one know that he's seeing a ligature and not the actual Unicode character?

What if someone takes a screenshot and shows it to people who know nothing of these magic ligatures? What if someone sits down at another person's computer and sees these ligatures?

They can look very nice, but I'm afraid they are just not a good idea for general use. If the build infrastructure can support a custom build with them, then I'm all for giving people options. And if editors begin to support ligatures, then I'm all for having them in the font as built-in alternatives. But they should definitely not ever be a default feature. To do so would condemn the font to be used by virtually no-one.

They are pretty, though. :)