Adobe Releases New Openly Licensed Coding Font
tqft writes "From the sourceforge page: 'Source Sans is a set of monospaced OpenType fonts that have been designed to work well coding environments. This family of fonts is a complementary design to the Source Sans family.' License: Open Font License 1.1 (OFL 1.1) (both FSF and DFSG free). Hope to see it Debian (& other) repositories soon."
The example text doesn't really look too much better than Inconsolata. But, hey, who can complain about more liberally licensed fonts?
8ut there are lots of reasons to switch away from Courier. 0ne obvious reason is that l made four easy-to-over1ook typos in this post alone.
Obliteracy: Words with explosions
Which is why the 'allow websites to choose their own fonts, instead of my selection above' checkbox is unchecked on my Firefox :)
Your typos were trivial to spot in Dejavu Sans Mono which, incidentally, is my favorite monospace font! :D
Fighting for peace is like fucking for virginity
There's only three typos in your post and believe me they're very easy to see on a system where fonts are displayed properly instead of being hammered into sub-pixels.
Nope, four:
8ut - 8 not B
0ne - 0 not O
that l made - lower case L not I
easy-to-over1ook - 1 not l
not so easy to see I guess.
Well, the standard is pretty much the Microsoft-Apple TrueType (designed as a competing standard to Adobe PostScript fonts). (Yes, Microsoft and Apple worked on TrueType together, during the 90s when they were fierce enemies). Even then it's not a simple spec because it's actually quite difficult to lay out text nicely.
One of the jobs of a typesetter is to actually arrange the page so the text flows properly, and it's more of an art than a science. It's why TrueType implements a virtual machine to help with the automatic arrangement of characters.
It's also why designing a font is damn hard - creating the character shapes is the easiest part, but doing the necessary back end work to ensure it looks pleasant to the eye no matter the word/letter combinations is difficult (hence the virtual machine). And then there's Unicode, so you have to way more shapes to contend with (luckily a lot of them get by with monospace).
Finally, the licenses reflect the fact that fonts are a tool - so there's a lot of complexity in them. First, printing them out means having to send the font over at times (if it's not rasterized locally), so you need to enable translation of the font to the printer's natively language. Then you need to consider that electronic documents may need to embed fonts in them to look the same on every computer, even the ones without the font, but that embedding is now distribution of the font.
The license is complex purely because copyright law doesn't cover it terribly well. Embedding is a form of distribution and derivative work. Printing can mean creating a derivative work so the printer can rasterize it. Then there may be distribution if you want to send it to a printing press so they need the font as well...
As for raster fonts - they're great, but when you're dealing with high res screens, they start to show their chunkiness. I just wish some of the nice raster fonts were availble as TrueType so they can scale up nicely and be razor sharp on high res "retina" screens.
One of the jobs of a typesetter is to actually arrange the page so the text flows properly, and it's more of an art than a science. It's why TrueType implements a virtual machine to help with the automatic arrangement of characters.
That's kerning. TrueType solves this problem with a static kerning table.
The virtual machine is for hinting - adjusting the outlines so that they still produce reasonable bitmaps at small point sizes. It has nothing to do with the flow of text.
But then, no sane coder uses a light background for coding, right?
Actually a light background is (somewhat counter-intuitively) easier on the eyes, especially in dim lighting scenarios. The reason comes down to the optical properties of your eyes, which we can talk about in camera terms. A narrow aperture creates a broad depth of field, while a narrow aperture creates a very shallow depth of field. Bright scenery requires a narrow aperture and a broad depth of field, while dark scenery (is certainly moodier) requires a wide open aperture and a very shallow depth of field.
That means that the brighter things are, the smaller your iris is, the more movement you can have in your head without your screen really going out of focus. Very dark setups with dark code (the stereotypical coding setup, it certainly looks cool) actually lead to more eye strain than a bright working environment and white background on your code. Eye strain is caused by constantly shifting focus, and that is alleviated by bright environs and bright code. Dark setups can require only a few millimeters of movement before your eyes are having to refocus. Bright setups can give you several centimeters of movement.
Slay a dragon... over lunch!
Let me be more specific. Think about a lower case m. We want each of the three vertical strokes to look exactly the same, even if antialiased. Your eye will really complain if this isn't the case, even on a high resolution display. (If not then don't worry about it, quality anything is not for you. You can save a lot of money on stereo equipement.) Hinting will adjust those three strokes to be equally separated in terms of pixel units, even if exact alignment to pixel boundaries is not possible. Then if you display the same font much larger, the strokes will be allowed to move to the exact positions defined by the artist. Hopefully, showing good taste. That's just the beginning of it, hinting a huge and subtle topic. Trying to pretend it doesn't matter, or actually lowers quality, does nothing but demonstrate ignorance.
When all you have is a hammer, every problem starts to look like a thumb.
Wow, I don't think you could have made his point any better right there.
Your post reminded me of this: http://mrl.nyu.edu/~perlin/homepage2006/tinyfont/index.html
Do what thou wilt shall be the whole of the Law
That's one cause. Excessive illumination is another, as a person with sensitive eyes quickly discovers after staring at a white background for a few seconds and experiencing strain and tearing. Focus changes in particular, do not cause eyestrain in nearsighted people because we are used to blur and have acquired the ability to read text through a much wider depth of field.
Whatever the cause, brightness sensitivity is much more common among the coders I know, and white backgrounds are the worst possible thing to look at. This used to be exacerbated by CRTs with 60Hz default refresh rate. Looking at the 60Hz white background of a default Windows installation causes eyestrain and tearing within thirty seconds, making any work impossible without deep squinting. We thus become proficient at switching the color scheme as quickly as possible. Windows 7, of course, makes this more difficult, as Aero does not support changing the theme background, so a classic theme must first be enabled.