There is a disappointing amount of good quality open documentation on how font rendering should be done, and a lot of haughty arrogance from people who should know better.
The worst thing I have noticed on my travels around the net is the disdain for anti-aliasing technology generally, and the disrespect for solutions which aren't suffixed with the word "Type." In particular, Microsofties are very late to the game here, yet mention anti-aliasing and they say "ClearType," which is really the wrong end of the stick and too little too late.
As an example of what I mean, nearly all anti-aliasing methods used on popular platforms (i.e. not RISC OS) set a threshold for rendering anti-aliased type. Great, this is a good idea. Except that anti-aliasing is used *above* the threshold and not *below* it. Large point sizes do not benefit from anti-aliasing, because aliasing does not dominate large letter forms. The best example I can think of is a character which is 200 dots wide on a 200 dots per cm printer: do you notice the dots on that device within such a character? I think not.
It is small font sizes which benefit from anti-aliasing. They also benefit from subpixel addressing (at very small sizes), scaffolding and hinting (at larger sizes.) These things need to be combined in artful and intelligent ways to produce an aesthetic result.
The wrong approach, which persists today, is to have someone hand draw aliased versions of small fonts at fixed sizes. This technique results in the same font having a different aesthetic at each size it is rendered at, which is distracting. It is also a lot of wasted time and space, if you ask me. Computers should be doing the rendering at small sizes (just at they do at large sizes,) not humans.
If you talk about anti-aliasing for any length of time, you'll come across these people which complain about the grey mass that letters dissolve into at small sizes. Well, what else would you expect? The computer to say "ah-ha, if you render that font that small, the strokes will be too small to make pixels turn black, so I'll substitute this other font instead where the strokes are a pixel wide!" This is truly evil. Typography is all about positive and negative space, and the aesthetic, and the art: change the stroke width and you change the font. This is typesetter's business, not the computer's, and not Microsoft's. And by this I mean the computer and Microsoft should keep their nose out of this business, and (unfortunately) this is not to say that they don't actually conduct such shoddy business in today's computer market.
But one thing a computer probably should do is shift the strokes, with a designer's guidance (the scaffolds and hints to which I refer above), so that they more closely align with the available pixel grid. This is what the RISC OS FontManager has been doing for nearly 20 years. But even here, there comes a point where the shifting would dominate the designer's original design, and at this point the best we can do is create different renderings for each character depending on where it falls in an imaginary subpixel grid. RISC OS is unfortunately still about 10 years behind here, though it does divide pixels in two on each axis and is aware of arbitrary raster backgrounds. You'd be surprised by how far hinting and scaffolds take it, however: after all, who uses really small sizes and expects a legible result? You're violating hundreds of years of good typesetting rules there!
My main point is that it is not particularly hard to make a font system which scales well in terms of software engineering discipline and in terms of raster rendering. It is also not hard to design a stroked, or outline, font which appears legible at small sizes, yet is entirely rendered by computer. But still people insist this is all very hard, and we should keep our noses out of this very difficult business. Pshaw!
Kasoft is a registered trademark of Kasoft Software, owned by Kade Hansson.
Author and editor:
Kade "Archer" Hansson; e-mail: archer@kaserver.orgLast updated: Monday 9th May 2005