Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ligatures #25

Open
larsenwork opened this issue Jun 4, 2015 · 94 comments
Open

Add ligatures #25

larsenwork opened this issue Jun 4, 2015 · 94 comments

Comments

@larsenwork
Copy link
Owner

Like e.g. https://github.com/tonsky/FiraCode

I'm still trying to figure out how best to solve it technically though

@larsenwork larsenwork added this to the v0.35 milestone Jun 4, 2015
@larsenwork
Copy link
Owner Author

So I think I've figured out how to do some of it. I'm trying to keep this a strictly monospaced font so hack job like combining two characters in to one wider character isn't kosher. Instead I'm thinking about using contextual substitution like this

feature calt {
  sub less hyphen' by ligaarrowleft;
} calt;
feature calt {
  sub less' ligaarrowleft by space;
} calt;

so that all glyphs still have the same width.

screen shot 2015-06-06 at 07 53 14

@larsenwork
Copy link
Owner Author

monoidvsroboto

I've added these so far but having some issues with "calt" and Atom (editor I'm primarily using)

@glebd
Copy link

glebd commented Jul 8, 2015

I wonder if this is going to work in Visual Studio on Windows. Pragmata Pro and Hasklig ligatures seem to work there. In case they work, it would be great to have =>, // and /// for C# in addition to the ones above. Also, for F# (which is cross-platform) |>, <|, <||, <||| (* *), (| |), ::, :>, :=, <<<, >>>, [| |], [< >] etc. would be great. The full list: https://msdn.microsoft.com/en-us/library/dd233228.aspx

@larsenwork
Copy link
Owner Author

@glebd can you check the latest version and see if it works on windows with these ligatures #25 (comment)

@larsenwork larsenwork removed this from the v0.35 milestone Jul 17, 2015
@larsenwork
Copy link
Owner Author

@glebd should => be an arrow like this: ⇒ or what is it used for? I have added // and /// (not pushed yet)

@glebd
Copy link

glebd commented Jul 19, 2015

Yes, I think so: => turns into ⇒ across 2 character widths. Thanks!

@larsenwork
Copy link
Owner Author

@glebd cheers, did you get to test it on Windows?

@glebd
Copy link

glebd commented Jul 19, 2015

Not yet, will do next week

@larsenwork
Copy link
Owner Author

👍

@larsenwork
Copy link
Owner Author

screen shot 2015-07-19 at 22 26 04

@larsenwork
Copy link
Owner Author

Compared to
screen shot 2015-07-19 at 22 33 00

@glebd
Copy link

glebd commented Jul 19, 2015

Niiice

@larsenwork
Copy link
Owner Author

@glebd I don't know haskell but is this something I should fix (comment about >→) https://news.ycombinator.com/item?id=9718099

And are there other similar issues?

@mo-seph
Copy link

mo-seph commented Jul 24, 2015

These are lovely!

I'm writing in a language where => and <= are both arrows, and at the moment it's a bit confusing as:

  • <= gets turned into less than/equal to
  • => doesn't seem to be ligatured
  • <- and <-- are correctly ligatured into arrows

Unfortunately, some of this is language and context dependent. For me there are times when <= is an arrow, and times when it is less that or equal to.

Could the download page (which is great, btw) allow a choice of ligatures as well as just on and off?

@larsenwork
Copy link
Owner Author

@mo-seph cheers,
=> should be a ligature. What editor + OS are you using?
screen shot 2015-07-24 at 10 40 30

<= vs ≤ could be a choice, the easiest (and best thing) would be to add it as an stylistic alternate, but that only works if your editor allows you to add your own stylesheet.

It could also be a downloadable choice but problem is we're currently generating all possible versions (current 3200) so adding it as downloadable choice would require it replacing one of the existing options.

@larsenwork
Copy link
Owner Author

What language uses <= as arrow?

@mo-seph
Copy link

mo-seph commented Jul 24, 2015

An obscure one ;) It's called LCC, and represents messages sent to ( => ) and from ( <= ) agents
(https://bitbucket.org/mo_seph/scalsc/wiki/Representing%20Interactions)

Here's a screenshot, using Eclipse on OSX 10.10
screen shot 2015-07-24 at 09 50 19

The <= on line 7 has been changed to leq as expected, the => on line 8 is un-liga'd, and the <- on line 9 is great ;)

(BTW, these arrows are clearly an edge case, and I suspect your approach works for 99% of the time ;) )

@larsenwork
Copy link
Owner Author

@mo-seph => should be a ligature. What editor + OS are you using?

@mo-seph
Copy link

mo-seph commented Jul 24, 2015

Eclipse, OSX 10.10.4

@flaviotruzzi
Copy link

Ligatures are not working here :( (IntelliJ OSX 10.10.4)

@chase
Copy link
Collaborator

chase commented Jul 24, 2015

@larsenwork It seems like Java doesn't support ligatures, at least not on OS X. Eclipse and IntelliJ are both Java-based.

EDIT: Turns out that IntelliJ's rendering engine doesn't support ligatures, Eclipse does in fact.

@mikebronner
Copy link

Crud, I guess that holds true for PHPStorm 9 as well (built on Java).

@chase
Copy link
Collaborator

chase commented Jul 24, 2015

@mikebronner Since it is a derivative of IntelliJ, I'd say that's safe to assume.

@rkurbatov
Copy link

@mikebronner @chase Eclipse is supporting ligatures, just checked. IntelliJ doesn't - they've changed rendering engine. They are working at this. SublimeText too.

@chase
Copy link
Collaborator

chase commented Jul 24, 2015

@rkurbatov Thanks for looking into it!

@larsenwork
Copy link
Owner Author

@plgruener I think the ~ will get too condensed + it looks ok now because it's not "end-to-end" so it's easier to tell them apart if there are many

@larsenwork
Copy link
Owner Author

@plgruener
Copy link
Contributor

Yeah, priorities! 👍

@ ~~ I just wanted to throw in the idea.

@cabralRodrigo
Copy link

I don't know is this is the right issue but I'm using monoid to develop typescript and the ligatures for the operator !== seems a little odd.

ts

I don't know if is even possible to do something about it, but would be really nice if this could change :)

BTW, awesome font to develop :)

