Misplaced code

[Lars Hellström]

I've been thinking about last week's debate on the boundarychar, and I have
come to the conclusion that this mechanism should probably be reimplemented.

As it is today, fontinst does not give access to the full generality of the
PL format in this respect. The PL format does not require that the
beginning-of-word ligkern program is identical to the ditto program of any
actual character in the font, so it does definitely not require it to be
identical to the ligkern program of the character which has been made the
boundarychar, but that is what fontinst currently requires.

I would therefore like to suggest the inclusion of the following three
commands in fontinst:

\setleftboundary{GLYPH}
\endsetleftboundary
\makerightboundary{GLYPH}

The first two would make a pair like \setslot{GLYPH} ... \endsetslot, be
encoding commands, and between them would be a sequence of slot commands.
Any beginning of word ligatures would be made using ordinary \ligature
commands in the sequence of slot commands. Beginning of word kerns would be
the kerns on the right of GLYPH. The last command would be a slot command
and mark that the slot in which it appears is the boundarychar, i.e., the
slot that matches the end of a word when TeX is processing a ligkern
program. The purpose of including a GLYPH name here is that this makes it
possible to write code in which it is clear whether a specific kern or
ligature is for the actual end of a word, or whether it simply is for the
character which happens to serve as the boundarychar.

With the above, one could include any kerns between space (on the left) and
another glyph (on the right) as beginning of word kerns simply through
including the commands

\setleftboundary{space}
  \comment{The beginning of a word (not an explicit character) kerns like
    the space character.}
\endsetleftboundary

in t1.etx. No questionable kerns with the visiblespace would be necessary.

Any comments?  (Shorter names, perhaps? I'm no good at that.)

I suppose I can undertake writing the code to implement it, unless Ulrik
has any objections.

Lars Hellström