B612 is a highly legible open source font to be used on aircraft cockpit screens
b612-font.com
b612-font.com
I mean most likely the real design goal was to create a cool futuristic looking typeface that would make the planes themselves feel more technologically advanced. I have no doubt legibility was one of the main requirements, but let's not kid ourselves on why this was really commissioned.
They did a great job though. I'm not a typography expert or even a designer, but to my untrained eye this looks like one of the most original and visually impressive typefaces I've seen in a while.
Legibility was a solved problem literally centuries ago.
For print, maybe? But digital displays are a whole different kettle of fish which didn't exist centuries ago.
(Not a rhetorical question; I'm genuinely curious. What was true for NTSC-interlaced isn't necessarily true for 8K.)
I mean look how asymmetrical the characters in this typeface are compared to almost every other sans serif typeface. The way the body of the characters flairs out opposite the ink traps is pretty wild. It almost looks like it was designed using deep learning or something, because how the hell could any human possibly come up with those forms.
Maybe I need to get my eyes checked. (although last time I went doctor said I had better-than perfect vision in both eyes)
On mobile, almost no one can see Verdana.
But it's included in iOS (http://iosfonts.com)?
Edit: the pdf included in the download has both variants of 0, the slashed one at unicode point E007. So it seems it's up to the user to pick one.
”The slashed zero causes problems in all languages because it can be mistaken for 8, especially when lighting is dim, imaging or eyes are out of focus, or printing is small compared to the dot size.”
I think that can be a valid reason to use regular zeroes on all kinds of numeric indicators.
Edit: mostly a problem if you are from said countries tho
”The slashed zero causes problems in all languages because it can be mistaken for 8, especially when lighting is dim, imaging or eyes are out of focus, or printing is small compared to the dot size.”
I think that can be a valid reason to use regular zeroes on all kinds of numeric indicators in airplanes, where context makes it clear that O’s cannot be present.
Also, some passport numbers stay with you for life (China), other change with every passport.
Doesn't dyslexia involve transposing the positions of characters, not mirroring individual characters? Or do some/most dyslexics also sometimes misread letters as their mirror-image counterparts?
Considering dyslexics have difficulties with already very distinct shapes (i.e., most letters are pretty unique), would a relatively subtle difference between p and mirrored q actually reduce the error rate? Or is that "premature optimization" in that the drop in accuracy due to the p-q mirror images is dwarfed by the gain in accuracy of using Futura?
"Dyslexie font does not benefit reading in children with or without dyslexia":
https://link.springer.com/article/10.1007%2Fs11881-017-0154-...
Switching to modal screen-based interfaces happens when there isn't enough room on the panel in question to supply a separate physical control per thing that needs controlling.
Once you've had to do that, though, every remaining knob is a cost that could be removed by adding a few lines of code to the interface software.
A single touchscreen for everything is the natural endpoint of this process.
Because 'ooh, shiny!' That's my best guess, anyway.
Although there is a benefit to being able to deploy a new control configuration with a software change, I think it's far outweighed by having something physical to hold when operating the controls.
… and one wouldn't want the controls one is used to changing anyway …
Plus, fixed touchscreens on cars, planes, equipment, etc. tend to be resistive ones, and those can be very annoying to use even when they're perfectly still.
I was worried about the issue, but in light turbulence, it’s no issue IME and in moderate, it’s maybe less certain than knobs, but I bet even there that I could still enter an accurate flight plan update, whether a new full route and just a direct-to shortcut) faster on the touch GTN 750 than on an old (multi-knob) GNS 530. (That’s not just touch; it’s partially the discoverability and access to “more than the -D-> key” functions.)
I am glad the critical autopilot inputs (HSI heading bug) and other flight controls are not touch, though.
Also, knobs in turbulence are fun. "Turn left 15 degrees" can become a random amount on your heading bug with an unfortunately timed thump!
Anyway, bottom line is that I find it easier to see the relative angles and trends of the pointers in old analog gauges in turbulence than read the tapes. The angles meant something easily interpreted as being unexpected at a glance even if the absolute value might take another moment to read.
Imagine if our AI were two tapes, like the EFIS horizontal and vertical deviation indicators!!
"Transport" font used in UK road signs: https://en.wikipedia.org/wiki/Transport_(typeface) http://www.roads.org.uk/fonts
"Mandatory" font used in UK number plates: https://en.wikipedia.org/wiki/Mandatory_(typeface) http://www.k-type.com/fonts/mandatory/
Relevantly, the EPL 1.0 is incompatible with any version of the GNU GPL (as is the EPL 2.0 by default).
I know for my self, when writing for others I block print rather than use cursive so that they can understand it easier.
This likely has moved over to type as tradition rather than actual usability.
I find that claim to be completely false, as I am learning to read text written in Cyrillic alphabet, when I do actually read the words letter by letter and I even get surprised when I finish reading a word.
In contrast, I can read text in all caps at about the same speed as lower case text. If there's any slowdown, I say I read all caps at 95% of the speed I read text in lowercase.
Later the same page says this: "all-capital text was read 11.8 percent slower than lower case, or approximately 38 words per minute slower".
In that case that later claim completely contradicts the former claim of letter by letter reading, which is IMO about five times slower, not just a few percent points slower.
In any case, ALL CAPS text is perfectly legible, and it is actually more legible than using something like cursive, including lowercase cursive.
All programming languages have a bracket problem; Lisp just has a more intense bracket problem. Until the recent advent of 4K and "retina" displays, it wasn't practical to have significant weight variations in screen fonts for programming. It's now practical, and it's easy in font editors such as Glyphs Mini to swap in or modify brackets to be a lighter weight.
I've made many Lisp coding experiments: with preprocessors that eliminate most parentheses, with alternate symbols, and with various weights and sizes of parentheses. There's something to be said for the theory that parentheses should be lower case, just like identifiers. (I'm reminded of the "GET OFF MY LAWN" effect in Common Lisp; one can shut off the upper case defaults but most people don't stay around long enough to find out.) However, my favorite approach is to make parentheses light, but not too light. There's a sweet spot where you actually love the lightweight brackets, in Lisp code and everywhere else. You're conducting an orchestra, not engaging in a knee-jerk debate; if the trumpets play too loud, teach them to play at the right volume.
It took me ten minutes to swap in ()[]{} from SourceCodePro-ExtraLight, and copy a period into the center of the zero. This a fine Lisp font but not my favorite. I like Input Mono, or Courier Prime Code (both similarly modified).
The Input download can be customized to look nearly identical to B612, only better, and without the O0 and () problems.
That is exactly the opposite of a good programming font. These characters should be extra-tall. They should go at least as low as any other ASCII character, and at least as high as any other ASCII character. An extra pixel (or several on a 4K display) upward would be even better, up there with the accented uppercase letters like A-with-ring.
Lisp is in decline in part because of the community tendency to circle the wagons in the face of any criticism. My single point is that Lisp parentheses are always too heavy, and readability improves with lighter parentheses.
I've also long used Unicode replacements for => and other combined symbols in Haskell. Then I discovered Hasklig, solving this problem instead through ligatures. Any problem one can solve in the font itself is transparent to the rest of one's tool chain. I'm a convert.
Lowercase letters are just as tall as capitals...
And even among the ones you listed, g, p, q, and y are fully as tall as every capital except Q.
Really? Bolded keywords and other tweakery was common on 512×342 OG Mac screens.
I'm trying to understand why lightweight Lisp parentheses haven't been a thing for 50 years. It's so obviously right once one tries it, with sufficient resolution. My guess is that "sufficient resolution" is both key, and recent.
NB Haskell folks are not any more likely than Lispers to think visually. A lot of Haskell code is difficult to read. But it does feel like the Miranda-style syntax (particularly pattern matching) has made the first few steps towards eliminating unnecessary structure-related cognitive load on the programmer.
Lisp partisans will probably reject this opinion, but IMO the presence of strings of matching parens in Lisp isn't something that needs to be restyled with a better font, it's something that needs to be designed out of the language.
Edit: I know this ground has been well-covered in the past. Usually the advice is that by using a proper editor and relying on indentation, parens just stop being a noticeable problem. Whether just restyling parens is cosmetic or not, it seems less powerful even than that advice.
define | edge? g e
let
$ es | edges g
e2 | reverse e
or (member e es) (member e2 es)
(define (edge? g e)
(let
( (es (edges g))
(e2 (reverse e)))
(or (member e es) (member e2 es))))
The central question for any programming language isn't how comfortably it welcomes casual newcomers; it's how effectively it creates a human:machine interface for the committed. Most criticisms of how Lisp looks can be likened to criticisms of a frozen screen from a crashed video game. One needs to play the video game. Lisp acquires its meaning in short time scales from the experience of syntax-aware editing, a live experience. Lisp acquires its meaning in long time scales from the experience of using macros to rewrite the language to exactly suit the problem at hand. Haskell is safer, faster, more densely expressive, but not as plastic. Lisp appeals to woodworkers; other languages appeal to people who like to buy nice furniture, sit in it and get to work. I can see both sides, and I've worked hard to experience both sides.
In terms of Lisp vs the ML family of languages (including Haskell), "absence of syntax" as a guiding principle of Lisp seems to be in contrast to a language community, like Haskell's, that spends more time considering how it will write its own compiler than anything else.
With that in mind, I think it's a bit tendentious to dismiss Haskell users as passive consumers who don't consider the nuts and bolts of their programming language, and Lisp programmers as woodworkers. It's actually very difficult to get anywhere significant in Haskell without deeply committing to learning the Haskell way of doing things (currying, evaluation strategies, monoids and monads, type classes, even continuations etc.) I'd say, from what I've seen, that Haskell has more of a particular, distinct flavour than Lisp, which goes along with coming from that "MetaLanguage" tradition, concerned with codifying (in the language) the routine ways to manipulate structures. It's a culture, and one that happens to be a little bit elitist and not very good at transmitting itself to outsiders. But maybe the only languages that have no fixed cultural elements (abstractions/tropes) to speak of are rudimentary Turing tarpits.
Metaphors about craft vs consumerism aside, a good Lisp programmer and a good Haskell programmer will both know the techniques they are applying. It's not like Haskell is a high-performance car with the hood bolted shut. It can appear that way because they're always trying to polish the abstract principles of the thing and make it more elegantly expressive—it's a research project in that sense. But by the same token, to get the real benefits you have to buy into that academic culture and do the same kind of conceptual thinking you would in Lisp.
Most focus is on transforming code for machine consumption (compilation). But underappreciated I think, is that code can also be transformed for humans. Reversibly (editing), and not (analysis). Colorization and outlining are common. Less common are syntax transforms like yours. Fortress-like mathification. Reverse templating and macros. Intensional programming. The idea of a collaborative-compilation environment with an editor-like UI.
So much potential fun. But so little R&D funding. And a discoordinated profession. So decades slide by.
It's called pretty-printing. The name is underwhelming, but there are some advanced techniques for it.
Including rudimentary, POSIX vi.
E.g. in the normal Scheme code, I can put the cursor on this line:
( (es (edges g))
(e2 (reverse e)))
( (es (edges g)) (e2 (reverse e)))
—
1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...
It's more of being aware that Lisp syntax works different from what most people are used to. The current Lisp syntax was originally an accident, but it survived because it has some interesting and unique properties.
Lisp code is relatively unique because it is written on top (!) of a data syntax.
Thus is has a two stage syntax: a the bottom there is a syntax for s-expressions - which is purely about light-weight syntax for data - not a programming language.
On top of that there is Lisp syntax, which is defined in terms of structured data. This enables code manipulation in terms of programs over hierarchical list-like data. It also enables user extensible syntax via Lisp macros. Thus a program in Lisp syntax can be written as text by serialized data, but it can also be computed in memory.
Thus we'll see code which visually has more of a layout in terms of hierarchical nested lists. For this programs have been written which can produce such a layout from code as data.
Lisp has an aspect of direct manipulation of code as data. You may want to design it out of the language, but few actual Lisp users would do want that - additionally it has been tried multiple times and it has often failed. For example there was a large effort to design a Lisp 2 (as a 'second generation Lisp') with non-s-expression-based syntax. A large effort, which failed and which in the end had very little influence on how Lisp programs look like. There are versions of Lisp like RLISP which had a syntax not based on s-expressions and which is still used in a software which is a computer algebra system. Dylan was another attempt of a Lisp-like language without s-expression based language.
> Usually the advice is that by using a proper editor and relying on indentation, parens just stop being a noticeable problem.
Another advice is to use an interactive programming environment for Lisp to actually make practical use of the unique features of Lisp syntax.
To a Lisp programmer it is more useful to support this dynamic aspect of code as data AND its visual representation - more than losing these capabilities and supporting the idea of code as static text. Tools which support Lisp were for example the Interlisp-D structure editor for Lisp code and the Lisp listener for Symbolics Genera. The latter keeps the connection of the external textual representation of Lisp data and code with their underlying data representation.
Otherwise we would be using ML (nowadays SML or OCAML), which was initially a functional language on top of Lisp written without s-expressions. Languages with more conventional syntax exist already - languages which combine syntax with a data representation are not so common...
Haskell doesn't. It's possible to fix the bracket problem, but it's not C-like so people will be forever complaining and refusing to learn your stupid crazy language.
What makes fonts convey other information? Why is comic sans so derided? (It obviously is.) What makes the emotion of a font come out?
So my assumption would be that to whatever degree humans associate handwriting with things like personality or personal disability, we will tend to associate those concepts with fonts that touch on similar patterns, if that makes sense. (Maybe not explained very clearly.)
But again, I cannot refuse the fact that comic sans is so.. derided and laughed at. Nary a week goes by without someone guffawing at that typeface on reddit or social media.
Any ideas how to measure this? Seems like emotion is the key here.
Emotion is basically a summary of past experience. Relying on "your gut reaction" is a bit more error prone than actually analysing it, in part because it is rooted in personal prejudice, in essence. But in a survival situation, being able to quickly go "Nope! I'm out of here!" can be the difference between life and death.
So emotion based judgements tend to be fairly strong ones. They tend to be of the "Don't confuse me with the facts, my mind is made up" variety.
(The right answer is instead to embed personality and humanity into the words themselves, which is comparatively much higher effort and indeed beyond the skill of many people.)
Over time we've grown accustomed to working within pre-packaged emotional bounds (e.g. the limited set of emojis) and the meme-status of the font has long since passed so it would probably not be quite the same faux pas today as it was two decades ago.
> The design is simple so that it can be easily read by a machine, but it is more difficult for the human eye to read
So, unless your plane is piloted by a robot from the 60s, quite favorably.
B612 seems much more like a Helvetica derivative.
It's not hard to see why people want to make more infinitesimally-different fonts with their own name and a funny ampersand or (in this case) parentheses. What is never explained is why anybody else should care.
I’m not aware of any shared history between Inconsolata and Source Code Pro. Do you know of any? On the on there hand, Inconsolata is heavily influenced by Lucas De Groot’s Consolas.
Normally, when putting in the effort to make something new, one tries to make it better than what came before, on some axis. Introducing a new thing less good than what came before is a waste of our time and a distraction from the better things. I don't doubt that designing SCP or B612 was educational for its designers, but that is not a good enough reason to adopt it, or even to study whether to adopt it.
The new thing should be better. Why is that hard to process?
Using "good" and "better" implies that there's some objective measurement against a common set of criteria, which is not necessarily the case from the standpoint of the designers, nor for those who choose to use the fonts and for what purpose. Better according to you? Sure, but I'd frame that as an opinion rather than objective fact.
For that matter, I don't think you can say that any one of those fonts is better than any other, for anyone but yourself. I find Inconsolata too narrow and cramped on the screen, compared to the wider SCP. And the cute lowercase "t" in Inconsolata is by comparison lost on me after 8 hours of coding, and I don't notice in absence in SCP.
FWIW, I really like Source Code Pro — it's my default font everywhere. Inconsolata is nice, too, but I like the little hook on the lowercase 'l' in SCP. Also, SCP abbreviates to the name of a Unix command, which is cool
The 0 can easily be confused with 8. I personally don’t like the serifs on the bottom of a few letters, like ’i’. And then some others like ‘v’ have an awkwardness to them.
Do you have specific reasons why you prefer it?
I then switched back to Hack, at the same size. With the same frame size, I could then see 64 lines, and the letters were all larger and much, much easier to read. https://i.imgur.com/99Hi6kh.png
If I were to set Source Code Pro to a size at which the letters were the same vertical height as Hack, I'd see something like 50-55 lines of text, instead of the 64 I see with Hack.
What am I missing? Am I doing something wrong that makes Source Code Pro look bad?
Would be interesting to see if there was any discussion about it.
When will they learn? When will we?
Sans faces appeal to graphic designers for graphic-design reasons that have no connection to merit as a means to convey useful information clearly and quickly. Graphic designers prefer details that make text less legible for the actual people obliged to read it, who get no say in what is used.
Maybe it's a matter of exposure? If I spent more time reading books than blogs, I might find serifs more comfortable?
Update: it looks (to me) like the biggest differences are in peripheral vision.
Interestingly, on the web, I still prefer sans-serif (Verdana especially). But perhaps it's because more than a page of two of text is relatively rare, and most sites are really more like apps in layout - a menu, various labels and buttons etc. Or interactive discussion like here, where each comment stands by itself.
For book readers, Amazon's Bookerly is just perfect for reading hours straight. It's not as condensed as many serif fonts, and it keeps all strokes full-bodies, which makes it a lot easier on the eyes, IMO.
I did a brief search for scientific evidence on the topic, and came up with nothing in favor of your position.
The reality, of course, is that there's a vast grey area between "serif typeface" and "sans serif typeface", and this one does sit in that grey area, albeit much closer to the "sans serif" side.