Hack
Hack copied to clipboard
source-foundry
Hasklig style ligatures
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.
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.
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.
@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.
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.
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,
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 [email protected] 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 https://github.com/chrissimpkins/Hack/issues/35#issuecomment-138225930.
Kevin Lozandier [email protected] [email protected]
How about having two versions of the font? Hack and Hæck. So people can choose themselves whether they want Ligatures or not.
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 [email protected] 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 https://github.com/chrissimpkins/Hack/issues/35#issuecomment-139858283.
Kevin Lozandier [email protected] [email protected]
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.
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. :)
from @stefan-kern:
Hasklig: https://github.com/i-tu/Hasklig Monoid: https://github.com/larsenwork/monoid FiraCode: https://github.com/tonsky/FiraCode
all of those fonts come with ligatures for the most common programming operators like:
<* <> <+> <$> ** <|> !! || === ==> <<< >>> <> +++ <- -> => >> << >>= =<< .. ... :: -< >- -<< >>- ++ /= ==
since hack aims to be a code typeface it might be a good idea to include these common ligatures aswell.
Atom editor now supports ligatures:
http://blog.atom.io/2015/10/29/atom-1-1-is-out.html
Atom already did via author style sheet; I've literally used ligatures in Atom for years.
On Saturday, October 31, 2015, Chris Simpkins [email protected] wrote:
Atom editor now supports ligatures:
http://blog.atom.io/2015/10/29/atom-1-1-is-out.html
— Reply to this email directly or view it on GitHub https://github.com/chrissimpkins/Hack/issues/35#issuecomment-152765830.
Kevin Lozandier [email protected] [email protected]
@lozandier I see. They seemed to push this as news. I don't use Atom.
I don't use it often either; I primarily use Vim or Webstorm
On Saturday, October 31, 2015, Chris Simpkins [email protected] wrote:
@lozandier https://github.com/lozandier I see. They seemed to push this as news. I don't use Atom.
— Reply to this email directly or view it on GitHub https://github.com/chrissimpkins/Hack/issues/35#issuecomment-152773376.
Kevin Lozandier [email protected] [email protected]
+1
In response to your request for research, Chris, the FiraCode page on GitHub has a fairly extensive list of editors with and without support for ligatures: https://github.com/tonsky/FiraCode#user-content-editor-support
We’re tossing around the idea of starting a branch of Hack that includes ligatures and will serve as “working fonts” for development in text editors. This will be developed in parallel with the main Hack branch, be released under a new font name, and address the mounting interest that you’ve expressed here.
For those who are interested in this, will you please chime in again with:
- a list of the idioms / adjacent character combinations that should be supported
- a list of programming languages where these are appropriate/inappropriate in your opinion - this will be necessary to create testing tools to support these sets
As you work through the above, I’d ask you to also begin to think about the design of the ligatures that you suggest. As this materializes, we will plan to create issue reports for the ligatures where the design can be discussed in much more detail. It will be impossible to meet everyone’s demands / needs, but ideas are extremely helpful and will drive the design as the set matures.
Lastly, it would be helpful to have at least one individual with development experience in each language that we define as our supported target languages (see above) who would be willing to commit to testing these during the early, active development phase.
Let’s see what we can pull together. Please continue the discussion here for now.
Hi, So Hæck it is :). I am particularly interested in Scala ligatures and can test drive them. The tool I use is IntelliJ idea which has some beta support for ligatures (https://youtrack.jetbrains.com/issue/IDEA-127539).
The single most important character combination in Scala is => which can even be written as ⇒ but that character looks odd in monospaced fonts. Same goes for -> and <-, which are the next most language specific combinations.
In Scala, many popular libraries have also popularised other types of arrows and other combinations deserving of ligatures: ~>, ==>, ~~>, :=.
There are also some other more general purpose characters which occur in a great many languages: ==, !=, <=, >=, ===, ++, &&, ||. I would personally love for the ! character followed by any letter in abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ to translate to a not character: ¬. I have not seen any other font do that. It would leave exclamation marks used in sentences unaffected, since they are followed by a space. Another cool thing would be for nested parenthesis to render following ones a bit smaller, but that wouldn't work for an arbitrary number of them and at low font sizes.
That's all I can think of for now. It got a bit stream of consciousnessy towards the end. Sorry for that.
Hæck it is
+1 haha! I love this. Thanks for all of this information. Look forward to this discussion.
For me would be important implementing the ligatures the "monoid-way" because like in the Atom 1.1 release notes states this is the only one where it is possible for atom to set the cursor between the two ligature-symbols: http://blog.atom.io/2015/10/29/atom-1-1-is-out.html
Note that there is a limitation with FiraCode and Hasklig that does not allow placing the cursor between combined ligature characters like ->. This is a limitation in the Chrome DOM measurement API. monoid does not have this limitation due to the way it implements ligatures."
I am still not pro-ligatures, but otherwise +1 for the "monoid way", because of not breaking the fixed-width paradigm.
From a purely visual perspective, I'm also not yet convinced. The examples of ligatures I've seen so far break up the vertical rhythm of the columns.
I'm looking for classic ligatures first, who are present in a majority of languages :
==, ===, !=, !==, >=, <=, ::, ->, ++, --, &&, ||, .., ..., <<, >>, +=, -=, *=, /=, %=, **, =~, <>, <=>, //, /*, */, <!--, -->, </, />,
A big part of this ligatures could be tested with common languages (CPP, Perl and HTML should cover all ligatures in my list). As @i-am-the-slime, I use IntelliJ IDEA to code, and KDE soft sometime (kate, ...).
Alright some more for scalaz. Wenn schon, denn schon (come on, Kendos-Kenlen just said: "majorité")!
<*>, |@|, |+|, <=<, =<=, |->, >>>, (and the other ways around). Are you using fontforge to make this font? I could try and add some ugly ones that could be improved upon to get the idea across.
goal is to make the development independent of the font editors through UFO source files. It's not there quite yet but that is next in the queue. we are using Glyphs for most of the design and FontLab Studio for table definitions and builds at the moment.
and you are more than welcome to contribute. we will create a new repo and work off of UFO files for this branch. Font Forge supports ufo source
does this new repository exist already (didn't find any)? if so, can you please share a link
