[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inverted (=reflected) N
- To: Chris Rowley <C.A.Rowley@open.ac.uk>
- Subject: Re: Inverted (=reflected) N
- From: Robin Fairbairns <Robin.Fairbairns@cl.cam.ac.uk>
- Date: Thu, 05 Feb 1998 21:36:39 +0000
- Cc: "Y&Y, Inc." <support@YandY.com>, email@example.com
> Y&Y, Inc. wrote --
> > There are many examples of such things:
> What things?
> > mu micro
> > These correspond to the many-to-many relationship between characters and
> > glyphs.
> No they do not; they are just synonyms for glyphs.
as far as i'm concerned, the glyphs have nothing to do with the
matter. the names represent some semantic notion; in an ideal world
each such semantic notion would be represented in the character set by
a different code, but this doesn't happen any more.
the parts of unicode that inherit from iso/iec 8859-x maintain the
semantic distinction, so that we get the latin glyph H having one
code, the greek glyph H (`long latin i', aiui) having another, and the
cyrillic glyph H (latin n) having a third. in other areas of the
table, not so inherited, unicode scrunches semantics together.
this is unlikely to change, imho, ever.
> > We often think only of how one character can be repesented in several
> > different
> > ways (think of the two forms of a and the two forms of g for example).
> I am just waiting until Unicode decides these should get different names!
and unicode won't allocate separate names to the same code, whatever
the semantic implication of the name. i don't remember, but i'll bet
there's a rule somewhere that says that character code standards
aren't allowed to do that.
> > But there
> > are also plenty of examples where one glyph stands for more than one
> > character.
> I am not sure that glyphs "stand for" characters at all.
quite so. a glyph is mapped, by the software that chooses to use the
font that contains it, to a character code. that software responds to
that character code by selecting the glyph. that grubby mark that
appears on the screen or the paper, stands for itself: the software
behind it has, however, made a decision about its use.
it so happens that we often have conventional representations of
characters, which any sane software would employ (amusingly, of
course, knuth -- predating our present freedom to think moderately
clearly in these matters -- chose to veer away from what at the time
was a distinctly limited set of conventions when he designed OT1).
> > Indeed the above come directly from comparable
> > TrueType and Type 1 fonts. You can find more if you compare the TrueType
> > and Type 1 version of Lucida Sans Unicode.
> It would seem to me to make more sense if the names of the glyphs were
> decided by the font designer then this particular problem would not arise.
it would surely lead to insanity if the names of glyphs were to be
different in every font designed to be used with a given character
set. conventional representations and all that...
no, let's stick to the situation we have, where there are conventions
(flouted of course by the big boys like microsoft) and we therefore
have a finite task when we're building our software.
but let's remember that, because of the shortage of slots in
unicode[*], and that therefore one is forced in the real world to
overload the semantics of characters by using aliases.
and of course, i have nothing to say about the naming of the glyphs
required by maths. i can see the value in making them consistent, but
i can't get particularly excited about minor inconsistencies.
[*] and the sorry fact of life that has SC2 taking a long time to
produce standards -- 10646-1 _does_ `give them the freedom' to go away
and do the right thing, in its intro about the architecture of 10646.