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