airwindows- shareware, source code, music, art, essays, entire novels, less than entire novels, not even slightly entire novels, rants, demented foolishness, beeps, fonts, web background gifs... by Chris Johnson

Art- Art, drawings, desktop pictures by Chris Johnson.

Essays- Essays, rants, black humor and arguments by Chris Johnson.

Fiction- Novels, works-in-progress, short stories and other writing by Chris Johnson.

Music- Music, MIDI, by Chris Johnson.

Random Stuff- Everything here is too weird or unclassifiable to go anywhere else. Enjoy...

Shareware- Shareware programs with GPL source!

Fonts 
Airwindows Hand-Antialiased Fonts



  This page is dedicated to a particular sort of font I've been making for over a year, hand-antialiased fonts. These are Mac bitmaps- I'll also give instructions on how users of other platforms can reproduce my work and create their own hand-antialiased fonts.
Airwindows formally thanks Microsoft for devising ClearType, and thereby figuring ways to add strange color casts to type on LCD screens, while simultaneously reinventing a technique they may well have first heard of from me. By trumpeting their new idea so loudly, they force me to bring the font pages up to date, and to openly publish all details of my take on the matter- in doing so, I may throw a well-earned monkey wrench into the buggers' plans, but failing that I can at least contribute some very important antialiasing concepts to the Open Source ideaspace.
I'll state up front that I've never seen Microsoft's algorithms or plans for ClearType: I know the details of their LCD screen sub-pixel boundary color fringing scheme only by reading about it in web articles. What I'm laying out is my own invention, which I have been publically using for over a year.
  That said-

  Can you see the difference? Tell which column represents which technique? An odd result of antialiasing done properly is that the resulting text can look blacker than plain text, even though only grey has been added, and in some rare cases black pixels have been lightened to grey! If you noticed that Geneeva and Geneva are spelled differently, that's not an accident- this antialiasing was actually done with Greg Landweber's 'Smoothtype' (of which I am a registered user) and grabbed as a screenshot from Simpletext... but Geneva was never meant to be antialiased, it is one of the most basic Mac application fonts, and so Smoothtype intentionally does not make Geneva look like what you see in the third column (faked in Photoshop, with results identical to what you'd see if Smoothtype did it). Enter Geneeva- and as you can see, the second column shows a Geneva that's even sharper and more contrasty than the purely black and white version.
  One interesting note is that ProFont 9 is very clear with dithercopied antialiasing, but all other sizes rapidly deteriorate. This is because ProFont was originally designed as a Monaco 9 replacement with more legible programming symbols- here's what's happening there.
  Dithercopy-style antialiasing works like this- the text engine makes a offscreen picture double the size it will need. It draws the text at double size, and then dithers it down to actual size again, introducing grey pixels.
  When the font is designed to get the look of a particular bitmap size (such as ProFont 9), then using ProFont 18 and dithercopying it down results in just about exactly what you'd want if you were antialiasing it by hand. However, using the outline font in this way is problematic, as you can see from ProFont 12 in the third column- dithercopying has its weak points. I'll note that it's not fair to blame Greg Landweber for this lack- his system utility also produced the text in the middle column.
  How? In the middle column, Smoothtype finds itself looking for double size versions of the listed fonts- and finding Palatino 28, 24, 20 and 18, ProFont etc. as bitmaps- bitmaps I made knowing what Smoothtype was going to be doing with them. Let's have another look at an example...

  The difference between the methods should be quite clear. There will be some fonts and sizes, such as ProFont 12, which are grotesquely blurred using straight dithercopying, and some which are not so bad, but in general, and given a good text engine (there are some special cases of applications that draw text their own special way and suffer problems having their text drawing toolbox calls swapped out from under them), hand antialiasing is superior to any other technique.
  How is this done? It's pretty simple.

  Take a bitmap font, and double its size. On the Mac this is done by having that size of bitmap be the only type available for that font, and telling a utility called BitFont to produce a double-size bitmap- it will produce a blocky version for lack of any alternative, scaling the original bitmap directly. If this resulting font is used with Smoothtype, it produces exactly the appearance of the original bitmap. You can see the R from Geneva 12 on the left, scaled blockily to 24 point.
  In the middle, you see pixels being filled in. Can you see where the 'negative space' pixels are? For each block of four, you get three gray levels, white, and black. The top of the crossbar is being filled in with gray pixels to antialias it- the lightest of three grays. At right, you see all the pixels filled in to the final values, the resulting doublesize bitmap for the hand-antialiased font Geneeva 12.
  Interestingly, you wouldn't have to put the pixels in logical places- the depicted letter would work exactly the same if all the pixels occupied the opposite diagonal corners of the 'blocks' they darken. However, in case the font gets used or viewed at actual size, it's good to have it looking normal.
  See the top left corner of the R? Sharp, isn't it? Well, you could soften that edge, round it an imperceptible amount, by chipping the top left pixel off it, making that block three-quarters grey instead of pure black. This is an effective way of making soft yet clear fonts, though it is more an artistic tool and wouldn't be very sensible in an automated situation.
  Automated?
  Yes- as near as I can tell, this procedure could be automated. It could be done either as a display engine, or as a generator of doublesize bitmap fonts from a specified outline font. In the latter case, any antialiasing utility would be able to produce the resulting sharp antialiased output, given the full selection of doublesize bitmaps to work from.

How To Do It


  Basically, the rules of hand antialiasing go like this- consider a pixel 2x2 block as the 5 on your numeric keypad, surrounded by 123, 4 and 6, and 789:

Darkening


  • black pixels stay black (unless artistic license dictates otherwise)
  • corner pixels surrounded by only 84, 86, 24, or 26 go to 1/4 grey, depositing one subpixel into their block (5)
  • corner pixels heavily surrounded (like the 147896 between the legs of the R) can be darkened to 1/4 grey as well
  • heavy corner pixels surrounded by 478, 896, 632 or 214 can go to 1/4 grey, but this darkens things a great deal.
  • orientation is always important. The top inside right corner of R above gets a subpixel because it has surrounding pixels at 86, and also 73, but not 9. However, another arrangement with four surrounding pixels, 1379, clearly would not want a subpixel- and 4963, 7963 and 1963 are also clearly inappropriate since the subpixel would be filling a gap that is partially filled by optical illusion anyway...
  • There are conditions where a 1/2 grey level is called for, but determining this algorithmically would require a larger sample than a 3x3 grid, because it's mostly useful smoothing an almost-straight aliased one-pixel line. Such a line works pretty well with simple 1/4 grey antialiasing anyhow...

    Lightening


  • points, or black pixels surrounded by 84, 86, 24 or 26, can have a corner knocked off and go to 3/4 grey for a softening of all edges.
  • curve edges, such as black pixels surrounded by 72, 92, 16, 76, 18, 38, 94 or 34, can be softened to 3/4 grey. Doing so will wash out the font to some extent.
  • line segments such as 456, 852, 753 and 159, should not be lightened.

    Stylistic


  • the above rules, when applied, are best applied consistently or ignored consistently. For instance, on the whole if several letters use a darkening subpixel for 478 and 236 corners (heavy top/left and bottom/right corners) then all letters should use that rule.
  • different fonts will call for different rulesets, but within a font the setting of pixels quickly becomes routine and mechanical, suggesting that an automated program would be quite feasible, and its errors and inaccuracies would likely be insignificant.

    Download


      This isn't academic stuff- it's quite tangible, and while its future is pointing towards automated font processing, its history is solidly based in hour upon hour of ResEdit hacking. Here are the fonts I have produced using this technique.
    Greg Fonts are provided by permission of Greg Landweber. These are hand-antialiased versions of the fonts supplied with Greg's Kaleidoscope- Espi Sans 10 and 12, Espi Sans Bold 10, Tecton 12 and 14, BeBox 12 and Veritas 12. Greg, in turn, has my permission to bundle these freely with his products, or do anything with them he likes, though he hasn't taken me up on that yet.
    OS8 Fonts: these fonts are given names reserved for Apple's fonts- don't use 'em if you intend to use the REAL Sand, Techno or Textile. I've no idea what those fonts even look like. My Sand is angular and sort of like Nordic or something, Textile is very soft and rounded, and Techno is squared off and quite condensed, very economical with menu bar space.
    Palatino Bitmap fonts can be used to supplant your existing Palatino TrueType fonts. I recommend not having the existing bitmaps around (stuff 'em in case you want to return to them later). These antialias Palatino 9, 10, 11, 12, 14 and 16. I decided the larger sizes looked good antialiased from the TrueType... also each font takes hours, as I antialias all glyphs, not just English letters...
    ProFont isn't my font- and unlike the GregFonts, I haven't spoken with the author. For that reason, these are supplemental only- this contains ProFont 18, 20 and 24, of the standard ProFont distribution (not ISO-Latin or Windows character sets). I suggest getting ProFont- it rules.
    SysTeam Fonts is my name for variants on the classic MacOS fonts. You've seen one already- my Geneeva. It comes in 9, 10 and 12 point sizes (which of course means that it includes an 18, 20 and 22 point size for Smoothtype). Also featured are Chicaago 12, which ends up looking quite a lot like Chicago (very few diagonals in Chicago), and Moonaco 9.
    Tech Fonts are the same as the SysTeam Fonts, only they are squared off, angular. The package includes ChicagoTech 12, GenevaTech 9, 10 and 12, and MonacoTech 9. Using all of these results in a very futuristic look! They actually are so angular that there is little left to antialias, but every slanted line is antialiased nicely.
      Enjoy the fonts! Remember, for most of these fonts you must have Smoothtype running or you will see no difference. OS8 Fonts and Tech Fonts are the exceptions, and if you are not antialiasing then these are the only ones that will interest you... if I end up doing more font work and producing more original fonts, the results will appear here.



  •  



    page created Tuesday, May 26, 1998
    last modified Monday, January 25, 1999



    back to
    Shareware
    Shareware programs with GPL source!

    GregFonts.hqx
    69 K binhexed Mac application

    method.gif
    1 K GIF graphic file

    OS8Fonts.hqx
    24 K binhexed Mac application

    Palatinobmp.hqx
    58 K binhexed Mac application

    ProFontbmp.hqx
    12 K binhexed Mac application

    sampletext.gif
    3 K GIF graphic file

    SysTeamFonts.hqx
    34 K binhexed Mac application

    TechFonts.hqx
    31 K binhexed Mac application

    threecolumn.gif
    3 K GIF graphic file

    title.gif
    3 K GIF graphic file