From: caro@adobe.com (Perry A. Caro)
Subject: Re: Unicode and Fonts
Reply-To: caro@adobe.UUCP  (Perry A. Caro)
Organization: Adobe Systems Incorporated, Mountain View
Date: Fri, 4 Sep 1992 20:35:21 GMT

At the risk of beating a dead horse, I think it's worth summarizing some
of the key points made in this discussion.

But before doing that, here's my opinion: We are suffering the first
pangs of transition pain.  We are moving from a world where ASCII codes
represented both FORM *and* CONTENT.  People are used to this.  People
expect this.  People are unhappy when self-proclaimed
we-know-better-than-you experts tell them that that world is too limited
for the future of information commerce.

It is therefore incumbent on the experts to both motivate the need for
change, to educate, and to make the transition as painless as possible.

Perhaps the one thing the various experts could have done was find out
what people really wanted.  And I suspect that one of the top things is
the close association of FORM *and* CONTENT in the data stream (after
the usual "support my language", and "support my typography").

I see this transition phase as an opportunity for a White Knight vendor
to make things a whole lot easier.  It could have been Apple.  They are
damn close.  They provide the system level mechanism for FORM, but not
the data interchange level.  I would like to see Apple take one more
step and adopt ISO 9541 (the glyph/shape standard) as the FORM part of
their solution.  I would like to see Apple define a data stream format
that made it easy to specify both FORM *and* CONTENT with mappings
between ISO 9541 glyph indices and ISO 10646 (UNICODE) codepoints.  The
FORM properties could be advisory, such as, "in the following sequence
of UNICODE characters, consider using an 'fi' ligature in the first
position, with the following font and character metrics".  Yes, data
streams will get bigger -- that's the price of global information
commerce.

Those who care only about searching for the word "fin" will find it,
those who care about the "fi" ligature can have it too.

Now, the summary:

In article <27197@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu (Glenn A.
Adams)
writes:
>   from other character sets.  The only conclusion that can be reached is
>   that characters should be associated with (at least) a 2-dimensional
>   basis that specifies FORM and FUNCTION.  However, even when form is
>   predominant in a character, it is the lexical (symbolic) function which
>   that character possesses that makes it a character (and not a glyph).

In article <28250002@otter.hpl.hp.com> hjb@otter.hpl.hp.com (Harry Barman)
write
s:
>+ Personally, since UNICODE doesn't describe anything about the appearance of
>a document, it isn't really a complete interchange standard in its own right.
>So if UNICODE is simply part of an interchange standard, then I would be
>inclined to keep markup out of UNICODE.  This has the benefit that
>applications that want to parse text without appearance information, can
>simply be given raw UNICODE.

In article <71761@apple.Apple.COM> opstad@Apple.COM (David Opstad) writes:
>In the fonts we're working with for Line Layout in QuickDraw GX, we have
>some cases where one font has 7 or 8 ligatures for, say, 'st'.
[...]
>For these reasons, and as I've argued before, I believe the inclusion of
>ligatures in the text stream is a bad idea. Each font has its own unique
>repertoire of glyphs, and should be given the chance to use it. This is
>*NOT* to say, of course, that the user should not be allowed to specify
>when ligatures, or swashes, or any other rich typographic features are
>used.

In article <2A9C6D8A.813@intercon.com> amanda@intercon.com (Amanda Walker)
write
s:
[Assuming appearance functionality will be provided by all]
>While this is not an unreasonable assumption in an ideal world, I fear that
>it is far too optimistic.  My own expectation is that the majority of vendors
>will supply a couple of UNICODE-encoded fonts and a minimal input method, and
>declare their systems "UNICODE-compliant."  Now, there will no doubt be a few
>(such as Apple, based on their track record so far) which will actually
>invest the effort in doing things right, but I am not optimistic about the
>majority.
~

Perry

P.S.
Speaking of bigger, why oh why is UNICODE 16-bit based?  Can you say
major byteswapping headaches?  I still think Xerox's interpreted sequence
of bytes, with infinitely expandable space, is the better solution.
-- 
caro@adobe.com	...!{sun,decwrl}!adobe!caro   Contents: my opinions, no others