Misplaced code

[Lars Hellström]

Hilmar Schlegel wrote:
>Lars Hellström wrote:
>> >
>> >Do the occurrences of rightboundary in ligkerns replace or append the
>> >occurrences of the choosen character (which might be present when it is
>> >not the boundary) in the ligkerns?
>>
>> I was thinking about making it a matter of first come, first served. Any
>
>Perhaps a warning message that a collision happens would be in place.
>
I'm not at all sure it would be worth it, since the detection of such a
collision is rather costly. But I'll think about it.


>> Another class of candidates for right boundary character is the ligatures.
>> As fi, fl, ff, ffi, and ffl are only formed by ligatures (AFAIK), they do
>> never occur as the next character at any ligkern step, hence it would be
>
>This depends, certainly not in the general case.
>
I which case isn't it? Certainly you can typeset them through a \char
command, but doing that inside a word is at least as silly as putting a
questiondown there.

>> safe to use their character code for the right boundary (but definately not
>> for the left boundary).
>
>The leftboundary has no code, only a name.

As fontinst is currently implemented, the left boundary is "given" a code
(the same as the right boundary). Therefore it would not work to let ffl
serve as the right boundary when using the current fontinst, as that would
also make it the left boundary.


>I can imagine that one has a "character" boundarycharacter to allow
>transfer of kerns from some character in a metrics file (or your way to
>specify where kerns are coming from by means of a new command). And
>rather a command \rightboundary which is to be used in ligkerns. By a
>definition of a certain name for \rightboundary this name becomes the
>actual character to be used as boundary. I.e. I think it would be useful
>to have a way to write ligkerns into an etx without to know the actually
>used character in advance. This would allow to change the rightboundary
>character later without problems, depending on the needs or fancy.
>Besides this the possibility to have at least a leftboundary without to
>occupy a character code for it would be certainly also an advantage.

It would be advantageous if you would try to use the expressions `glyph'
and `slot' instead of `character', as the meaning of the latter is often
unclear.

What you seem to suggest is that instead of explicitly giving the name(s)
of the glyph(s) which is/are to work as the boundaries in the etx file,
there should be a predeclared command which denotes the name of a
pseusoglyph for the boundaries when used in a GLYPH NAME position, so that
in effect there is a predeclared name for a boundary glyph (which should
not be equal to anything one can type in any other way). The problem with
using this approach is that it is unnecessarily limited. If the etx file
can give any glyph name(s) as the name(s) of "the boundary glyph(s)" then
one can set up the metrics for several different boundary behaviours by
loading one single sequence of mtx files and then create several fonts with
different boundary behaviours from these metrics simply by using different
etx files. If there can only be one "boundary glyph" then the etx file can
only choose between using the behaviour of that glyph or have no boundary
behaviour at all.

Lars Hellström