On your first issue: try and stay semantic— if an icon has a related symbol in Unicode, use its Unicode value. Otherwise assign a PUA value and display it using a CSS replacement technique or (possibly) OpenType substitution. Some relevant links:

On Unicode assignment in icon fonts: Font-Embedding Icons the Right Way

Some common Unicode icon entities: Unicode icons in Web fonts

Unicode character reference: Unicode Character Search

Methods for HTML markup and CSS: HTML for Icon Font Usage

Semantic icon fonts using OpenType substitution:
Symbolset - Semantic Symbol Fonts

Pixel precision? Not likely. Even if you delta-hinted all of your glyphs for small ppem sizes, most modern platforms ignore some or all hinting, and embedded bitmaps are pretty much extinct. A convoluted solution might be to use CSS and javascript to detect device-pixel-ratio, then load/position an image sprite instead of the font.

Is there a guide or some easy way to sort this out?

A couple of big blogs posted about icon fonts a while back and suddenly it's all the rage. I tweeted about my post on the topic yesterday ( typophile.com/node/96583) and got retweets like there was no tomorrow. Oh, you predictable suckers. Problem is, the tutorials gives the impression this is easy. Truth is, it isn't.

Thanks for moving me in the right direction folks. Much appreciated. I'll let you know how things pan out; also bug you when I have the next inevitable question.

-S

any subpixel rendering (ClearType) pays less attention to x-direction hints

That's a bit misleading, I think. Better as a general statement to say that the effect of x-direction hints in subpixel rendering is different from and less pronounced than their effect in greyscale antialiasing, and that specific x-direction instruction types may be ignored completely (as is the case with x deltas in ClearType, although there is a mechanism to turn them on at the individual font level).

If you're going to be controlling how the font is used on your site, you may be better off making a pixel font for each size you need. Fontstruct.com is an easy tool for this. Unfortunately, it will necessarily be vulnerable to people scaling the type up and down in their browsers, and of course Retina display users will notice, but I think those are expected limitations.

BTW/but what about that [Apple] Emoji stuff?

According to this article at Typographica they are, "color bitmaps included at two sizes in a proprietary “sbix” table".

I think that SD Typographica article is a bit of an exaggeration. What I think we see illuminated to some extent there, is the convenient attributes of fonts and Unicode being twisted to suit the needs of a party. As a solution to scalable color icons, it seems pretty narrow and short-sighted. And it gobbled up Unicodes when there are still scripts with 1000s of as yet to be encoded glyphs? A shames.

David: And it gobbled up Unicodes when there are still scripts with 1000s of as yet to be encoded glyphs?

We're not in risk of running out of Unicode codepoints any time soon, so I'm not concerned about them being gobbled up, per se. And I say that as one of the people who made the case against encoding emoji in Unicode, and I agree with you completely that this represents hijacking of the convenience of fonts and text encoding, but that's been the nature of pi fonts, wingdings, etc. for a long time.

...to suit the needs of a party.

Many parties, unless you group as one everyone involved in making and selling mobile phone hardware and software. That's who pushed the emoji encoding through.

A quick peek into the 'sbix' table:

Version: 2 USHORTS, as usual for TTF tables. Version seems to be 1.1
Num Sizes: ULONG -- 6, for Apple Color Emoji v.8.0d3e1
numSizes * ULONG: offset for size table, relative to the start of the sbix chunk

Each size table starts with
Size USHORT
Dpi USHORT
The sizes in the six tables are 20, 40, 48, 64, 96, and 160 pixels (all individual images appear to be square). Dpi is '72' in all of the tables.

Then follow (numChars + 1) * ULONG offsets from the start of the size table. numChars seems to be taken from the maxp table, plus 1 to add a 'last entry' file size.

Each offset from the start of this table points to:
4 zero bytes \
"png " / reminiscent of Apple's File Type/Creator data
.... raw PNG data

The file size of the PNG data seems to be calculated from the offset to the next image; the last one is empty.

There seems to be no direct link from bitmap index to Unicode or the character map. The first 41 images seems to always be of size 0; inverse parallel to InDesign's Glyph panel, where the first 41 glyphs contain visible vector data (the bitmaps are not visible in InDesign).

