From: James Kass (thunder-bird@earthlink.net)
Date: Fri Apr 17 2009 - 22:21:57 CDT
Asmus Freytag replied to Doug Ewell,
>> The stop sign, like "pictures of cows," is another canonical example
>> presented in the WG2 "Principles and Procedures" document (updated
>> less than a year ago) of what should *not* be encoded. It's
>> interesting to see further evidence of how loosely the principles are
>> applied, in spite of all the protests that UTC is following the same
>> principles in encoding emoji that it followed two decades ago.
>
>If that kind of thing amuses you, try reading the introduction to the
>Unicode Standard. The early versions boldly proclaim many things off
>limits that later happened. From 32-bit character codes to Musical symbols.
>
>I don't see this as problematic. Many of these changes are the direct
>consequence of Unicode's success.
And those which didn’t result from Unicode’s success stem from
allowing marketing people to re-define computer plain-text while
trashing existing principles. Part of Unicode’s success was a
direct consequence of those principles.
>Rather than shoehorn everybody and
>everything mercilessly into the 1988 view of what a global, universal
>character set should be, the developers of the standard have wisely
>adapted to critical needs and allowed the standard to reflect the
>experience gained in developing and implementing it.
Doug’s point was about the current WG2 principles and procedures
document rather than a freeze-frame 1988 book intro.
> That's an
>unquestioned strength of the Unicode Standard.
>
>In that process, the principles have acted and continue to act as
>valuable guide posts. Ideally, all coding problems and needs can be
>covered within the boundaries demarcated by them. When that's not
>possible, a critical and thorough evaluation is performed that looks at
>whether a problem is important enough to address at all, but also
>whether it should give rise to an exception, or to a reformulation of
>the principles.
It’s too bad that a critical and thorough evaluation isn’t *first*
performed to determine if the solution to a perceived problem
is within the *scope* of a computer plain-text encoding standard.
>For those areas where users and implementers MUST be able to rely on
>enforceable restrictions, you have the Unicode Stability Guarantees.
>There you have critical rules that MUST NOT be violated by changes in
>the standard. But there's a reason that principles and stability
>guarantees are not one and the same thing.
The stability guarantees assure us all that certain errors can never
be corrected. As a selling point, I’d be more inclined to focus on
principles. But I suppose it’s too late for that, eh?
>>> It's not sufficient to just point at sets of symbols for that - you
>>> also need to isolate which ones are _common_ symbols in each set,
>>> according to the definition of this concept that I've proposed here.
>>
>> Unless they can be defined as "compatibility characters," in which
>> case all of them must be encoded without question.
>
>Unless the set has been approved as a compatibility character set, in
>which case, the goal is, indeed, to cover it in full.
Even to the point of encoding flags and copyrighted logos.
“Stealth encoding”, as others have called this.
>(That decision does not rest with the proposer, no matter how much you
>would like to insinuate it.)
Non sequitur? I don’t see any such insinuation here.
>The "sets of symbols" I was addressing in that part of my message,
>however, did not include compatiblity character sets, but sets organized
>by category or type of symbol, like ISO safety symbols, UI symbols, etc.
Many UI symbols are just icons, right? Here’s an interesting quote from
this list written by Markus Scherer in reponse to a letter from Christoph
Päper dating from 2002/11/12:
>>> One might argue these aren't "real" characters, but neither are all of
>>> Dingbats and many others. I can see a use for them in plain text user
>>> interfaces, be it an OSD or small LCD, and in documentation of such.
>>
>> In my very personal opinion, these go beyond what should be in
>> Unicode and are only justified for compatibility with pre-existing
>> (pre 1992) character sets. Symbols and logos should be displayed
>> using icons and other pictures.
I agree with what Markus wrote, [such] symbols and logos *should* be
displayed using icons and other pictures. Which means nobody would
expect them to display in plain-text.
Best regards,
James Kass
This archive was generated by hypermail 2.1.5 : Fri Apr 17 2009 - 22:23:39 CDT