Re: New FAQ page

From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: Thu Oct 11 2007 - 01:41:20 CDT

  • Next message: James Kass: "Coloring plain text and other fancies"

    James Kass wrote:

    >> http://www.unicode.org/faq/unsup_char.html
    >>
    >> Q: How should characters be displayed if the rendering system
    >> doesn't fully support them?
    >
    > The correct answer is that it depends on the operating system and the
    > font(s) in use.

    My first concern with that entry was with the question, not the answer. What
    does "fully support" mean? To take a simple example, consider a system that
    renders text in a given font. For definiteness, let's suppose it's a web
    browser rendering a page that does not itself specify any fonts, so that the
    browser uses its default font (or the font chosen by its user).

    _This_ is a frequently occurring problem, even though people often cannot
    formulate it exactly. Besides, programs address it in different ways -
    picking up a character from some other font, or treating it as
    undisplayable, and in the latter case, the FAQ entry becomes relevant (to
    implementors at least).

    Intuitively, I would say that a browser does not "fully support" a character
    if it does not render it as a normal character without special actions by
    the user. In this sense, a browser "fully supports" only those characters
    that have glyphs in the browser's default font.

    But I guess this is _not_ what the FAQ question means. Rather, I think it
    means to ask what should be done by a rendering system if it is incapable of
    rendering a gpaphic character at all as a normal glyph or part of a glyph.
    (Dealing with non-graphic characters is a different issue and should be
    addressed under a separate heading.) I think the font issue should at least
    be mentioned in the answer, even if it is considered as being at a different
    level.

    People often need to face the question whether a typographically inferior
    glyph (or a glyph from just about any font, so that we don't really know
    whether it's acceptable or awful) is better than treating a character as
    undisplayable. They might expect to find some guidelines on it in a FAQ like
    this, so if this is considered as off-topic for the FAQ, this should at
    least be clearly mentioned.

    Then there's the question what to do if you can't display a character, or
    you decide you "can't" (i.e., you won't, because the result would be too
    poor). This is relevant to both font designers and program designers and to
    some extent even end users, since they might need to know what to expect and
    what they might even demand from vendors.

    > Display issues such as these are beyond the scope of
    > a character encoding standard. Suggestions are fine, defining
    > expected behavior is not.

    I don't quite agree. Expected behavior should be characterized at a general
    level, but there needs to be room for variation in quality. A simple
    implementation could use the same substitute glyph for all undisplayable
    graphic characters and leave it at that, while a more advanced
    implementation might use different generic glyphs, might give the user
    access to information about the character, etc.

    > The appearance of the "missing glyph" in a font is completely under
    > the control of the font developer. Many developers use a hollow
    > rectangle, but some developers use their own logos.

    Some designs are better than others, especially since some of them (like
    "?") can easily be mistaken as real characters and some of them (like a thin
    vertical bar) might escape the reader's attention and might be interpreted
    just as some kind of dirt, if noticed at all.

    But this cannot be solved at the character code level. The "missing glyphs"
    should be clearly indicated as distinct from glyphs representing characters,
    but by its very nature, this requires something external to the character
    level (and fonts), such as the use of colors, which is not always possible.

    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/



    This archive was generated by hypermail 2.1.5 : Thu Oct 11 2007 - 01:43:52 CDT