RE: Apostrophes at

From: Philippe Verdy (
Date: Mon Aug 27 2007 - 21:33:23 CDT

  • Next message: Philippe Verdy: "RE: issues storing ZWSP in docs, files and databases"

    Such specialized fonts for “show hidden” mode during editing will then need
    to map explicitly the variation selectors to some glyph (possibly the
    .notdef glyph if this is desired) The absence of mapping to .notdef should
    mean that nothing was designed for them in the font, and the renderer should
    do its best with that font, and simply discard the supported variation
    selector during rendering (unless the renderer supports itself a “show
    hidden” mode applicable to any font, suing the “show hidden” mode as defined
    in that font where it exists, or implementing it itself if the font has no
    such feature).


    This way, fonts do not need to map variation selectors if they don’t have
    any distinction of glyphs for the same characters followed or not by
    specific selectors. This will be the case for most fonts.


    So the simplest way to solve the problem is not to modify fonts, but enhance
    the renderers so that they treat variation selectors in a smarter way, which
    does not contradict the design of specific fonts that make glyph
    distinctions using variation selectors.


    This leaves the freedom for font designers to map the variation selectors
    only when needed, and simplifies the process of designing fonts for the many
    scripts (or subsets like alphabets) that don’t have such significant
    distinction : The case where the letter “a” has an ascender above it or is a
    single eye taking the whole x-height is such a variation, and a font may
    define only one glyph for one form or the other. Only fonts that have two
    separate glyphs will need to map variation selectors.


    The same case occurs for the form of the descender in the letter “g” (note
    that for IPA, the loop-less descender form of g has a separate code point,
    which accepts no variation, many fonts map it to the same glyph as the
    normal latin letter “g” unless this normal “g” is mapped to a glyph using a
    descender with a loop by default, like “Times”-like fonts, that don’t always
    support variation selectors for the normal Latin letter “g”).


    Note also that most recents version of “Times”-like fonts (such as “Times
    New Roman” for Windows) will support a variation selector for the letters
    “a” and “g” to select the “a” without ascender above it, or the loopless
    “g”, simply because these fonts also support the separate explicit mapping
    for the Latin alpha and loop-less “g” used in IPA. A renderer may consider
    this when seeing how to render “a”+VS or “g”+VS, and the font does not have
    an explicit mapping for the sequence, and may “smartly” remap these
    sequences to the same glyph as the glyphs mapped explicitly in the font for
    the IPA symbols, instead of just stripping the VS not supported explicitly
    by that font…


    I consider this as a candidate RFE (Request For Enhancement) sent to the
    developers of font renderers (including Windows itself in GDI/GDI+ and the
    other related text layout and rendering APIs), but this does not imply any
    RFE sent to font designers that may still choose what they want explicitly
    in their fonts for variation selectors.



    De : [] De la
    part de Mark Davis
    Envoyé : vendredi 24 août 2007 19:47
    À : James Kass
    Cc : Unicode Mailing List
    Objet : Re: Apostrophes at


    If that is a common perception, then we certainly need to correct that

    For general-purpose fonts, the default ignorable code points should be
    invisible, just like whitespace characters should be invisible. Specialized
    fonts, such as those used for a "Show Hidden" mode or for code charts, may
    well want to have visible glyphs for default ignorables, whitespace
    characters, controls, confusable characters, and so on, so that people can
    see the internals of their text. But those are very specialized cases.


    On 8/24/07, James Kass < > wrote:

    Mark Davis wrote,

    >A similar annoyance is the fact that so many fonts don't map the
    >default-ignorable code points (like variation selectors) to a zero-width
    >invisible glyph by default.

    It's up to individual font developers to weigh the pros and cons
    of including control picture glyphs for such characters, as it
    should be.

    Mapping characters like VS to zero-width no outline glyphs would
    mean, for one thing, that applications which give the user the
    option of displaying control characters (and related items) would
    not be able to get appropriate outlines for such characters from
    the font. Opinions on this differ, as discussed on this list in years

    If an OpenType font supports a sequence which involves a VS, the
    user won't see the control picture. If the font doesn't support
    the particular sequence, it can be helpful if that is reflected in
    the display.

    Best regards,

    James Kass


    This archive was generated by hypermail 2.1.5 : Mon Aug 27 2007 - 21:36:38 CDT