On 8/14/2011 12:51 PM, Jukka K. Korpela wrote:
14.8.2011 17:51, Doug Ewell wrote:

This sounds like Jukka expects browsers to analyze the glyph assigned in
the font to the code position for 'a' and decline to display it if it
doesn't look enough like an 'a' (rejecting, for example, Greek 'α'). I'm
not sure that is a reasonable expectation.

That wouldn’t be reasonable, but what I expect is that fonts have information about the characters that the glyphs are for and browsers use that information. Something like that is required for implementing the CSS font matching algorithm:
http://www.w3.org/TR/CSS2/fonts.html#algorithm


Not all documents are HTML or CSS.

Font overloading of this kind is common in many "rich text" documents and not limited to the "Symbol" font. Yes, it makes text non-portable in certain ways. Private use characters would have been a "cleaner" way to achieve the same non-portability. Windows will let you use private use characters to access symbol fonts (not just "the" symbol font), but this feature is not widely used (despite the fact that it dates back to the earliest days of Unicode support on that platform).

Why users voted with their feet (or keystrokes) is not a useful topic of speculation. The fact is, they did.

The question here is whether it's useful to add code additional points to allow plain-text coverage of certain widely spread fonts (of which "the" symbol font is one) so that it's possible to use, for example, automated processes to re-encode font runs in older documents to make them more fully portable.

If there are indeed some characters "missing" to complete that goal, the numbers are small and similar fragments of mathematical symbols have been encoded before. I would see not principled objection - only the question whether these are truly still unmapped (however, I haven't researched these particular characters, so I'm not giving any comments related to them in particular).

A./

Reply via email to