Hack: 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 [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]

[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 [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]

[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. :)

[chrissimpkins]

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.

[chrissimpkins]

Atom editor now supports ligatures:

http://blog.atom.io/2015/10/29/atom-1-1-is-out.html

[lozandier]

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]

[chrissimpkins]

@lozandier I see. They seemed to push this as news. I don't use Atom.

[lozandier]

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]

[ioquatix]

+1

[treybrisbane]

+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

[chrissimpkins]

@tbrisbane thank you

[chrissimpkins]

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.

[i-am-the-slime]

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.

[chrissimpkins]

Hæck it is

+1 haha! I love this. Thanks for all of this information. Look forward to this discussion.

[wottpal]

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."

[burodepeper]

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.

[GauthierPLM]

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, ...).

[i-am-the-slime]

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.

[chrissimpkins]

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.

[chrissimpkins]

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

[stefan-kern]

does this new repository exist already (didn't find any)? if so, can you please share a link

[chrissimpkins]

@stefan-kern https://github.com/source-foundry/Hack-dev

[chriskrycho]

@chrissimpkins, here chiming in to say I'd love it as well. Just checking in: what's the status on any update—I see the dev repo hasn't been updated in a while? (No rush, just curious. :smile:)

[chrissimpkins]

@chriskrycho Time is short and the list is long! We were using the dev repository to collaborate on a fully scripted build approach as v3.x but @jublo has been tied up with other projects and this has stalled for the moment. That is why you haven't seen commits there. I am working in the development branch of this repository to develop the main sets and work remains very active. We just released a new set of fonts last week and work is underway on the next release (with an available set of testing builds for the first set of changes!). I would like to have solid main sets before I start diverting my time to variants (including requests for sets with different line spacing, condensed sets, and this request for ligatures). All of these requests for new variant builds remain on the list and would definitely move forward more rapidly if there is anyone out there with interest would be willing to help with the work. Consider this an open invitation and stay tuned!

[chriskrycho]

@chrissimpkins Thanks for the quick response! I hear you on all fronts, and am delighted to hear that work continues apace. If I knew what I was doing with typeface _design_ tools, I'd pitch in myself.

[mynetx]

@chriskrycho Thanks for your interest! The scripted build approach that Chris mentioned hasn’t died—it’s just on ice for now. I may be able to resume contributions on this over the next time and will make sure to keep you updated! :)

[Grandt]

My two Knuts worth.
Looking at FiraCode I have to say that I really dislike some of their ligatures. Especially the ones for => and <=, which they translate to ≥ and ≤, only their "equal" line is parallel to the bottom diagonal of the arrow.
IMHO that breaks one of the fundamental needs of any font, especially one used for coding, namely that intent should be easily determined at a glance. the FiraCode versions look far too much like the regular > and < characters. Either the equal line must be horizontal, or better yet, at least that ligature ought to be omitted.
Other FiraCode ligatures do a very good job of making the code less readable.

[i-am-the-slime]

Well you just made a great point why these ligatures do make sense:
=> does not get translated to ≥. It is translated to ⇒, which is what it means. Very easy to get this wrong without ligatures, almost no chance with ligatures.

[Grandt]

Great point regarding catching the typo in my post :)
I'm not against ligatures, I just wanted to point out that some are better than others, and FiraCode's version of less-than-or-equal-to or greater-than-or-equal-to are good examples of bad ligatures IMHO.

That said, most IDE's would probably mark that typo as an error. => _usually_ makes no sense in the parts of the code where it should have been >= and vice versa.

[treybrisbane]

IntelliJ IDEA has just added full support for ligatures!

Has there been any further work on this?

[ignatov]

Hi all, I've just spent several hours tonight and create ligatures for == and != for Hack Regular.
I'm going to add more of them, but the issue is that I'm using Glyphs not FontLab.
@chrissimpkins Could you please give me a piece of advice how to contribute to the main repo with FontLab VI.

