Re: What's STILL wrong with "symbol" fonts?
Re: What's STILL wrong with "symbol" fonts?
- Subject: Re: What's STILL wrong with "symbol" fonts?
- From: "Ken Thomases" <email@hidden>
- Date: Fri, 28 Jun 2002 16:51:17 -0500
- Priority: normal
[lots of discussion snipped]
I hope I'm not presuming too much, but I see a lot of talking past
each other in this discussion and I hope I can help clear it up.
This is a long post, so if it doesn't interest you, skip it.
I think the old way (pre-Unicode) of doing keystroke -> character
encoded in memory -> glyph drawn on screen has instilled very deeply
a way of thinking that people don't realize they're stuck in. It's
preventing them from understanding what's happening in the brave new
Unicode world.
Because of the limitations of 8-bit representations of characters in
the past, there was lots of overloading of a single numeric value to
mean different things. When you typed 'a', the character code 0x61
was stored somewhere (memory, file, etc.) to represent that character
(assuming an ASCII-based character encoding). If you wanted a greek
alpha, you said effectively "Alright, store it as 'a', but draw it as
alpha" and chose a font which drew an alpha where an 'a' was stored.
Where most fonts "claimed" things like "I know how to draw 'a' -- I
draw it with serifs, etc." or "I know how to draw 'a' -- I draw it as
cursive", other fonts like Symbol "lied" and said "I know how to draw
'a' (but really, I don't draw 'a', I draw alpha *muahahaha*)". OK,
maybe without the sinister laugh. I'm deliberatly using loaded terms
to emphasize that, although this was the way it had to be for 8-bit
characters, it is deeply problematic (and just plain evil, to boot).
So users were trained to think (correctly for the most part) that
fonts are a way of changing the appearance of characters. But they
were also trained that alpha wasn't a separate character from 'a', it
was just 'a' drawn differently. I think this is a large part of what
people are stuck on.
Along comes Unicode which declares, "'a' is a different character
than alpha, 'b' is a different character than beta, etc.". By
expanding the character representation from 8 bits to 16 or even 32,
we have plenty of space to give each different character a different
numeric code. Since 'a' really is, in any rational way of thinking
about it, _not_ alpha, those two characters no longer share the same
numeric code or really have any relationship at all.
This also allowed for the rationalization of fonts. The Symbol font
no longer deceptively claims "I know how to draw 'a' (code 0x0061)",
it just truthfully claims "I know how to draw alpha (code 0x03B1)".
So, when the user tries to apply the Symbol font to text which
includes character code 0x0061, that character isn't found in the
font. There's just no entry for code 0x0061 in the font's code-to-
glyph map. And because 'a' and alpha are no longer unnaturally,
arbitrarily tied to each other, there's no way for the font to
magically summon the alpha glyph for the 'a' character code. The OS
has two choices: display the good old missing character box, or
search for another font which does contain a glyph for that code.
Mac OS X chose the second approach.
So, if the user really wants an alpha, s/he needs to really enter an
alpha character into their document. As others have described, this
is accomplished through various means, primarily a keyboard map which
causes a stroke of the 'A' key to generate the code for alpha instead
of 'a'. This part of the system could stand to be improved as
described elsewhere. However, do note that this does make some
aspects of the user's job easier. If s/he wants an 'a', an alpha,
and a hebrew aleph to appear together, s/he just enters them and the
system finds a way to display them without the user needing to fiddle
with fonts. The user is free to select all of a document full of
text, mathematical equations, etc. and apply a font without risking
losing the "symbol-ness" of their symbols. The symbols are really,
at a low level, what they appear to be; not just at the surface.
Now the choice of font is only useful for determining the _style_ in
which a particular character is rendered (serifs/sans, block/cursive,
bold, italic, etc.) _not_ which character is rendered. Systems
typically have a variety of fonts supporting the Latin characters for
a variety of text styles. Some might have multiple fonts (including
Symbol) for the greek alphabet that provide different styles.
So typing a bunch of text in the Latin character set, selecting it,
and choosing the Symbol font does not, can not, and _should_not_,
cause it to suddenly turn into a bunch of greek letters and
mathematical symbols. Because the Symbol font doesn't provide glyphs
for the selected characters, the system tries its best to display the
characters in some intelligle way to the user and falls back on
another font.
This raises another UI issue: should the font menu/picker even show
the Symbol font when a bunch of non-Symbol-supported characters are
selected? In the context where a document can contain a mix of
characters from all throughout the Unicode space, does it even make
sense to apply a (singular) font to a selected span of text? If you
try, it will work for those characters supported by the applied font,
and the system will fall back on some search algorithm for the rest.
Does the user get to control the search algorithm? In reality, what
the user needs is to assign a search _list_ of fonts for a given span
of text.
For example, suppose a document contains the sentence:
As <alpha> varies from 0 to <infinity>, <beta> converges to 0.
Suppose also that the system has multiple fonts supporting Latin
characters, multiple fonts supporting Greek characters, and multiple
fonts supporting mathematical symbols (with some fonts supporting
some of each). If the system's implicit search algorithm picks
Symbol for all of alpha, infinity, and beta, but I want to use a
better Greek-capable font for alpha and beta and a better math symbol
font for infinity, I have to tediously apply my desired font to each
character individually. I should be able to apply to the whole
sentence/document a font search list like: Lucida, MyNiceGreek,
MyNiceSymbol. Notice that there's a good chance that MyNiceSymbol,
like Symbol, contains Greek characters, too, but my search order
allows me to use MyNiceGreek instead. I could even insert
MyNiceNumerals at the front of the list to get better rendering of
the zero and, assuming that MyNiceNumerals only renders numerals and
no other characters, it won't interfere with the rest of the
sentence. Of course, if I type a character not supported by the
fonts in my explicit list, the system will still fall back on its
implicit search algorithm.
By the way, there's been some discussion of Apple "fixing" things in
Jaguar. I believe that what Apple is going to try to do is arrange
it so that when the Symbol font is selected for about-to-be-typed
text (i.e. when there's no selection), the Symbol keyboard map will
be engaged. That way the user can put the insertion point somewhere,
pick the Symbol font, and type; this will produce actual symbols
(alpha, beta, etc.). How they're going to manage this and the switch
back to the default keyboard map, and whether it's a good idea at
all, remains to be seen.
I hope this (very long) post has been helpful.
Ken
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.