Re: What is the principle?

From: Asmus Freytag (
Date: Fri Mar 26 2004 - 18:00:25 EST

  • Next message: Rick McGowan: "Public Review Issue Update"

    At 02:03 PM 3/26/2004, Ernest Cline wrote:
    > > [Original Message]
    > > From: Asmus Freytag <>
    > >
    > > There are millions of fonts out there with variations of the zodiac. Font
    > > shifting would seem to be the correct answer to implement glyph
    > > there. (A wrong font will ruin the mood, but not change the identity of
    > > symbol). Math, and some linguistic notations are the opposite: a wrong
    > > font, and you lose the
    > > meaning of the text.
    >It would be nice tho, if there was something like a Private Variation
    >Consider for example, a font that offered both of the common glyph
    >variants of PLUTO. At present, one would be have to be encoded as
    >U+2647 and the other as a private use character, say U+E647. If a
    >Private Variation Selector were available, then one could encode
    >for that font, one form as U+2647 PVS1 and the other as U+2647 PVS2.
    >Thus, even if the document was then rendered using a different font,
    >the connection to PLUTO would still be kept no matter which glyph
    >for PLUTO was used by the author, altho the desired glyph might not
    >be shown. One could perhaps use the existing Variation Selectors
    >to do this unofficially, but that is not sanctioned by Unicode. Indeed,
    >a conforming implementation would have to render them the same
    >as if no variation selector was present. Perhaps the added variation
    >selectors on Plane 14 could be turned over to this usage, as it
    >seems doubtful that they will ever be used for official variations,
    >or a row of Private Variation Selectors could be added
    >as U+E01F0 to U+E01FF.

    There are discussions about variation selector schemes for use with
    ideogaphs, where the problems are well-established. It is conveivable
    that symbols do have similar issues. At the moment, we have only a
    few *standardized* variation selectors for mathematical symbols.

    There are situations where it's not clear whether the whole range of
    core glyphs for a symbol really can be substituted for one another without
    doing some violence to the text. For example, there are forms for
    2114 (the lb or pound symbol). Unicode 2.0 showed a ligature of l b in
    a Times like style with a cross bar, while Unicode 4.0 shows a flowing
    form that looks more handwritten. It is incontestable that both mean
    the same thing. It is less clear that both are equally well recognized,
    so that an argument could be made that users should be allowed to make
    a distinction between them. (Creating a separate font for an isolated symbol
    like that is awkward, so unlike the choice between the forms of the letter
    'a' (with and with out handle) it's not something that's tied to a
    general design approach for a particular font style (and also, the
    two forms of 'a' are much more definitely able to be substituted --
    as long as one does not write IPA ;-).

    For symbols, unlike scripts, it's not a-priori clear whether, when and
    how to unify such variations. Unicode has proceeded with caution in
    this area. That's only proper, since 'characters are forever'(tm).

    However, that doesn't mean that it's not legitimate to re-think, and
    possibly re-evaluate some of these unificattions. [I'm not arguing
    for two versions of 2114 - I'm just taking it as an example].

    Your argument, essentially, is that there is a gray area where it
    would behoove the UTC to not get involved, so leaving the distinction
    to private use - except using variation selectors so as to recover
    the character semantics (and fallback glyph range). I think this is
    a valid thing to consider.

    The downside, to mention this right here, is that private use of any
    form degrades interchangeability, but so does markup relying on the
    availability of specialty fonts. Another drawback is the fact that
    too few systems handle any variation selectors gracefully. The cost
    to low level routines (like comparison) can be substantial. But, as
    we have a foot in the door with some of our standardized variations,
    we might as well figure out what we want to do with this concept.

    In that spirit I appreciate your contribution as an impetus for
    further discussion.


    This archive was generated by hypermail 2.1.5 : Fri Mar 26 2004 - 18:29:52 EST