Please see https://www.dropbox.com/s/owzd20463aqc40a/Hack-Normal.ttf?dl=0

[Defman21]

Looks good! What characters did you add? != and ==?

[ignatov]

@Defman21 Yes, != and ==.

[chrissimpkins]

@ignatov Thanks for your work on this! My opinion about ligatures is that they belong in a separate developer 'working font' based on Hack (like Fira Code is to Fira Mono). Happy to commit the separate fonts here if you would like. This will require a new set of source. Likely the better option to provide you and anyone who would like to collaborate on this with complete control on its progress is to fork and create a new repository for it. We will point there from these threads and I am happy to include information about it in the documentation. Based upon the interest in it over the last several months, I think that you will gain traction from the ligature crowd who will be more than willing to suggest visually appealing ligatures for code editors. This works well for those who know that the ligatures are present and expect these character changes in the body of the source text.

Anyone else out there interested in this work feel free to chime in about the best approach for progress to happen with this ligature derivative of Hack.

And this should go without saying, but please take advantage of your libre rights and do feel free to make derivatives of Hack to create new things. This is a good thing and all of us who have committed to the project would love to see it used as an upstream for other projects (as we have done with DejaVu and Bitstream Vera).

[treybrisbane]

@ignatov Good stuff! :D

Any plans on forking the Hack repo as Chris suggests above? I'm no font designer myself, but I suspect Chris is right in saying that a dedicated ligature fork of Hack will definitely encourage collaboration on this feature.

[ignatov]

@chrissimpkins @tbrisbane Thanks for the reply. So I'm going to create a separate repo for the font with ligatures.

[chrissimpkins]

:+1: let me know if/how I can help. I can get you started with our ttfautohint hinting scripts if you need. Definitely recommend that you use them. They are tuned to the Hack set.

[caizixian]

+1 for optional ligatures

[chrissimpkins]

@ignatov did you create this fork?

[ignatov]

@chrissimpkins not yet.

[chrissimpkins]

@ignatov no worries. was just going to give users here the link if so

[Brantron]

Is there a link for the new font?

[chrissimpkins]

see @ignatov post below

Hi all, I've just spent several hours tonight and create ligatures for == and != for Hack Regular.
I'm going to add more of them, but the issue is that I'm using Glyphs not FontLab.
@chrissimpkins Could you please give me a piece of advice how to contribute to the main repo with FontLab VI.

Please see https://www.dropbox.com/s/owzd20463aqc40a/Hack-Normal.ttf?dl=0

[skbolton]

Any progress on the ligatures?

[ignatov]

I haven't done anything since summer :–)

[skbolton]

Still hoping this comes around at some point

[ignatov]

Hi guys,
I've just forked the Hack repo and created a prototype with several ligatures. Feel free to use it.
https://github.com/ignatov/Haack/
Your feedback is highly appreciated!

[chrissimpkins]

Response to @ignatov by email for request about build technique for Hack font files:

Sergey-

There is not a fully automated process to build Hack.

For ttf files (recommended for use across all platforms), I built with FontLab V as “pre-hinted” ttf build files, then used our ttfautohint based scripted hinting approach that is contained in the following script file:

https://github.com/chrissimpkins/Hack/blob/master/postbuild_processing/tt-hinting/autohint.sh

This uses hinting settings that are defined in the -TA- files in this directory:

https://github.com/chrissimpkins/Hack/tree/master/postbuild_processing/tt-hinting

These files apply optimized hinting to the main character set files that are used in code. We never ran through optimizations for extended character sets that were not commonly used in code because this was not our goal. If you replicate this approach, you will get hinting in your new ligature characters (ttfautohint hints all characters in the set) but you may need to tweak these if you find that they do not look as intended at certain glyph sizes.

For otf files, the build files are hinted with the built in otf hinting used in FontLab V. You will get good automated hinting of otf files in Glyphs as well (probably better c/w FontLab).

On OS X, the hinting is automated by the operating system and hints are ignored. TTF and OTF files should both look similar and good.

For Windows and Linux, the hints really, really matter (see a large number of the closed issue reports) and I suggest that you investigate how your new glyphs appear at a range of sizes commonly used in code editors if you are targeting these platforms.

Feel free to get in touch if there is anything that you need. Best of luck with the fork! There have been a large number of requests for ligatures. My goal was to create a typeface that could be used as a general face for code anywhere (including textbooks, websites, etc) and the ligature approach was not what I wanted for the main face. It will be a great tool for a “working” typeface intended to be used in editors for individuals who are working on code.

[cvharris]

I tried out Firacode just to checkout ligatures and, although the ligatures are there and good, the rest of the font is not great. I have always loved Hack's attention to detail. Can't wait to see the progress @ignatov makes on Haack!

[ralgozino]

First, let me say that I love the Hack font, Thank you! But lately I've been using Fira Code only for the ligatures. Just came to propose Hack Code as the name for the Hack + ligatures font alternative! :wink:

[chrissimpkins]

@ralgozino Thanks for the note Ramiro! Pinging @ignatov on this. You can find his fork where he is including programming ligatures here:

https://github.com/ignatov/Haack

[chrissimpkins]

@ignatov Sergey, as a side note we are working on a new build and testing chain for Hack that will be fully scripted to eliminate editor dependencies. I am hoping that this simplifies contributions here, provides tinkerers with an approach that allows them to modify fonts for themselves, and that all downstream forks will be able to take advantage of it. Keep an eye on the repo for updates as we move in this direction. Work in progress. It will be released as v3.0 of the fonts.

[ignatov]

That's cool, are you still using FontLab for editing? Is it possible to use an open sourced or at least free editor for contributing?

[chrissimpkins]

@ignatov Yes, I have used FontLab Studio V for most of the editing work in v2.x. The goal will be to support contributions with any editor (including command line editing tools) that can modify UFO source. We are creating the build tool chain directly from the UFO source files with libre OS build software. We are also working on a testing approach with a goal to include a combination of source text file diffs, opentype table error detection, and visual diffs of modified glyphs with each commit. The maturity of OS testing software out there has reached a stage where it seems feasible to begin to implement this. Possibly in a CI testing form, possibly manual.

cc: @burodepeper @spstarr

[chrissimpkins]

@ignatov

