[karl@cs.umb.edu: the cork font encoding scheme for tex]

[mackay@cs.washington.edu (Pierre MacKay)]

 > What is character 0211, the L with an apostrophe after it?  I'm
 > curious as to if a language uses such a construction, or if it's just an
 > unfinished rendering of something else.

 > Should 0264, the t-followed-by-apostophe, be t-with-a-caron-accent?
 > That is what its uppercase counterpart, 0224, is.  Or are these
 > apostrophes some variant of carons I don't know about?

Both of these are indications of palatalization in slavic languages
especially.  

The apostrophe character indicates a consonantal y offglide from
the consonant, which also forces the following vowel forward in the
mouth.  

L'et == lyet,
bilo == b(w)ilo  (with a back of the mouth pronunciation of l.

 > I am wondering what the state of that encoding scheme ``standard'' is --
 > are further changes being contemplated, or is it frozen?  For example,
 > Rahtz's article mentioned above suggested that the visible space
 > character is inappropriate for a text font, a suggestion I agree with.
 > An invisible space character would perhaps be more useful.  I don't
 > understand why a visible space character is needed in a font at all --
 > can't it be created entirely from rules?  Also, why are the accented A's
 > (for example) in two different places?  I'm sure there is a good reason,
 > but I'm ignorant of it.

Somebody (bb?) later in this mail list argues in favor of the
visible space character in some faces, and if we are going to
make this mapping cover a wide variety of text categories, then
the cell needs to be reserved for that character.  It might be
argued that the character in that cell can be in fact invisible in
the case of a font that is not monospace.

 > I am fully in favor of Pierre's suggestion that the accented characters
 > all have the height of the unaccented base; in fact, I don't see any
 > serious alternative, given the limitation in TFM heights.  (This
 > limitation might be a good thing to remove in the first ``non-TeX'' TeX,
 > if it can be done in an upward compatible way.)

Barbara argues that it is not really necessary to consider it a 
limitation.  If the accented characters have the height and depth
of the entire glyph, rather than just the height and depth of the
unaccented base, they cause unexpected and often undesirable things
to happen at the point of \topskip and at interlineskip in tightly
leaded formats.  

 > This brings up another question -- don't we need to create and
 > distribute a set of macros and recommend standard ligature sequences for
 > the coding scheme?  If the TeX input isn't agreed on, some of the
 > advantage of a standard encoding scheme will be lost.  The biggest
 > question in my mind is how to take advantage of all the accented
 > characters.  I can imagine several alternatives:

 > 1) change \', \`, and the like to produce a \char command if its
 >    argument is one of the grave-accented characters in the encoding, and
 >    an \accent command otherwise.  This would require the least change to
 >    existing input files (not an overriding consideration, in my view).

 > 2) define ligatures in the font so that A + grave => Agrave (that is,
 >    0101 + 00 => 0192).  Then define a new control sequence \gravechar
 >    (e.g.), or perhaps redefine \grave to do \char outside of math mode,
 >    so that the user can type `\grave A' anywhere.  Then \grave should do
 >    \accent, if its argument isn't one of the grave-accented characters
 >    in the encoding.

I am strongly in favor of this one. (I renumbered it 2)

 > 3) make new control sequences \Agrave, \Ntilde, and the like to produce
 >    them.  This is the easiest thing to do, but the most painful to use.

 > Of course, all of this is unnecessary when keyboards can produce Agrave
 > or whatever directly.  The question is what to do when they can't.

 > One more question: are discussions of a math symbol coding scheme (and
 > others, such as a companion to the basic text font to provide many
 > missing symbols, like bullets and daggers and paragraphs) ongoing, and
 > if so, in what forum?  If it's open, I'd like to join.

send a message to Beebe@math.utah.edu

Email concerned with UnixTeX distribution software should be sent primarily
to:	elisabet@max.u.washington.edu           Elizabeth Tachikawa
otherwise to:  mackay@cs.washington.edu		Pierre A. MacKay
Smail:  Northwest Computing Support Center	TUG Site Coordinator for
	Thomson Hall, Mail Stop DR-10		Unix-flavored TeX
	University of Washington
	Seattle, WA 98195
	(206) 543-6259