Programming ligatures and `locl`
Belleve Invis
Posts: 269
Recently many programming typefaces provides ligatures for operators, i.e., `!=` will be look like `≠`. However some operators may have different meaning in different languages, for example, `/=`, the meaning of this symbol in Haskell differs from that in JavaScript.
So consider a similar situation that the same letter has different shapein different langauges, is it possible to provide different ligarues for different programming languages using `locl` feature?
So consider a similar situation that the same letter has different shapein different langauges, is it possible to provide different ligarues for different programming languages using `locl` feature?
0
Comments
-
locl lists languages, not programming languages.2
-
Belleve Invis said:Recently many programming typefaces provides ligatures for operators, i.e., `!=` will be look like `≠`
Really? Is it just me, or is this terrible practice? Usually the idea is to not have OT features mess with the underlying data stream, i.e. not to substitute anything by other encoded characters (just glyph variants are fine). In your example, ≠ is not just a prettier representation but actually a distinct character from typing the != sequence — and ≠ is not part of the programming syntax. Which could cause problems on a data level (think searching or copy-pasting your code) if that ≠ is actually encoded as ≠, but even if it isn’t, I also find it problematic on a recognition level: You read a character that as such is not part of the syntax. Which, imagine learning programming that way and then having to code in a different font where the ≠ won’t do anything.
I may well be missing something (in which case please enlighten me) but personally I would get rid of a programming font with such inbuilt magic — and/or confusion — very quickly.
7 -
It's worse than that.The features in these fonts don't mess with the underlying data stream - they provide ligatures which look like other characters but actually aren't them. So != will look (a bit) like ≠ but will not actually be ≠ - ≠ will be a distinct character; ... will ligate to an ellipsis but it will not be the same ellipsis as …; -> will look like → but will not actually be →, and so on.It's like mimic, only people are doing it to themselves.2
-
@Simon Cozens
I am considering about creating some "quasi-ligatures" like `->` with the slash enlonged. However I do not think that providing `≠`-like or `≤`-like symbols is a good idea.0 -
Ligatures don't actually change the underlying data; they're simply rendered glyph substitutions for the sake of looking nicer. So, yes, ligatures can be used in programming fonts without affecting the code itself.The bigger question I have is why a programmer would want ligatures distorting the visual representation of the code and making the differentiation between the various individual characters more difficult.I'm not a programmer, but I've been hand-coding HTML/CSS for many years. For me a good monospaced font, like Source Code Pro (which I'm using as I write this offline), is perfect.All this considered, there are instances in programming and scripting languages when a string of ASCII characters are used to represent a single token. So I suppose a -->, for example, being represented as an actual arrow occupying three monospaced slots might be visually preferable and understandable to some. Really, though, it seems to add even more confusion than it might eliminate. A better solution, in my opinion, would be better integration of Unicode into programming languages.1
-
So I suppose a -->, for example, being represented as an actual arrow occupying three monospaced slots might be visually preferable and understandable to some. Really, though, it seems to add even more confusion than it might eliminate. A better solution, in my opinion, would be better integration of Unicode into programming languages.
This is a terrible idea to switch '-->' to an arrow in a code environment. Because '-->' means the end to a comment block in a lot different languages – the arrow on the other hand does not mean anything. The code will still work but will confuse people quite bit. Coding fonts should never do anything like this (≠, --> ...).
1 -
Cory Maylett said:A better solution, in my opinion, would be better integration of Unicode into programming languages.0
-
Nina Stössinger said:Belleve Invis said:Recently many programming typefaces provides ligatures for operators, i.e., `!=` will be look like `≠`
Really? Is it just me, or is this terrible practice?
Staring at valid code patterns has a funny effect of burning itself into the brain, so substituting something as essential as a "!=" might actually be confusing. Scanning the code, using search & replace patterns, syntax highlighting... There's situations where you might be programming patterns that include the "!=" combination, but not as an "not equal", but as part of some string or other pattern. For example search all occurrences of "foo" followed by a space, followed by a "!=" followed by a space, followed by "bar" you might write as a regular expression like "/^foo\s\!=\sbar$/- your OT substitution is not context aware and will horribly distort the meaning and readability of a string like that.
It's great typographers turn their attention to coding, but substitutions seem like a very bad idea to me (as someone with a programmer's background). You are talking about an activity where mistaking "'" for "’" can crash your business' servers, or the difference between "!=" and "|=" makes traffic lights switch from red to green - don't mess with what people are reading and writing and leave them with their ascii.2
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports