Bitmap v scalable fonts
Bitmap fonts are incredibly easy to make. Using a program like Softy or BitFonter you decide the size of your letters and start plotting pixels. You can see exactly how it will look because you draw every glyph (letter/symbol/number) in every size you want to support. This can obviously be very time consuming and doesn’t let you take full advantage of the resolution of the device and the capabilities it offers. A printer can handle in excess of 300 dpi while a display is typically 72 dpi (Mac) or 96 dpi (Windows) with LCD’s supporting sub-pixels due to the individual layout of the red-green and blue elements you can’t feasibly pre-plot every single combination and even if you could the file size would be rather large.
Rather than having specific set of pixels to turn on or off TrueType, OpenType and PostScript fonts contain a series of instructions that tell the computer the shape using a series of points, lines and curves. This means the computer can scale the glyph to the size that is required and then take full advantage of the device being rendered honoring the users preferences for anti-aliasing (smoothing using shades of grey), sub-pixel precision (smoothing using hints of red, green and blue to take advantage of the layout of colour elements in an LCD display), desired contrast and gamma settings etc.
Such a scaled glyph won’t fit perfectly within a pixel grid and a small sizes and low resolution it can look awful. It is also necessary to ensure that the vertical part of the letter I (known as a stem) looks very similar to the stem of other letters at the same size – we don’t want some letters looking bold – and that the top of the letter o aligns nicely with the top of the i etc. (in most fonts). The glyphs themselves don’t know what is a stem, what should align with other glyphs etc.
Many renders include logic to try and improve un-hinted fonts such as the drop-out control in Windows through to the full auto-hinter in FreeType. If you’ve ever used free fonts from any of the numerous web sites around you’ve probably seen that it doesn’t get it right and it looks like this:
The first few versions of Envy Code R looked like that because to address this problem you need to learn a process called hinting, which let’s the designer give the renderer “hints” on how to choose the pixels.
Font hinting started off as stem and edge identification so that glyphs would maintain the right proportions when sized and rendered on these low-DPI devices. It became apparent that a much more fine-grained level of control was required and so a stack-based byte-code language was developed as part of the TrueType specification to allow designers finer control in how points are adjusted to better take advantage of the display characteristics.
A TrueType font can contain extra blocks which describes, using a sequence of bytes that represent instructions and their arguments, the process by which to align the points and therefore make decisions about how best to fit the letter into the grid by retaining and adjusting various elements.
The important blocks are:
|fpgm||Font program||Run once when font first used to setup the tables.|
|gasp||Grid-fitting and scan conversion||Table specifying when to apply smoothing and grid-fitting based on size ranges.|
|prep||Control value program||Run every time the font needs to be drawn differently (e.g. change of size, changing anti-aliasing etc)|
|cvt||Control value table||Set of tables that can be used to specify various heights, widths, spacing, positions etc. that glyphs can relate to.|
Each instruction (opcode) has a mnemonic that is representative of what it does and these are documented in Chapters 5 through 6 of the TrueType specification (along with much other useful relevant information). Actual per-glyph instructions are stored with each glyph outline in the glyp block.
Rasterizing & rendering
There are many different ways a TrueType font can end up on your screen with a lot of variants between how vendors chose to render the font and what options they expose to developers and users to fine-tune the experience.
- Windows – User choice of 1-bit, 4-bit grey-scale anti-aliasing, ClearType, ClearType tuning and display DPI plus WPF and DirectWrite per-app options
- Mac OS X – User choice of sub-pixel anti-aliasing strength and 1-bit cut-off plus per-app 1-bit option (e.g. Terminal)
- Java – Per-application choice of 1-bit, grey-scale or sub-pixel rendering
- Flash – Per-application choice of 1-bit or grey-scale
- FreeType – Rendering library that exposes a number of runtime and compile-time settings
This is of course ignoring the other rendering engines out there such as the Adobe’s Photoshop, RiscOS, D-Type rendering engine, Font Fusion (used on BeOS) etc. and prior versions of those renderers listed above (Flash and Mac OS changed significantly). Getting it pixel-perfect on every combination is impossible but we can try :)
Instructing fonts is a painstaking process at the best of times and few people deal directly with the low-level instructions instead relying on tools, stem identification and higher-level languages to achieve the same result. Some tools that have support for hinting instructions are:
- FontLab Studio 5
Comprehensive font-production package for Windows and Mac that includes auto-hinting and it’s own higher-level link language that it can generate TrueType instructions from but it does not support viewing or modifying existing TrueType instructions and does not handle diagonals well. Rendering preview includes mono, grey-scale and ClearType. (Commercial $649)
- Fontographer 4.1
Rather dated font-production package for Windows and Mac. (Commercial $349)
Comprehensive font-production package that runs on X11 that includes auto-hinting and the ability to disassemble and edit existing TrueType instructions as well as debug them with stepping. Includes basic mono/grey-scale rendering options. (Open source)
- Microsoft Visual TrueType
Hinting instruction tool from Microsoft that uses it’s own higher-level VTT Talk language that compiles down to TrueType instructions that you can further edit. Includes a comprehensive set of preview rendering options but is not capable of disassembling existing instructions. (Commercial, free with signed licence agreement)
Python scripts that can convert a font into an editable XML representation and back including disassembly and assembly of TrueType hinting instructions. (BSD)
Command-line tool that provides an alternative C-like hinting language. (GPL)
FontForge scripts to provide an alternative XML-based hinting language. (GPL)
Windows tool for displaying TrueType fonts and glyphs including debugging and descriptive disassembly of instructions. (GPL)
Real-time editing of hinting instruction mnemonics and observing their effects which is useful for learning. (Free, no longer supported)
I know, I said there would be a good chance that the next version of Envy Code R would be out this weekend but the annoying sizing, thickness and cropping issues that came up at some sizes above and below the optimum 10 point were really annoying me.
Many articles later, some playing around with Microsoft Visual TrueType and much frustration and experimentation later I think I’m on the right path.
Here is how Envy Code R is looking on Windows right now with standard font smoothing.
ClearType doesn’t look as good and I’m still learning the black art and the implications of each type of hinting instruction.
Strangely, these hints seem to be ignored on the Mac which is still rendering everything a little too thick especially on curves. Perhaps that is why so many developers create a Mac-specific version?
Once I’m happy with how the regular version works I’ll put it online for download and then whip the bold and italic variants in to shape and any feedback into regular for the proper 0.7 release.
A newer version of Envy Code R is available.