Nice. How about a second font with just the pressed keys? You could overlay it on top of this one in a different color. This might open up new uses for this font.

I second Meek's suggestion.

You may want to include the full keyboard graphic (no keys pressed) as your first glyph (Capital A) in this proposed pressed-key font. Both to preserve accurate alignment between layers when using the two .ttf files, and also for a useful alternate coloring approach.

The best way to preserve alignment would be to make both fonts monospaced (Preview > Advanced > Spacing).

A very interesting concept. 10/10

The main technical reason for adding a full-size keyboard graphic in the next edition (aside from its graphical usefulness) is to preserve the vertical component. The FontMortar, anticipating a wide variety of grid sizes, defines a ratio between brick and point size based on overall vertical extent and a given formula. This way, FontStructions hundreds of bricks tall do not set 10x taller than FontStructions tens of bricks tall at a given point size.

I wonder if Rob would release that mathematical formula? I assume the baseline has something to do with the vertical height calculation as well...

I have run into the same problem with some of my pixel fonts: when making outline versions, the resulting outline TTF shrinks down considerably when compared to regular's TTF. Even thought the pixel font is 8 pixels high and the outline font is only 10 pixels high (or 9 above the baseline), I have to use the resulting outline TTF at double the size (!) of the relugar TTF to match up. (Example: Regular TTF = 8 pt, but Outline TTF = 16 pt to match!)

It also appears that once a height value is chosen by the Font Mortar (through saving the progress of your font), it cannot be reduced by removing vertical pixels. At least, that's been my experience; I could be wrong about this.