Re: Next fontinst version and code I once sent

[Lars Hellström <Lars.Hellstrom@math.umu.se>]

Hello again, Ulrik.
  [snip]
>>  * I reimplemented the way fontinst remembers assignments of glyphs
>> to slots. As it is now, fontinst knows at most one slot number per
>> glyph. This causes a problem if you are making an all-caps fonts the
>> trivial way, i.e., having \lc equal to the normal \uc and so on,
>> because at most one of the slots in which a glyph is used will have
>> a KRN instruction written for it.  (NB: This affects the right glyph
>> in a kerning pair, not the left.) Thus AV and Av in such an all-caps
>> font will kern differently. The reimplementation fixes this problem.
>
>I'm confused.  Is this a bug fix or a new feature?
>
I think it is mainly a bug fix. The current implementation has a rather
non-expected behaviour when it comes to situations such as the above,
although I do not think I can find a specific claim in any fontinst manual
which does not hold due to this.

>> Apart from these fixes, I have as mensioned implemented a new syntax
>> for boundarychar support. This new implementation currently has the
>> drawback of not being backward compatible, but it actually occured
>> to me while I was writing this that it can easily be made backward
>> compatible. I intend to do so this weekend.
>
>Not being backwards compatible might be a problem, indeed.
>
After what I have written during the weekend, I think I can say that it now
is compatible, apart from such minor details as adding three new commands
(thus making them unavailable for use in \setcommand). In the code I have
now there is a docstrip switch called boundaryCompatible around the
critical code: When true, both old syntax (setting boundarychar to a fixed
number or to \int{GLYPH} for some glyph) and my proposed new will work, but
there is some redundancy (fontinst stores the slot numbers in two different
places). When false, only the proposed new syntax works, but fontinst uses
less memory.

Lars Hellström