🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.fonts
Article #634

Re: font encoding morass

#634
From: Michael Wang
Date: Thu, 20 Aug 1992 01:34
44 lines
2795 bytes
In article <71384@apple.Apple.COM> opstad@Apple.COM (David Opstad) writes:
>In article <26760@life.ai.mit.edu> bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn) writes:
>>
>>Finally:  Let's hope that UNICODE with its 16-bit characters will help
>>resolve some of these problems.  Although, UNICODE is dead in the
>>water if it does not provide access to ligatures.  For there can be
>>no fine typesetting without ligatures.
>
>As I've said before, Unicode and ligatures are completely orthogonal issues.
>I have on my machine right now a Unicode font containing almost 1,000 glyphs,
>including scores of ligatures. The ligatures, like the rest of the
>typographic richness of this font, are accessed via a well-defined method
>that has *nothing* to do with the character encoding (i.e. Unicode).

In the case of document portability, I don't feel that Unicode and
ligatures are unrelated issues. On the Macintosh, there may be (will
be) something in the OS that allows automatic substitution of ligatures
for letter combinations, but what about other platforms? If I create
a document with a Mac application that uses the Line Layout manager to
handle ligature substitution and transfer it to another platform that
doesn't have QuickDraw GX, I'm not going to get the ligatures.

Or take another example. Let's say I have a font on the Mac that includes
small caps in addition to all the other regular characters. I can use
the Line Layout manager to display the small cap characters, even 
though they are not part of the encoding. Again, if I transfer this 
document to another platform, I'm going to lose my small caps since
what is stored in the document are the encoding values for the l.c.
or u.c. letters that were turned into small cap characters, not the
encoding values for the small cap characters themselves.

Unfortunately, expanding Unicode to include ligatures and small caps
is not going to solve the general problem. What do you do if you have
a font with many alternate character forms? Poetica, for example, has
many different versions of the capital letters (not to mention 58
different ampersands). How do you setup Unicode so that it can uniquely
encode each of these different versions? Do you turn Unicode into a
24-bit encoding where each of the regular 16-bit characters can have
256 variations?


-- 
Michael Wang
mmwang@adobe.com
Technical Details
Message-ID: <1992Aug20.013444.6313@adobe.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!ames!decwrl!adobe!mmwang
References: <26760@life.ai.mit.edu> <71384@apple.Apple.COM>

Show Full Headers
Complete Article Headers
Newsgroups: comp.fonts
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!ames!decwrl!adobe!mmwang
From: mmwang@adobe.com (Michael Wang)
Subject: Re: font encoding morass
Message-ID: <1992Aug20.013444.6313@adobe.com>
Sender: usenet@adobe.com (USENET NEWS)
Organization: Adobe Systems Incorporated
References: <26760@life.ai.mit.edu> <71384@apple.Apple.COM>
Date: Thu, 20 Aug 1992 01:34:44 GMT
Lines: 44