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

Safe stylistic ligatures #287

Closed
CircleCode opened this issue Aug 7, 2020 · 4 comments
Closed

Safe stylistic ligatures #287

CircleCode opened this issue Aug 7, 2020 · 4 comments

Comments

@CircleCode
Copy link

stylistic ligatures are meant to improve both code readability, and code writing.
These are, I think, primary goals of ligatures for monospaced code aware fonts like this one.
The cosmetic aspect is of last resort (and always subjective).

According to these principles, this issue is not at all about wether a ligature is beautiful or not.

When a ligature changes the perceived order of symbols, it goes against code writing.
When a ligature make it not clear what symbol is used, it goes against code readability, and code writing.

Below are some examples as such ligatures that could be reworked to improve either code readability, code writing or both:

  • !==
    The current result seems to indicate that the input is =/=
    There are 2 drawbacks:
    • symbol confusion:
      it seems the input is using a / instead of a !
    • order confusion:
      when you select the first character of the ligature,
      your selection appears to be a = character while it is in fact a !
  • != same problem as !==

Note: this issue is extracted from #11

@philippnurullin
Copy link
Member

@KillyMXI
Copy link

KillyMXI commented Jan 16, 2023

It looks like there is still no documentation for all alternatives ( #8 (comment) ).
Considering the number of variants detected by fontdrop.info now, it might be the time to document them.

Looks like it is hidden under the name ss19.
vscode config can look like this:

"editor.fontLigatures": "'ss19' 1, 'zero' 1"

Were all currently existing ligatures considered for whether they fit the scope of this issue?
!= and !== were the worst offenders. But aren't there more?
>= and <= change the perceived number of characters - does it fit here or only #11?

@philippnurullin philippnurullin removed this from the v2.300 milestone Jan 18, 2023
@philippnurullin
Copy link
Member

Hi @KillyMXI
The documentation is on the way.

  • As for the Spacing only ligatures variant #11 This can be treated as one of the Stylistic Sets. For example ss18.
  • Regarding the Safe ligatures. Maybe you can help me and create a list of ligatures that can be included in ss19?

@KillyMXI
Copy link

KillyMXI commented Jan 18, 2023

I mostly care about #11 and have ligatures off wherever I can until that one is fulfilled. So, I'm not deeply familiar with all ligatures.
The next thing I've noticed - the difference between <|> and |>. The former looks fine even as a spacing only ligature imo, and the latter has no "stencil bridges", making it perceived as a single character.
I just checked - >=, <= , |>, etc - all take the space of two characters, but simple shape and the aspect ratio close to square makes them perceived as a single character, compared to the majority of ligatures.

>= and <= hide the underlying character order (but not the characters themselves). And they are still somewhat hard on eyes to discern from > and <.
The family of |> ligatures combine simple characters in the way that makes them disappear in the new combined simple shape.
I won't take the responsibility to decide where to draw the line for this issue.

("stencil bridge" is actually a good analogy for what I'd like to see more in #11, to have all characters aligned but discrete.)

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

3 participants