@larsenwork
Copy link
Owner Author

It's how it's designed "notequal + type" "≠="

Any other ideas as to how it could/should look?

@cabralRodrigo
Copy link

I really don't have any ideas, maybe something like this:
n

But I can see that this can be a little confusing with the current !=.

And, if this is this way by design I can get used to it.

@larsenwork
Copy link
Owner Author

@cabralRodrigo yep, I deliberately didn't do like e.g. fira mono because I don't want there to be any confusion between !== and !=

@cabralRodrigo
Copy link

@larsenwork Thanks for your time anyway :)

@luben
Copy link

luben commented Aug 4, 2015

In gEdit ">==>" is rendered like a " ==>" (with leading space) : not that I know of programming language that uses it.

@luben
Copy link

luben commented Aug 17, 2015

Also "foo <- bar" is rendered as "foo - bar"

@luben
Copy link

luben commented Aug 22, 2015

Correttion on the previous comment, regarding "foo <- bar". It renders incorrectly with the Retina face but renders correctly with the Regular one. ">==>" renders incorrecly in both of them

@larsenwork
Copy link
Owner Author

@luben cheers, "<-" is fixed in next update
Because of my approach (using contextual alternates and not conventional ligatures (read why in the medium articles)) random strings of "<", "=" and ">" will render with errors...not sure how to fix this. Other than to include specific solutions for those combinations used by programming languages (e.g. <==>)

@blixt
Copy link

blixt commented Oct 30, 2015

@larsenwork The !== ligature is very confusing to me and was the one thing that stood out to me as something that makes code less readable. To me, and I'm sure many others, it reads pretty much like a broken form of regular "not equals" (because it just has two regular equal signs).

Semantically, identity equals is a three line equals sign (≡) and with a strikethrough it would be equivalent to !==. I would do just like Fira Code does it, which is immediately clear to me:

screen shot 2015-10-29 at 9 41 08 pm

If keeping the current one is something you feel strongly about, could the more semantically correct version perhaps be available as an optional font feature?

@in-in
Copy link

in-in commented Dec 8, 2015

I agree with @blixt. The first time I saw that !== ligature, I thought it is broken. It is look weird in such perfect font. Double m also confusing me.

@larsenwork
Copy link
Owner Author

@blixt a good idea, I will look into it this christmas 👍

@larsenwork
Copy link
Owner Author

@blixt @in-in I have a problem with the "==" ligature though...it's aesthetically doing what e.g. Fira Code does and merge the two equal signs but then it's only by length that you can distinguish it from a single equal sign...not sure what's the optimal solution

@larsenwork
Copy link
Owner Author

screen shot 2015-12-10 at 22 03 45

@in-in
Copy link

in-in commented Dec 10, 2015

You're right, it looks a bit alike.
I tried your sample in editor (Fira Code).
2
You can see different height between lines.

@marnen
Copy link

marnen commented Jan 24, 2017

@larsenwork:

I'm trying to keep this a strictly monospaced font so hack job like combining two characters in to one wider character isn't kosher. Instead I'm thinking about using contextual substitution like this

A belated note of thanks for this idea. That's how I did it in https://github.com/marnen/borg-sans-mono, and I think your work was where I found the technique.

@larsenwork
Copy link
Owner Author

@marnen cheers, I've recently changed my opinion about this a bit though so I think I'll make more ligatures that span multiple letters 🤷‍♂️ 😉

@marnen
Copy link

marnen commented Feb 20, 2017

@larsenwork Does that mean that you're now doing something like this?

sub a_b.left_half b' by a_b.right_half
sub a' b by a_b.left_half

(If you're curious, here's what I did: https://github.com/marnen/borg-sans-mono/blob/master/BorgSansMono.fea.)

@larsenwork
Copy link
Owner Author

larsenwork commented Feb 20, 2017

@marnen essentially yeah, because more and more editors and terminals support this kind of ligatures now (didn't do that when I created Monoid)

Thanks for the link btw 👍

@marnen
Copy link

marnen commented Feb 20, 2017

Right. I don't especially like the idea of the left and right halves being separate glyphs in the font, so I probably wouldn't do it that way unless there were some overwhelming advantage.

@larsenwork
Copy link
Owner Author

@marnen they actually aren't in Monoid either — if it's a ligature that spans three letters then the first two are substituted to empty letters and the third one has the entire ligature. But it's complicated to maintain so normal ligatures is obviously they way to go now that editors support it.

@marnen
Copy link

marnen commented Feb 20, 2017

Does that work in a monospaced font, though? I wouldn't expect it to, at least not with proper caret positioning, hence the space trick that I use in Borg Sans.

@larsenwork
Copy link
Owner Author

that's how all my "ligatures" have been created so far but it's annoying having to substitute with 3 characters instead of just one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests