OSDev.org

Hi. I am working on implementing my own TrueType rasterizer for my OS. I got it mostly working but now I am stuck on point coordinate rounding in hinting programs. I have troubles understanding how exactly rounding routine should work.

For example, let's focus on RDTG instruction. Both, Microsoft and Apple docs provide examples of it's usage. But the problem is that they both show pretty special case instead of general one. Namely:

Please note that both freedom and projection vectors are axis aligned and are both the same.
But what would RDTG instruction do if this was not the case? For example, if F and P vectors were not axis aligned and not the same. Plus, there is that thing called minimum_distance. What is it for?

From what I gather, you would round the point by moving it along the freedom vector. I'm no TrueType expert, though.


When rounding, points might get closer together. This is used to keep them from getting too close together.

Before you dig too deep, you should know that most fonts don't have hinting instructions, or a very mediocre ones at bests. Only professional fonts have good hinting code, but they are not for free. Good hinting generators are very (very) expensive proprietary tools, and there are no good Open Source alternatives. Even the best FOSS alternative generates terrible hinting code. Also hinting is a very bad design in the first place, if you change anything in a font (just moving a curve coordinate by one pixel) you can throw it out of the window and start over.

Otherwise I'd suggest to use FontForge, that's a very good tool which has a hinting editor and hinting code assember / disassembler. By modifying the hinting instructions you'll be able to see how it affects the rendering. BTW, it is an Open Source tool, so don't trust its hinting code generator, that's just terrible.

FYI, after quite some time spent with vector fonts, I ended up eliminating hinting alltogether just like Apple does.

Cheers,
bzt

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.


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)?

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).

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.)

@bzt I just realized, you are the author of SSFN. If that's the case then I think I will try it. Would be awesome if your format became kind of our OSDev standard And the demo you have on GitLab looks pretty damn good too.

Thanks for your kind words, but I don't intend to create standards. I've just created a simple scalable font library with as few dependency as possible for my OS. Then I've offered it as FOSS to help out other OSDev members, that's all. Give a star to the repo if you like it!

Cheers,
bzt

Starred! I'm definitely interested in using your library when I get around to UI work.

You accidentally starred the old obsolete repo The new SSFN 2.0 repository is here. Anyway, thanks for the star!

Cheers,
bzt