@tim ahrens Yes, perhaps PUA is the best way to go. In my work in mathematics, I have found that PUA is something to stay away from but in this particular situation, it might be the best solution. Still, sticking with the academic discussion a little longer, I wonder why font access by glyph index is good at the OS level but not at the web level. Part of the world is trying to make HTML5 and associated standards into a new platform for app development — a new OS in a sense. It would seem like being able to address fonts at the glyph level would be a good thing for the same reason it is in OSs.

@richard fink Sorry, whatever you are talking about is not clicking with me either. Somehow you have assumed that I have some sort of specific rendering problem I am trying to solve. I do not. This is purely a philosophical, technological discussion.

Seriously, I’m having a little trouble figuring out what you want to have happen and under what circumstances, and perhaps it’s my fault but I’m trying.

How’s this: As part of EOTFAST – the free EOT maker – there’s a fallback font that contains nothing but solid black boxes. It’s there to verify that the EOT has loaded in IE. It’s in the font-stack right behind the font that’s being tested. If there’s a problem with font, you see the black box, if there is no problem, you don’t.
In my own testing, these days I use a slightly more sophisticated ttf (converted to WOFF and EOT as well) for the same purpose.
Would something like that solve the problem?

Instead of trying to access glyphs by index it would make more sense to use Unicode values from the Private Use Area (PUA), which is intended for cases like you describe. Rather than trying to introduce a new, unreliable, implementation-revealing mechanism, you should use the existing principles that will still work when the font is updated and the glyph order changes.

In some sense, by using a PUA value, you make the statement, “This is not a standardized glyph, please do not apply another font”. I do not know exactly what search engines or browsers do when they encounter PUA values, though. You may be unlucky to have a font with that glyph somewhere down the (explicit or implicit) font stack, when it would display the wrong symbol. The PUA is generally to be used with caution, although having a logo with PUA value is not as problematic and against the standards as using PUA for things like small caps.

No, I was not suggesting turning off font fallback in general. Characters accessed by glyph index are only valid for a single font. As I said, failure to find the font would be considered identical to serving a missing GIF. With the ability to put a webfont on one’s website, and universal browser support for webfonts, the only way the character fails to display is when the website has an error in its construction. As I said, identical to the missing GIF situation.

If I was to advocate a CSS property that turned off font fallback, it would only turn it off for webfonts delivered from the same website as the page. It basically would allow the web designer to say that they absolutely want to know when they have failed to supply the font on their own website.

Paul

“A reference to a glyph index from a missing font would be displayed with a red “X”, just like a missing GIF.

What you are suggesting is – perhaps as a CSS property – the ability to turn off font fallback.
I suggested this on the W3C Fonts mailing list a long time ago, and the idea was considered out of the question. As in “Fuggedaboudit!”
They were right. At the very least, browser support would become a nightmare if the author could defeat the locally installed fallback fonts.

rich

I should have been more clear. If web font access mechanisms allowed specification of characters by glyph index then reading software could at least not misinterpret such characters as some other character. I am assuming, of course, that a glyph index character reference has a different representation in HTML than a Unicode one. If such a character represented a logo, then it would be good to have some sort of “alt text” for such readers (eg, “Acme Inc. logo”). On the other hand, such a mechanism would probably not have much over SVG for this purpose.

I do not worry so much about the “missing font” issue. I hope downloadable web font technology progresses to the point where a reference to a font that is not present on the web server is equivalent to a reference to a missing image file. A reference to a glyph index from a missing font would be displayed with a red “X”, just like a missing GIF.

Of course, all this is fantasy and not going to happen. Sigh.

The names used in the Unicode specification (which are NO-BREAK SPACE and SOFT HYPHEN) are completely irrelevant, the only thing that matters is the index (here, 0x00A0 and 0x00AD). The whole point of Unicode is to have fixed, standardized code points (i.e. numbers), in contrast to old PostScript fonts, which were in fact name-based. Unicode names can even change (although very rarely) so we shouldn’t even think about using them to identify characters.

In HTML, you can write   and ­, which are so-called named character entities. This is equivalent to writing & #xA0; or & #xAD;, as you have pointed out. You could also use the Unicode characters directly if your HTML document is in UTF-8 but the downside would be that you cannot spot them easily in the source code since they look the same.

Paul, your assumption is correct – while some desktop applications allow to insert any glyph from the font (internally handling it by index), this is not possible on the web. The two environments have somewhat different “rules of the game”, therefore we make modifications to the fonts. This is what this series of blog posts is about.

I don’t think webfont mechanisms will ever allow to access glyphs by index. Why do you think this would not interfere with software that attempts to read the page? What would the browser display for that glyph when the font is not available or overridden (such as in Reader or Readability). It would be against the principles of the web as far as I understand them.

Wrong on both counts? Non breaking space has a Unicode ‘name’ and of more use, with your notation, a code point, expressed as an entity, & # x A 0 ; here spaced to allow transmission on a web page. Similarly with the soft hyphen, It is named ‘SOFT HYPHEN’ with code point & # A D ;