Download disabled

The designer of this FontStruction has chosen not to make it available for download from this website by choosing an “All Rights Reserved" license.

Please respect their decision and desist from requesting license changes in the comments.

If you would like to use the FontStruction for a specific project, you may be able to contact the designer directly about obtaining a license.

Certainly not for everyday reading!

10 Comments

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.
Comment by Rob Meek (meek) 7th july 2011
I second Meek's suggestion.
Comment by riccard0 7th july 2011
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.
Comment by William Leverette (will.i.ૐ) 7th july 2011
Wow, three comments already! I like those suggestions; and I will try to get working on it soon.
Comment by ishallcallhimsquishy 8th july 2011
The best way to preserve alignment would be to make both fonts monospaced (Preview > Advanced > Spacing).
Comment by riccard0 8th july 2011
A very interesting concept. 10/10
Comment by p2pnut 8th july 2011
@riccard0: it is monospaced already
Comment by ishallcallhimsquishy 9th july 2011
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.
Comment by William Leverette (will.i.ૐ) 9th july 2011
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.
Comment by Goatmeal 9th july 2011
...........?



Font Mortar?

I'm still sort of new to this, so I don't know as much of the technical side of this.
Comment by ishallcallhimsquishy 11th july 2011

Also of Interest

GlyphsApp

Get the world’s leading font editor for OSX.

More from the Gallery

Etrussby ishallcallhimsquishy
A Hint of Randomby ishallcallhimsquishy
Impaby ishallcallhimsquishy
pixel scriptby ishallcallhimsquishy
MISQONDUKTby japanyoshi
AT Dornachby kassymkulov
Lane Sevenby four
Absinthelyric Printby zephram

From the Blog

News

Gridfolk: Interview with Zephram

News

Heavy Competition Results

News

Heavy Competition

News

Gridfolk: Interview with Jiri Novak