Useful? I don't think so. Only Apple's own software can display these glyphs, probably through the shared code base for its own glyph rendering. Inserting a Color Emoji here: [*] ("Do Not Litter", U+1F6AF). It should look like this:

(My Shared Code base just got some support. I originally typed this into Safari, until remembering it doesn't allow me to insert an image. It did display the emoji above. Switched to Firefox, Insert image Yes but Color Emoji No.)

[*] Ouch! Typophile does not like Color Emoji and cut off the rest of my post!

I know. We need one for every country, every thing, every thought, every name, and "duh" too. What should the "Duh" look like?

What should the "Duh" look like?

Must... resist... temptation to post someone's avatar...

We need one for every country, every thing, every thought, every name, and "duh" too.

What, no emoji for that? And yet they included both "Alien monster" and "extraterrestrial", as well as 10 different Cat Faces! No doubt due to popular demand from Japanese teen girls, a political force of their own.

Ah, wait: there is a "cuneiform sign Duh" (U+12083).

Fileformat.info shows the symbol for cuneiform sign Duh. Unfortunately, for U+FE048, the Kinya syllable "Doh," it shows only a generic place-holder.

David

You can see a rather ugly rendition of it at
http://www.decodeunicode.org/u+12083
or a somewhat better one in the 12083 slot of
http://www.unicode.org/charts/PDF/U12000.pdf

That was fun! I hard-coded one single image into my OTF (Type 1) generator and then generated a simple font. It works! ... Even though this is a Type 1 font. Must be some serious hacky overrides in Apple's code.

This is in TextEdit; the character '^' contains the bitmap:

One unexpected result is that the original vector data is drawn over the bitmap image. Not only that, it actually got scaled to both size and position of the '^' in my original font. My font generator doesn't allow for no-op drawing, so I had to draw a simple circle for a placeholder. I guess using Type 1 as a base is not that useful, because it doesn't allow an 'empty' drawing that still takes up space -- all ink marking are going to be visible.

You can download the zipped font here; apart from the sbix table, the rest is nothing spectacular.

Tying this back to Sean's question -- apologies for the slight diversion :D

• You can embed optimised bitmaps (pixel representations) into a font (I must admit I don't have a clue how you would make them -- Photoshop? MS Paint?)
• .. although it depends on the end-user's software whether s/he gets to see your painstakingly hand drawn glyphs. Software may or may not use your pixel previews.
• The pixel previews are bound to a pixel size, and you don't know in advance which size(s) would be needed. Therefore, you typically would need to create lots of different sizes.

A few random snippets from Microsoft's TrueType discussion:

Embedded bitmaps are bitmaps that can be added to a TrueType font file. A font may contain one or more embedded bitmaps, for one or more pixel-per-em (ppem) sizes. For instance, a TrueType font might include embedded bitmaps of glyphs that are difficult to hint at small sizes, such as complex ideographs.

[..] The TrueType font format currently does not support gray scale embedded bitmaps.

Is this new-fangled 'sbix' stuff something for you, then?
At first glance you might think so, because:
(1) you can use any color you want, including fully anti-aliased grayscale;
(2) you can provide optimized bitmaps for different pixel sizes.

But, as per tests above, it comes with a few drawbacks as well!
(1) It will only work on Apple's Mac OS X,
(2) .. and then only with selected applications.
(3) You can show a vector over a bitmap, or just a bitmap. On unsupported systems, only the vector part will be visible.

Here is my test font on a Windows 7 machine, in Microsoft Word:

Bottom line is, best to stick to the OTF standard. If you are concerned for the quality of your font at smaller sizes, try and find out how you can generate, hand-optimize, and embed standard black-and-white pixel versions with your software.

Jens, sorry, I have no experience *at all* with Python. I did my experimental unpacking in C (not even C++), and including the image was done with hardcoding the constants in Javascript. No actual 'compiling' was involved.

"I don't have a clue how you would make them -- "

I think we want to make them in a font tool, on a layer(s) that is produced with the option of an instructed outline, where the rendering type and color(s) are defined in the usual way, and the layer(s) are then manufactured into whatever sfnt, and other formats work the widest, web-wise.

Would that be better than metafont?

dberlow, I don't see how it's related to metafont. Did you mean "will it be as unpopular as metafont, or not"?