From: Jukka K. Korpela (email@example.com)
Date: Thu Oct 11 2007 - 01:41:20 CDT
James Kass wrote:
>> 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
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")
This archive was generated by hypermail 2.1.5 : Thu Oct 11 2007 - 01:43:52 CDT