Sergey, following the upcoming v3.0 release, I would like to give some attention to a Hack fork that includes source code ligatures. We are modifying the license with v3.0 so that Hack can be used in the name of fonts in any fork (i.e. the reserved font name is going away) if this is of any interest to you. This suggestion was included in a post in this thread (believe someone suggested "Hack Code"). Since you have an existing ligature fork, I wanted to see if this is something that you intend to continue to develop and maintain. If so, this would be extremely helpful (to both me and to those who want ligatures in the Hack sets) and I am more than willing to pitch in to transition your repository to the upstream build tooling so that you can stay current with upstream (non-ligature glyph) changes and build with the same approach that we are using. It will significantly simplify contributions from others so that you can attract contributions of ligature glyphs to your fork (we've added UFO source CI linting, CI build testing on OS X and Linux via Travis, scripted / automated builds from UFO source - including desktop/webfont/webfont subsets, new versioning application that will git sha1 short code stamp font builds, new UFO source diff tool, and more as part of this upcoming v3.0 release). The license transition is (in part and in addition to the removal of the Hack reserved font name) intended to support DFSG and other FLOSS build guidelines so that you will be able to release this font fork on Debian/Ubuntu and other distros that provide build from source guidelines for fonts. Our upstream build tooling (and all dependencies of the build tools...ugh!) is already under review by both Debian and Fedora so this work will be done down the road for anyone who wants to fork the v3.0+ source and release on these distros with the upstream build tool chain.

Let me know if this is something that you have the time/interest in at this point. All build tools are more or less in place in non-master branches and work can begin at any time that this is convenient for you.

For others with an interest in source code ligatures with the Hack upstream sets, I would encourage you to grab a free open source font editor that supports UFO source code and start drawing what you like off of Hack base glyphs in UFO source! The inclusion of these commits will not be difficult via standard Github PR approach in any repository that forks off of our v3.0 source and build scripts.

Let's make this happen.

[chrissimpkins]

@chriskrycho has pounded a flag in the ground on this one (possibly...)! I will start working on a guide for derivatives that details how we add/remove/modify glyphs, build, hint, perform other post-compile modifications, and create our release archives. I am more than willing to pitch in on actual work wherever I am helpful. It will be useful to us to use this as a project to understand how we can be most helpful upstream with commits in order to allow downstreams to cherry pick what they want from the changes here. We may need to update our workflow (and contributing documentation) a bit to make sure that design changes in the source are included as commits without repository changes outside of the source.

It would be helpful for all of those in this thread with an interest in this to start combing your source for ligature targets and maintain a list that includes code point 1 + code point 2 = ligature shape. The more visual you can make the ligature shape examples the better.

[chrissimpkins]

@chriskrycho still something that you want to do?

[chriskrycho]

Want? Very much yes. Time? Sadly, my other commitments are higher right now than I knew. If others want to pick it up, they should; I will not in the least be offended. If you write that guide, maybe I'll be able to get to it in December or, more likely, January–February time-frame.

[chriskrycho]

@chrissimpkins do you have a place you want a list of specific code points to go? I can at a minimum start throwing those together for you, based on my experience using Hack (and Haack) day to day right now.

[chrissimpkins]

@chriskrycho probably be best to place it on the repository for the ligature project.

How's this for a thought to get things off the ground?

• The ligature font ONLY includes ASCII glyph subset of Hack
• Hack is then used as the fallback for all extended set glyphs in editors that use ligatures

This assumes the following:

• ligatures will only be necessary in ASCII set glyphs (for source this should be correct, no?)
• editors where these ligature fonts are used will have the capacity to set a fallback font for glyphs out of range

Thoughts?

I can make the repo and get things moving with this if there is interest in lending a hand.

[chriskrycho]

Strategy sounds broadly correct, and it should be straightforward enough to tweak that strategy (e.g. including more-than-ASCII if necessary) should more data/different use cases emerge.

The one thing I'm unsure about is the fallback font approach. A few notes that way:

• It does work for VS Code, Atom, and JetBrains IDEs.
• It looks like it does not work for Sublime – there's no way to list more than one font there, so there's no idea of a "fallback" font
• I have no idea how that would play in Vim or Emacs, but it's probably going to be at the terminal emulator level—iTerm supports setting a fallback for non-ASCII text, but Terminal.app doesn't (and I have no idea what the story is on Linux or Windows).

[chrissimpkins]

@chriskrycho thanks Chris.

Let's wait for a bit more feedback and can decide if this is an appropriate approach.

FWIW, it would be ideal to simply work on Haack but I have not heard back about time/interest there. How recently has that project been updated, is it being maintained current with Hack upstream, and are PR being accepted / merged from contributors?

I don't use ligatures so this won't be for my own use, but given the interest out there (and opportunity to create some interesting new glyph shapes which seems like a fun challenge) I am willing to contribute time to this.

[chriskrycho]

As far as I can tell, Haack had one release and then the author went completely silent. Alas!

[chrissimpkins]

OK we will revive this. Thanks Chris.

[vikky49]

I patched Hack font with ligatures using this https://github.com/rojiani/Ligaturizer and it really looks good. Its a good alternative till Hack has its own ligatures

[ignatov]

@vikky49 Cool, could you please provide binaries?

[chrissimpkins]

Looks like perhaps they do for regular set only?

https://github.com/rojiani/Ligaturizer/blob/master/output-fonts/Hack.ttf

[chrissimpkins]

@vikky49 worth pushing a repo with those ligature patches and keeping this current with the Hack upstream?

[vikky49]

sure .I can push my binaries ..but the problem is its based off of Fira Code and FiraCode does not have italics .So at the moment only the regular version has ligatures but so far i did not find it as a problem as 90% of my mainstream code that uses is regular font ..Italics are widely used only for comments and stuff for the work i do..

The original version of the script has very limited ligatures .So I modified the script to have many more that are useful

@chrissimpkins to which place do i upload the binary

[chrissimpkins]

Ideally to your own new repository where you can host these changes for others who would like to use the binaries. Mind also posting some images there with what has been implemented so far as source code targeted ligatures?

[vikky49]

@ignatov and @chrissimpkins Here you go ..My version of modified ligatures over the
https://github.com/rojiani/Ligaturizer/blob/master/output-fonts/Hack.ttf

My Version of ligatures binary can be found here

https://www.dropbox.com/s/682w2cb8p0d018h/Hack.ttf?dl=0

[vikky49]

@chrissimpkins sure .Will host all these changes into my repository some time this week and post the link

[chrissimpkins]

@vikky49 sounds great. Let us know when it is available. We are maintaining a thread of derivatives and will find someplace to link these for users.

[vikky49]

@chrissimpkins @ignatov Now the new Ligaturizer has been updated to support all the variants like Bold , Italic and BoldItalic.. I have patched the Hack font again with the latest fonts and removed some ligatures which look very specific for Fira Code like (&&) . I have uploaded the binaries in my repo ..It can be found here

https://github.com/vikky49/patchedFonts-Ligatures

[chrissimpkins]

@vikky49 thanks! Willing to open the scripting that you used to accomplish this so that others can examine & replicate it?

[vikky49]

@chrissimpkins If u mean by the modifications of ligatures that i did ,, sure i can open put it up in a repo

[chrissimpkins]

@vikky49 that would be helpful too (along with images on your README so that users can see what they are getting with your ligature changes), but I was actually referring to a script that includes how you built the fonts with the Ligaturizer project. Possible to add a shell script / Makefile or some other approach that allows users to understand and compile the patched fonts in the way that you did?

[chrissimpkins]

This font renaming script is available for anyone who would like to install Hack derivatives side-by-side with upstream Hack if there is any use in having both installed (e.g., you are using it outside of work in source text where ligatures do not apply)

https://github.com/chrissimpkins/fontname.py

[pyrho]

For those interested I've "patched" @vikky49's ligatured version with nerdfont (powerline glyphs, dev icons etc.).
You can find it here !

[chrissimpkins]

@pyrho ty!

[bensleveritt]

I'm a little confused about the situation now (I got here after stumbling into hæck today). Is there an 'official' Hack Code? Or is @vikky49's patched font the best course of action?

I've tried to follow along, but I can't work out if this issue is still open for 'intent-to-change' or informational purposes only.

[bensleveritt]

Just to be clear. If an 'official' one is on the cards, I'd be willing to spend some time making it happen. I'm really pleased with Hæck, and I think it's pretty far behind Hack now. I'd love to see what's changed.

[Thesola10]

@bensleveritt

As I understand it, @vikky49 has successfully patched Hack with ligatures extracted from Fira Code, but they have not yet released a script describing their patching process, meaning that the patching process cannot yet be merged into the Hack project, and a ligatured font can't be reliably produced and maintained.

[chrissimpkins]

This is correct. There is no upstream Hack ligature set. @vikky49 patches are available. There are no immediate plans to release source code ligatures in this repository however I would be happy to pitch in on an effort to help make this happen in a derivative if anyone wants to take on the maintainer + design responsibilities for that project. There should be a reasonably straightforward way to merge any design changes here with that downstream repository. There is a lengthy story about my concerns with ligatures detailed very early in this thread. Let me know how I can help support this. It has been in high demand for a long time. I just don't have the cycles to tackle it myself.

[soetz]

@chrissimpkins

I'd LOVE to (try to) do it ! Problem being I've never designed/made/coded fonts before.
Do you have any resources so that I could learn how to use all the tools needed for this ?

[joshmcarthur]

Along with @vikky49's patches (which are now a little out of date since they were initially generated and then not maintained), I have found that the Ligaturizer project mentioned above (https://github.com/ToxicFrog/Ligaturizer) builds and releases a version of Hack with ligatures added from Fira Code.

Ligaturizer builds the Liga Hack font from @chrissimpkins's own codeface project, and publishes to their releases page. While the releases don't appear to be continuously build against codeface@master, there are regular updates, so this is probably a good source if you're not wanting to build the font yourself.

In terms of rolling this into this project, I can see three easy-ish options:

1. If Ligaturizer was added as a tool available to the build process of this project, it could prepare a variant of the Hack font with ligatures added as part of the release (Ligaturizer just needs to be pointed at TTF files and can automatically prefix the font name - e.g. Liga Hack, Hack Code, etc, or rename it entirely - e.g. LigaHack)
2. This project could pull in the pre-built font files from the Ligaturizer releases page. This is probably problematic since the font is probably quite out of date by the time it makes its way through the Hack -> Codeface -> Ligaturizer repos and build processes - but it's an option
3. The README and/or other documentation could be updated to direct potential users to the release of Ligaturizer that includes the variant of Hack.

[vikky49]

Sorry..I will soon update all of them again..I have been a bit lazy..I just saw a PR which updates the ligaturizer with the latest Firacode changes.. All the updated fonts should be out in a week

[joshmcarthur]

@vikky49 no pressure! You've made a fantastic contribution for this issue as it is. I just wanted to point out that there's an alternative available if anyone is wanting to quickly grab the release from Ligaturizer

[gaplo917]

Along with @vikky49's patches (which are now a little out of date since they were initially generated and then not maintained), I have found that the Ligaturizer project mentioned above (https://github.com/ToxicFrog/Ligaturizer) builds and releases a version of Hack with ligatures added from Fira Code.

Ligaturizer builds the Liga Hack font from @chrissimpkins's own codeface project, and publishes to their releases page. While the releases don't appear to be continuously build against codeface@master, there are regular updates, so this is probably a good source if you're not wanting to build the font yourself.

In terms of rolling this into this project, I can see three easy-ish options:

1. If Ligaturizer was added as a tool available to the build process of this project, it could prepare a variant of the Hack font with ligatures added as part of the release (Ligaturizer just needs to be pointed at TTF files and can automatically prefix the font name - e.g. Liga Hack, Hack Code, etc, or rename it entirely - e.g. LigaHack)
2. This project could pull in the pre-built font files from the Ligaturizer releases page. This is probably problematic since the font is probably quite out of date by the time it makes its way through the Hack -> Codeface -> Ligaturizer repos and build processes - but it's an option
3. The README and/or other documentation could be updated to direct potential users to the release of Ligaturizer that includes the variant of Hack.

For those who are looking for Liga Hack v3.003, I can confirm that current Ligaturize is not able to build Hack v3.003.

I submitted a pull request to fix that and also created a standalone repository "Ligatured-Hack" which implemented with a fully automated build process to build latest "Liga Hack".

I use Travis CI run a daily cron job to check both Hack / Fira code release version. If CI detected a new font release, it will build a new "Liga Hack" release automatically.

Latest build can be found in https://github.com/gaplo917/Ligatured-Hack/releases

This implementation should be self-maintained that automatically combine latest Hack & Fira ligatures together without any human maintenance 😄.

P.S. A warm reminder, the above implementation use Fira code ligature but not Hasklig.

[cata0309]

@vikky49 what are the names of the IDE and theme from the screenshot above ?