From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.fonts
Subject: Re: Unicode and Fonts
Date: 26 Aug 92 17:28:12 GMT
Organization: MIT Artificial Intelligence Laboratory

Berthold, I couldn't agree with you more about the state of operating
systems.  However, I arrive at a different conclusion than you do:

1. Operating systems (and graphical user interfaces) must provide TWO
   separate interfaces for displaying textual information:

   - LayoutText ( character data, rich text attributes, ... )
   - DrawGlyphs ( glyph identifiers, glyph positions, glyph transforms, ... )

   The first of these will take Unicode (10646) characters in plain text
   format along with other rich text attributes appropriate for performing
   the rendering and layout; it will produce glyphs, glyph positions, etc.,
   that serve as input to the second (DrawGlyphs) layer.

2. Current OSs and UIMSs are missing the LayoutText layer and treat DrawGlyphs
   as if it were drawing characters; whereas, in reality they all are drawing
   glyphs: e.g., C printf, X11 XDrawString, MS Windows TextOut, Postscript
   show operator, QuickDraw DrawString, etc.  If it weren't for backward
   compatibility, these should be changed to XDrawGlyphString, GlyphsOut,
   showglyphs, DrawGlyphString, etc.  [By the way, in SPDL, the Postscript
   "show" operator is replaced by ShowGlyph and ShowString operators, where
   the string is understood as a string of glyphs.  See below for reference
   to SPDL.]

3. Current systems treatment of DrawGlyphs primitives are inadequate for
   full typesetting requirements of all writing systems.  Additional
   equipment is needed to perform 2-dimensional kerning, diacritic
   attachment, template glyph composition, and glyph deformation (non-linear
   scaling).  These will need to be added to the lower glyph drawing layer
   in order to perform proper display operations.

4. UIMSs are also going to have to provide a sophisticated multi-line layout
   facility in the form of LayoutText, one that can do line-breaking,
   justification, and other advanced layout functions.  If done correctly,
   this facility will have the appropriate hooks to allow knowledgable
   applications to replace or modify default behavior.

5. As you point out, the DrawGlyphs layer will indeed need a standard way
   to refer to fonts and glyphs.  This "glyph reference model" should not
   be piggybacked onto Unicode: that isn't its intent.

   I have been personally lobbying for precisely this model for some time.
   At the moment, there is only one "standard" glyph reference model; viz.,
   the "structured glyph names" established by ISO9541 "Information Processing
   - Font Information Interchange, Part 1: Architecture," and registered by
   the ISO10036 Glyph Registration Authority, the latter function being
   performed by AFII (Association for Font Information Interchange).  This
   model has already been incorporated into a number of other standards, e.g.,
   DIS 10179 "Information Processing - Text and Office Systems - Document Style
   Semantics and Specification Language (DSSL)" and DIS 10180 "Information
   Technology - Text Communication - Standard Page Description Language
   (SPDL)."  In addition, I believe that Adobe has adopted this or a similar
   model for naming glyphs.

6. There are problems with actually using the ISO10036 glyph identifiers.
   One problem is that these identifiers tell you nothing about the properties
   of the glyph, e.g., which LATIN CAPITAL LETTER A glyph you have:  is it
   a swash variant, a small caps variant, a run of the mill sans serif, or
   what?

   I have been arguing that the glyph reference model should also incorporate
   the appropriate properties that allow glyphs to be selected during
   composition and layout processing by either the UIMS's LayoutText facility
   or the application.  Of course this can be separated from the actual
   names or identifiers used to refer to glyphs; the glyph identifiers can
   simply serve as a handle which is used to index a property table.

   Another approach that has been proposed is to actually use a character set
   encoding to refer to a collection of glyph equivalence classes, then use
   a feature vector to refer to specific glyphs in the equivalence class.
   While this would support selection of variant glyphs, all of which map a
   single character, this does not support ligature referencing in a
   transparent fashion.  The proponents of this approach advocate using a
   separate ligature mapping table which can be used to indirectly reference
   ligature glyphs by mapping N input glyphs to a single output ligature glyph.
   [Note that the input to ligation consists of glyphs, not characters.]

   While this latter approach is fairly efficient, it is not as flexible as
   a system which employs a transparent and distinct glyph reference model
   in which each glyph is equally visible.  For applications to implement
   their own layout component, I think this is essential.  However, to the
   extent that a ligature mapping table can be externalized, i.e., used
   directly by the application (or layout subsystem), then the application will
   still have access to ligature references as the output from the ligature
   table.

7. So, what will existing operating systems do?  I know that Microsoft
   Windows NT still has TextOut which can take Windows 3.X ansi "glyph
   identifiers" or unicode "glyph identifiers".  In the latter case, you
   can think of TextOut as implementing a DrawGlyphs function in which
   Unicode code element values are used to refer to glyph equivalence
   classes, all of which contain a single glyph.  Obviously one cannot
   do Arabic, Indic, or ligatures with this interface; that is, unless
   one uses the glyphic encodings in Unicode for Arabic contextual
   variants, or adds other contextual variants and ligatures to the
   private encoding zone (6144 code elements).  This is really *not* the
   proper use of Unicode; however, it just happens to work for most
   European and East Asian text, i.e., those writing systems which largely
   have 1-1 mappings between characters and glyphs.  This is not a
   general model however, and must be discarded for implementing universal
   text facilities.

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.

Glenn Adams


   




Newsgroups: comp.fonts