pvc wrote:Now, that I have it almost done, I think I might just as well finish it
I've spent half a day, figuring out how to use hint debugger in FontForge. Turns out that it has to be enabled at compile time. But now, works great as a reference. I also decided to analyze FreeType source code a little bit. It was really good idea, since Apple and MS documentation seems to be missing a lot of stuff that comments in the source document.
Good to hear you get it working! Yes, there are no good docs about vector fonts. At first they look good, but there's always some little detail missing... It worth reading the FontForge and FreeType docs too, they explain things that are not mentioned anywhere else (however they never were intended to be a TTF doc, they just explain things as they describe the user interface / API).
pvc wrote:How exactly did you tackle small size rasterization? Do you just do antialiasing and hope for the best? Or is there some way of making small fonts readable (possibly with just 2 level rasterization)?
Well, for SSFN 1.0 I did a neat trick. First, I counted the points in each coloumn. Those that exceeded a certain limit, I called important coloumns. Then instead of a single interpolation, I've calculated a
contiguous series of interpolations (that I called partitions) in which those important coloumns were always at exact pixel coordinates. Hope this makes sense to you. For example normally you would use one interpolation to scale 100 grid points to 16 pixels. The 48th grid point would be a partial pixel coordinate, and would be rendered non-sharp by the anti-aliasing routine. So if we want the 48th coloumn to be sharp, instead there would be two interpolations, one for 0 - 47 grid points scaled to 0 - 7 pixels, and another, 48 - 100 scaled to the pixels 8 - 16. This guarantees that important coloumns (like the 6 straight vertical lines in the glyph "m") are always rendered with 100% alpha, and that there's always at least a 1 pixel gap between them, even in small sizes.
Then in SSFN 2.0 I simply didn't care, just used a bilinear interpolation, and interestingly everybody (including me) likes those rendered letters much much better
Cheers,
bzt
ps: take a look at the window with the small "m" in the middle on the attachment.
Here you can see the counted points in each coloumns with white at the bottom (normalized). Those that exceed the limit, are continued in a cyan dotted line. Those are the coloumns that specify partitions. For this font and this glyph, there would be a different scaling for 0 - 387, 388 - 421, 422 - 495, etc. coloumns. (And you can also see that the font designer was lazy, as the upper right part of the "head" is one pixel off to the "leg", it is at 421 instead of 422
Expect such errors in all Open Source fonts: FreeSerif, FreeSans, Vera, etc. One has unaligned $, the other has problems with H etc.)
