From: lee@sq.sq.com (Liam R. E. Quin)
Subject: Re: Unicode and Fonts
Organization: SoftQuad Inc., Toronto, Canada
X-Feet: bare
Date: Thu, 27 Aug 92 01:58:05 GMT

glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) wrote a clear, well-reasoned
article that started off with:
> Berthold, I couldn't agree with you more about the state of operating
> systems.  However, I arrive at a different conclusion than you do:

I don't think I entirely agree with either Glenn or Berthold, but I come
much nearer to agreeing with Berthold.

Here's what's wanted:  the ability to interchange data.  Between applications.
Between platforms.  Above all, between People.

It looks to me as if Unicode is being thought of as a panacea solution that
it isn't trying to be.


Here is a very simple model of how things work in most systems now:

+------------+							  +---------+
|   input    | (numbers)  input	         	     Font +	  | printed |	
| characters |----------> encoding ----> names ----> Encoding---->| glyphs  |
+------------+ (65)			  (A)		(197)	  +---------+

(in practice, instead of names, most systems use numbers, in a way that one
might think of as `numerical names', for efficiency)

So if we start with an `A', represented as the decimal number 65, a program
that displays a file to the screen looks up 65 and sees that that
corresponds to an A in the current input encoding (these are not the terms
used in the various standards).

This information would perhaps be derived from a Unicode table.

In order to display the character called `A', we'll need to choose a font,
Mootype Bembo, say.  It will have an encoding -- in other words, a table
that will say, for each character name, which position in the font contains
a glyph that, when displayed or printed, represents the named character.
There is no ISO standard for font encodings as far as I am aware, although
perhaps this falls under the Font Interchange stuff.

A word processor or text formatter will notice the name f followed by the
name i, and when such a sequence occurs, will look for `fi-ligature' in the
Font Encoding table.

In this model, it is clear that ligatures must be present in the Font
Encoding, but wait!  Don't flame yet!  This does _not_ mean that ligatures
should not also be present in the input encoding.

The question is not `should every fi in every file be stored as an
fi-ligature?', but `should it be possible to store a file containing such
a ligature?'.  The answers to these questions are surely `no` and `yes',
respectively.

Now, troff (and Scribe and ...) users know that all they really need is the
ability to store the _representation_ of a ligature - that is, \(fi, @char[fi],
or whatever.

But in a WYSIWYG package, in Microsoft Windows or Sun's `Jed' or even in a
usenet article, there is no text formatter interpreting input characters as
a special little language.  Some people are even pleased at this. :-)

As a result, there is no equivalent of typing @char[fi] in many packages, and
so the user does not have the ability to include a ligature.
Fortunately, this isn't a problem for \(AE, \(OE and other combinations which
are separate letters in their own right in some languages and are therefore
included in Unicode.  And quite frankly, most receptionists typing away at
letters and 'phone messages don't really care.

The few people who _do_ care, care strongly.

It wouldn't take much to include ligatures, and I for one should like very
much to be able to preserve ct, st, tall-s and fi in certain hostorical
documents that I type; I use troff or TeX or SGML entities to do it at the
moment, but none of these are satisfactory for sharing the texts with others.

Glenn Adams concluded his article with the following statement:

>8. Instead of trying to beat Unicode into something that it isn't, it would
>   be much better if font designers and layout system designers could
>   contribute to developing a useful font and glyph reference model in
>   the framework I've discussed above.  This would be of great benefit to
>   implementors who are working on providing this framework.

but I cannot help but wonder if it wouldn't be better if Unicode were not
something it isn't.

-- 
Liam Quin, lee@sq.com, SoftQuad, Toronto, 416 239-4801; the barefoot programmer
  lq-text (Unix text retrieval package) mailing list: lq-text-request@sq.com
  latest released version: 1.10; ftp: ftp.cs.toronto.edu in directory: pub
  If Adultery is for Adults, is Juvenal for Juveniles?