| Jukka K. Korpela 2006-04-28, 7:01 am |
| Harlan Messinger wrote:
>
> Is it undefined in any way that's different from the way that handling
> of, say, the letter "A" is undefined?
It is; there is no corresponding statement about "A". It is a fair
assumption that in the absence of any other specification, a browser is
supposed to render any printable character in some normal way.
> What choice is there?
Quite a many, actually. Theoretically, "undefined" means that a browser
could do just about anything, like start playing Towers of Hanoi when it
encounters a character with an "undefined" effect, or render it as a
smiling face, to take an unimaginative example.
To mention some conceivable and logical alternatives:
1) Treat FIGURE SPACE as just another graphic character, applying the
same algorithms as for other characters when it is not present in the
currently preferred font.
2) Treat it as completely equivalent to SPACE.
3) Treat it as completely equivalent to NO-BREAK SPACE.
4) As 2) or 3) but adjust its width to match the width of digits.
5) Treat it as a disallowed character, issuing an error message or using
an error indicator in place of the character. (This may well be feasible
in specialized applications where the character is not supposed to be used.
In general, the spirit of Unicode - if I dare to use such a phrase - is
against using fixed-width space characters. They are compatibility
characters that have mainly been included due to existing or assumed use
in old-fashioned computerized typography. When supported, their widths
often do not match the Unicode widths, which themselves are partly very
vaguely described.
The problem in WWW authoring is that there are no feasible alternatives.
Technically we can use e.g. <span style="width:1en"> </span> to
create a simulation of a non-breaking EN SPACE, but I don't expect such
approaches to be very successful, and they surely aren't convenient to
use. Besides, for FIGURE SPACE, there is no way to express its width in CSS.
> I supposed the HTML engine could be made
> responsible for determining the distance that a "9" in the current font
> would span horizontally, including normal character spacing, and then
> offsetting that far to the right, but that seems unreasonable. The
> figure space ought to be in the font.
But what if it is not? Since the meaning of FIGURE SPACE is rather
well-defined in Unicode, it would be quite justifiable for a browser to
achieve its effect even when the current font has no such character.
This would in fact be superior, since using a figure space glyph from
_another_ font - which is what is generally supposed to happen in such
situations - would almost always create _wrong_ spacing.
|