Misplaced code

[Hilmar Schlegel]

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.

Optimal would be a structural implementation which avoids a possible bad
choice. The idea behind is to avoid unexpected results due the selection
of "better" suited boundary characters by someone not aware of the
possible consequences.

> >> 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.

I use them in ligature programs for intermediate steps (because these do
no occur in normal input). Let's simply state that the rightboundary
must not occur in the ligkerns (checked by the user or the program).
 
> >> 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

I mean how Tex understands the TFM.

> (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.

This is one restriction you suggest to lift with your additional code.

> >I can imagine that one has a "character" boundarycharacter to allow

in the sense of setglyph...

> >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

in the sense of character name, whatever slot it occupies

> >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

dito

> >character later without problems, depending on the needs or fancy.

dito 

> >Besides this the possibility to have at least a leftboundary without to
> >occupy a character code for it would be certainly also an advantage.

character code = slot

> 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.

Well, yes - that's life ;-)

> 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

Somehow yes - if I understand the difference between glyphs and names
correctly.

> 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.

Perhaps limited but at least the intention was to have an easy way to
change the rightboundary for a given encoding without changing too much
in fontinst & encoding files. If you implement a way to program various
boundary behaviours into a single encoding and select a) any given
character name (aka glyph) b) a specific boundary behaviour and even c)
separate left/right boundary ligkerns inhereted from any given
"raw-character" (character name in an AFM or slot in a PL) this would be
just like heaven ;-)

My point was simply that mtx files should be kind of
encoding-independent while the choice of the rightboundary's character
name depends on the to be used encoding (etx) (besides taste). Since the
occurrences of rightboundarychar(s) [or boundaryglyph?] in the ligkerns
must be replaced by the actually choosen character name, I suggested a
command for doing so. [to allow it to become the boundaryslot]
I have no preferrences with respect to the implementation - if the
functionality is there.
I guess I did not understand which notation you use to write down the
ligkerns with different boundary behaviours and different
rightboundarychars. I don't see if these etx files remain kind of
backward compatible to the current fontinst.


Hilmar Schlegel