From: Andrew C. West (andrewcwest@alumni.princeton.edu)
Date: Wed Jun 02 2004 - 03:32:12 CDT
On Tue, 1 Jun 2004 22:50:53 -0700, "Doug Ewell" wrote:
>
> I bet if someone took the trouble to look through enough children's
> literature and driver's testing materials, they could find at least one
> document that uses the STOP SIGN inline in a sentence, and that could be
> cited as sufficient evidence that it should be encoded.
And perhaps Michael would be kind enough to prepare a proposal for traffic signs
if you asked nicely ;)
> Everything I thought I knew about encoding symbols is wrong.
>
I think that I agree with you on that.
I suggest that everyone interested in the question of encoding symbols have a
close read of Annex H "Criteria for encoding symbols" in N2652R ("Principles and
Procedures for Allocation of New Characters and Scripts and handling of Defect
Reports on Character Names"), as this details the criteria against which
Michael's dominos etc. proposal should be judged.
A few gemane quotes from Annex H :
H.5 Discussion
Any proposal to encode additional symbols must be evaluated in terms of what the
benefit will be of cataloguing these entities and whether there is a realistic
expectation that users will be able to access them by the codes that we define.
This is especially an issue for non-notational, non-compatibility symbols.
...
As a conclusion, any successful proposal would need to contain a set of
non-notational symbols for which the benefits of a shared encoding are so
compelling that its existence would encourage a transition.
H.6 Some criteria that strengthen the case for encoding
The symbol
-- is typically used as part of computer applications (e.g. CAD symbols)
-- has well defined user community / usage
-- always occurs together with text or numbers (unit, currency, estimated)
-- is required to be searchable or indexable
-- is customarily used in tabular lists as shorthand for characteristics (for
example, check mark, maru etc.)
-- is part of a notational system
-- is used in 'text-like' labels (even if applied to maps and 2D diagrams)
-- has well-defined semantics
-- has semantics that lend themselves to computer processing
-- completes a class of symbols already in the standard
-- is letter-like (i.e. ordinarily varies with the surrounding font style)
-- itself has a name, (for example, ampersand, hammer-and-sickle, caduceus)
-- is commonly used amidst text
-- is widespread, i.e. actually found used in materials of diverse
types/contexts by diverse publishers, including governmental
H.7 Some criteria weaken the case for encoding
There is evidence that
-- the symbol is primarily used free-standing (traffic signs)
-- the notational system is not widely used on computers (dance notation,
traffic signs)
-- the symbol is part of a set undergoing rapid changes (short-lived symbols)
-- the symbol is trademarked (unless encoding is requested by the owner) (logos,
Der grüne Punkt, CE symbol, UL symbol, etc)
-- the symbol is purely decorative
-- the symbol is an image of something, not a symbol for something
-- the symbol is only used in 2-Dimensional diagrams, (e.g. circuit components)
-- the symbol is composable (see diacritics for symbols)
-- the identity of the symbol is usually ignored in processing
-- font shifting is the preferred access and the user community is happy with
that (logos, etc.)
H.10 Perceived usefulness
The fact that a symbol merely seems to be useful or potentially useful is
precisely not a reason to code it. Demonstrated usage, or demonstrated demand,
on the other hand, does constitute a good reason to encode the symbol.
This archive was generated by hypermail 2.1.5 : Wed Jun 02 2004 - 03:33:39 CDT