Re: Proposal to encode dominoes and other game symbols

From: Andrew C. West (
Date: Wed Jun 02 2004 - 03:32:12 CDT

  • Next message: Jon Hanna: "Re: Proposal to encode dominoes and other game symbols"

    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