Does BitFonter or one of the other tools from FontLab autohint the outline pixel fonts you can create with BitFonter? Does it do what I am trying to?
BitFonter:
"Achieve the same crisp font quality in other apps by exporting your bitmap font as an Outline Pixelfont, where each pixel is represented as a small square, circle, or another geometric shape."
Outline fonts created with BitFonter will be for a specific pixel per em size. This means that it will only appear crisp at sizes where each "pixel" in the outline version aligns with the device pixels. With other sizes, you will get a mismatch resulting in antialiasing, uneven pixel scaling, or dropout (depending on the rendering settings).
Here's an "18 pixel" outline font I made with BitFonter set at different sizes in Photoshop with antialiasing set to "none":
Your actual output will depend on the OS and application. This font (as a TTF) was used successfully on the Pebble Watch, but they needed to use a different fonts for different sizes, and could only use the fonts at those sizes in order to avoid problems.
I was able to put together a script that works decently to generate something like that, but not offset. It seems to be ok that the corners overlap. I'm looking into finding a better algorithm though, since what I have doesn't handle off pixels that are entirely enclosed by on pixels, like the center pixel in the hash character. I think I might also have figured out how to hint it using Xgridfit so that every pixel scales uniformly, but it involves explicitly calling a macro for every point in every glyph, which I think is workable, but verbose.
BitFonter has multiple options for export to an outline font, but none of them will give the exact inset effect I show above. So I'm pretty sure I did the path offsets in FontLab after exporting from BitFonter. Also, it only exports "pixel" outline fonts directly to FontLab, not to, say, TTF or OTF. So you need to also have a compatible version of FontLab installed, at least for the version I have (3.0.0, Mac). This may be not be true in more recent versions for Windows.
I'm in the process of looking for an open source description of an algorithm to do that, minus the offset, since I think I prefer to leave the corners overlapping. The one I came up with doesn't handle holes that are completely enclosed by all eight adjacent pixels, like in the hash character.
I finally found the time to take a look at the .otb file you posted.
The unitsPerEm is set to 2048, but all glyphs have an advance width of 6144 in the hmtx table. The advance width in the EBDT table is 6 pixels. So I guess the converter equalled 1 pixel to 1024 units, but set the unitsPerEm value incorrectly. From the .bdf you linked to, I think the nominal size of your font is 12 pixels. So the unitsPerEm should be 12 * 1024 = 12288.
I dumped the font to XML with ttx from the Python FontTools, and set the unitsPerEm to 12288, then recompiled with ttx.
Alas, I couldn't figure out how to preview the font. I managed to activate it in KDE Plasma, but it wouldn't display properly when used as terminal font.
I'm attaching my modified version here, again with the .txt suffix.
Hmm. I don't see any of the glyphs in FontForge when I open the one that you attached. I may have set the unitsPerEm to 2048 because I thought that was the standard for TrueType. I don't recall if that one was generated from FontForge, where I have it set to 2048 or by "fonttosfnt -b -c -g 2 -m 2 -o mono_size1.otb mono_size1.bdf". It is drawn as a monospace font with a width of 6 pixels, including one pixel for the spacing between characters.
I think this might no longer be needed though, because I think I might have figured out how to create a TTF from it by tracing the bitmap pixels to squares of 128 font units on each side and adding hinting to force it to scale to the nearest ppem that is a multiple of the ppem it was designed at (16).
If I'm creating a TrueType font from a bitmap font by translating each pixel in the bitmap font to a vector square in the TrueType font, how should I determine the units per em and the size in font units of the vector squares in order for each square to be exactly rasterized to one pixel? Should the units per em always be 2048 for TrueType fonts? Does it depend on the height and width of the characters in the bitmap font?
> Should the units per em always be 2048 for TrueType fonts?
Absolutely not, unless you are making the font for a client who insists on it.
Instead, make your UPM a multiple of your pixel grid (or pixel grid plus padding that fills out the em, depending on how you are doing things.
Also, your life will be vastly easier if that grid is equivalent to some especially convenient number of font units (e.g. like 50 or something).
Google’s Material Symbols icon font was initially on 480 units per em, later on 960, because that worked out to a lovely 20 (later 40) units per underlying pixel at 24 ppem, and similarly 24 (or later 48) units at 20 ppem, and it also made for even amounts at 40 and 48 upm, and I could always have an even half-pixel or apex in the middle of a pixel. Although not everything in that icon set is on the grid, tons of things are.
I can’t say enough how very actively happy I am about having made that particular decision. It has made keeping things correct and spotting errors vastly easier. It’s like the 3rd-best decision I have made in my life after marrying my wonderful spouse, and having kids.
Comments
Here's an "18 pixel" outline font I made with BitFonter set at different sizes in Photoshop with antialiasing set to "none":
Your actual output will depend on the OS and application. This font (as a TTF) was used successfully on the Pebble Watch, but they needed to use a different fonts for different sizes, and could only use the fonts at those sizes in order to avoid problems.
The "pixels" are slightly inset from the grid to avoid overlapping nodes.
The unitsPerEm is set to 2048, but all glyphs have an advance width of 6144 in the hmtx table. The advance width in the EBDT table is 6 pixels. So I guess the converter equalled 1 pixel to 1024 units, but set the unitsPerEm value incorrectly. From the .bdf you linked to, I think the nominal size of your font is 12 pixels. So the unitsPerEm should be 12 * 1024 = 12288.
I dumped the font to XML with ttx from the Python FontTools, and set the unitsPerEm to 12288, then recompiled with ttx.
Alas, I couldn't figure out how to preview the font. I managed to activate it in KDE Plasma, but it wouldn't display properly when used as terminal font.
I'm attaching my modified version here, again with the .txt suffix.
Absolutely not, unless you are making the font for a client who insists on it.
Instead, make your UPM a multiple of your pixel grid (or pixel grid plus padding that fills out the em, depending on how you are doing things.
Also, your life will be vastly easier if that grid is equivalent to some especially convenient number of font units (e.g. like 50 or something).
Google’s Material Symbols icon font was initially on 480 units per em, later on 960, because that worked out to a lovely 20 (later 40) units per underlying pixel at 24 ppem, and similarly 24 (or later 48) units at 20 ppem, and it also made for even amounts at 40 and 48 upm, and I could always have an even half-pixel or apex in the middle of a pixel. Although not everything in that icon set is on the grid, tons of things are.
I can’t say enough how very actively happy I am about having made that particular decision. It has made keeping things correct and spotting errors vastly easier. It’s like the 3rd-best decision I have made in my life after marrying my wonderful spouse, and having kids.