Re: Apostrophes at

From: James Kass (
Date: Sun Aug 26 2007 - 06:02:43 CDT

  • Next message: James Kass: "Control picture glyphs (was Re: Apostrophes at"

    Mark Davis wrote,

    > I□find□this□reasoning□bizarre.↓
    > ↓
    > Simply□because□someone□might□want□a□visible□symbol□of□a□character↓
    > in□unusual□circumstances□like□a□code□chart□or□Show□Hidden□Mode,↓
    > the□font□designer□is□supposed□to□have□an□abnormal□glyph?↓
    > It□is□the□*unusual*□case□that□calls□for□*unusual*□glyphs,↓
    > including,□those□for□space,□tab,□and□others.□



    In order for there to be abnormal glyphs there would have to be normal ones.
    The glyphs in the Unicode charts are informative, not normative.

    This, quite sensibly, leaves glyph design up to glyph designers.

    Which enables developers for non-English user pools to construct appropriate
    control picture glyphs for any character deemed necessary by the developer.
    (And does not prevent developers for English users from doing likewise
    in a manner consistent with the rest of the glyphs in a font.)

    In my letter, I was only referring to VS characters. You had specifically
    mentioned VS characters as an example of characters which must have
    zero-width no-contour glyphs. But, there are existing conventions, as has
    been shown, for other control-like characters, such as ZWJ etc.

    For space characters, tabs, carriage returns, and so forth -- Unicode already has
    special control pictures as characters. If an application needs to show control
    pictures for such characters, the application should first check the font-in-use
    to see if it supports those control picture characters. If so, the application
    should use the glyphs from the selected font as first choice.

    But, Unicode does *not* have control picture characters assigned for many
    of the non-ASCII control characters. What could be more simple and logical
    than storing outlines for glyphs for such characters in the font properly
    mapped to those characters?

    One method which might be better, perhaps, would be to have special control
    picture characters dedicated for *all* the control characters.

    I haven't seen such a proposal yet. But, such a proposal would make more
    sense than any proposal to encode animated icons in a plain text standard.

    (Touché, and winks to those who get it.)

    In the meantime, there's nothing wrong or bizarre about the existing
    practices. Please remember that, as long as the system and font support
    the characters and sequences well, users wouldn't see the glyphs anyway.
    (Unless the font is being called upon to display one of these characters
    in isolation, such as what happens when populating a chart.) And, if
    system and font don't support, then the user gets immediate visibility
    that such is the case, alerting the user to select an appropriate font.

    And, if the user does see control pictures but doesn't want to see them
    for any reason, this user can also select an appropriate font.

    > And□since□fonts□cannot↓
    > be□depended□on□to□always□have□"Show□Hidden"□glyphs,□*those*↓
    > are□the□ones□that□need□to□be□handled□specially□in□rendering.↓

    Agreed, but what you are describing is simply fallback rendering. Any
    font can be called upon to display any character in isolation at any time.
    And there's nothing abnormal about that.

    Best regards,

    James Kass

    This archive was generated by hypermail 2.1.5 : Sun Aug 26 2007 - 06:06:01 CDT