> > Again, I don't care so much whether these particular characters are
> > encoded, but they illustrate a point worth making, namely that
> > unifications that work in the GUI world don't necessarily work in an
> > environment where we must use a fixed-pitch font.
> I think you're missing the point a little. Over the past day, I believe
> we've established that these are the same things, so they shouldn't be
> encoded again; and we've established that you don't need two sizes of
> ordinal indicators. Right?
I appreciate that these characters are, in one sense, the same as the ones
already in the Latin-1 section of Unicode. But to a user of an SNI
terminal, they are not the same because they don't look the same, just as
a superscript digit "2" looks different from a base-character digit "2".
At the risk of stating the obvious (and I realize it is obvious to you and
to many other readers, but perhaps not to everybody), a terminal does not,
in general, have the ability to display glyphs at any desired point size,
or to turn a base character into a superscript, or vice versa, whereas a
GUI application can do this. So while the unification argument makes
perfect sense in the GUI world, it does not hold applications where we are
restricted to a fixed-pitch font. (Those who have never seen a terminal
before, think of a DOS window.) (I was going to say "or a typewriter",
but if you haven't seen a terminal, you probably also haven't seen a
typewriter -- and a typewriter is actually quite a bit more versatile than
a DOS window, since it can overstrike, and with some coaxing, also handle
sub- and superscripts).
In the end, an SNI screen can show a feminine ordinal from its Latin-1
character set and a "small letter a with underbar" from its Mathematisch
character set side-by-side and their visual appearance will be strikingly
different. And perhaps there is some application where this difference is
significant. (As it would be with "22" -- is the second digit a base
character or a superscript?)
Again, I'm not a fanatic about these particular characters, and as far as
I can tell so far, nobody will notice or care if they are not encoded, but
I want to be sure we have the selection process right, and this seems to
be an excellent test case.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT