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.

most modern platforms ignore some or all hinting

Is this true?
How much hinting does Windows ignore?

embedded bitmaps are pretty much extinct.

A damn shame.

hhp

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.

Correction: making something half-assed is pretty straight forward, but it's an ethical wormhole.

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

How much hinting does Windows ignore?

It depends on the rasterizer and display settings, but any subpixel rendering (ClearType) pays less attention to x-direction hints, and subpixel positioning (DirectWrite) means that any given glyph could render slightly differently depending on its location.

None of this to suggest that hinting is useless—particularly (mainly?) for Windows—just that the variety of platforms and settings makes webfonts a poor mechanism for delivering "pixel precise" icons.

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

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

That's correct. Almost all systems today subpixel render in x, and the majority pixel render fonts in y, aligning the baseline, descent and ascent, 3 y features, to the grid. All other features in y and all features in x are rendered by most systems without hints.

This may be why icons are "over" and big skinny type is replacing them.

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? I thought that was bitmaps. Doesn't that work OK? Only on iOSX*?

* I just made that up. Go with it dude.

hhp

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

So can we do that too? Anywhere?

hhp

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.

I agree, but mostly I'm wondering about how it works, and how possible (and safe...) it is to co-opt.

hhp

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.

(Argh, editing troubles)

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!

Ah, wait. The bitmaps are in the same order as glyph ids. Translating glyph names to character names, I get images such as "u26c5.png" ("Sun behind clouds") -- and "u0032_u20E3.png" (a proper ligature, "2" followed by "enclosing key cap"), as well as an interesting application of the Regional Indicator symbols. These are also ligatures, and the one for "GB" (U+1F1EC, U+1F1E7) looks like this:

.. but it doesn't contain the Dutch flag ..

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

Theunis, great digging.

Only Apple's own software can display these glyphs

What would it take to overcome that?

hhp

What should the "Duh" look like?

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

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

(g) take your pick. Any particular candidate in mind? :-)

Hrant, I'm not sure what part is picked up by Apple's code. Perhaps it's just the presence of the "sbix" table that triggers "oh let's use a bitmap here, and look up the closest one for the current display font size". I inserted them into InDesign (which I already knew wouldn't display them, due to Adobe's own Type rendering code) and then, heh heh, exported to PDF to see what Apple's Preview shows. Alas, nuffin'.

Code-wise, it would not be a real big challenge to mimick what Apple does. But I don't think FreeType and their likes are going to add this on short notice. (Of course, if you are doing your own font rendering, it should be as easy as I describe above.)

I'll experiment some more, see if I can add a bitmap or two to one of my own fonts. At the very least, it'd be a nice surprise for users of your font if they happen to be using it with one of Apple's programs that support this.

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

Japanese teen girls, a political force of their own.

Trumped by the all-powerful cat lobby at every turn however.

there is a "cuneiform sign Duh"

Go with it dude! What does it look like?

hhp

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 mean this?
http://www.fileformat.info/info/unicode/char/12083/cuneiform_sign_duh.png
Isn't that just a placeholder for the Cuneiform block?

"Doh," it shows only a generic place-holder.

That's out of this world. They could at least show a balding yellow head.

hhp

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's more like a "Duuuuuh". :-)

hhp

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.

Rock on Theunis!

hhp

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.

Theunis, do you by any chance know how to code in Python? I have the unpacking part of the sbix table format working as an extension of the Python FontTools, the ‘only’ thing missing would be the compiling function for the sbix table.

If you’d like to take a shot, I’d be happy to send you what I have got. I’d donate the code to the FontTools project if eventually somebody makes it work. I’d do it myself, but my time is really limited right now.

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 [bitmapfonts]

Fontographer can output BDFs (although it can't embed them); that's how I once made 5 sizes of bitmaps for Arasan (and used SBIT to embed). There are other tools too, including some that make color BDFs (which I once used to embed 16-gray bitmaps, which sort of worked - in fact much better than that MS passage implies, although still not robustly enough). But the problem isn't making or embedding them, the problem -as you imply- is that these days they get largely ignored. :-(

But maybe Apple has opened up an opportunity (which is quite ironic considering their anti-pixel font rendering philosophy).

It will only work on Apple's Mac OS X

What about a Windows plug-in/extension of some sort?

If you are concerned for the quality of your font at smaller sizes ....

Well, I have successfully made outline fonts that render out precise grayscale patterns at specific sizes (with special software by the now-defunct Ultrafonts):
http://www.themicrofoundry.com/manademo/
Although they don't work as robustly as they used to...

The thing is, now that we're getting 250+ dpi screens I do have to admit it's becoming moot (although I still don't agree with Apple's full-fuzz philosophy). So the impetus now is something else, something that can't be done with current rendering/formats: color!

Jens, good to have you here - my hope is now doubled! :-)

hhp

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

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.

Do you think it would be possible to build something like this into RoboFont?

Would that be better than metafont?

I honestly do not know. If sufficient time and energy is invested in either developing or supporting the efforts of development in any of the major tools then perhaps one is as good as another? The extensibility and comparatively friendly user interface (compared, for example with FontForge) of RoboFont combined with your expressed familiarity (on these boards) is what led me to ask.

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

I worked on my code some more and present to you: How to generate colour bitmap fonts.