Re: more dingbats in plain text

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sat Apr 18 2009 - 16:41:20 CDT

  • Next message: Joó Ádám: "Re: Entering quotation marks (derives from Re: proposal for a "Standard-Exit" or "Namespace" character)"

    On 4/18/2009 8:28 AM, Doug Ewell wrote:
    > Peter Constable <petercon at microsoft dot com> replied to Christopher
    > Fynn:
    >
    >>>> The Wingdings and Webdings family of fonts, distributed with every
    >>>> copy of Windows for over a decade, absolutely qualify as
    >>>> "compatibility character sets" according to the guidelines being
    >>>> applied for the emoji.
    >>>
    >>> At least Microsoft has always mapped the glyphs in Wingdings and
    >>> Webdings to the PUA.
    >>
    >> Not 100% true. These fonts are encoded in a encoding called "symbol"
    >> -- which means a font-specific encoding. The Symbol encoding uses a
    >> 16-bit representation in the fonts, and typically fonts have
    >> characters mapped from F020 to F0FF. It looks a lot like Unicode PUA,
    >> though strictly speaking it is not.
    >
    > The duck test tends to support Chris. When I type :) into a Word 2003
    > file (thus changing it to the smiley-face Wingding) and copy and paste
    > it into BabelPad, a plain-text but very Unicode-aware editor, BabelPad
    > tells me the character (with font information stripped) is U+F04A.
    > This is within the Unicode PUA, even if Microsoft has a different
    > interpretation of what is going on.
    And, in this case all of you are wrong ;-)

    The way these fonts work, and the way the SYMBOL charset is designed,
    was to allow BOTH the use of ASCII and the PUA.

    To see this, try (on Windows):

    Run Wordpad
    Select Wingdings
    Type F04A
    Press Alt+X
    -> you will see the smiley
    Now type J
    -> you will see another smiley

    In other words, both 004A and F04A end up displaying the same glyph.

    The way the designers of this feature explained this to me (a long time
    ago) it allowed fonts to support the PUA so that they would not overload
    the ASCII codes, but at the same time, existing fonts that were mapped
    to the ASCII range would continue to function, as would existing
    (pre-Unicode) applications that expected symbol fonts to be mapped to
    the ASCII area.

    A./

    This archive was generated by hypermail 2.1.5 : Sat Apr 18 2009 - 16:44:07 CDT