[Fontinst] \resetslot in multislot.sty would be nice to have working

[Lars Hellström]

Reuben Thomas skrev 2013-08-06 00.59:
> On 5 August 2013 22:35, Lars Hellström<Lars.Hellstrom at residenset.net>wrote:
>
>> Reuben Thomas skrev 2013-08-03 22.02:
>>
>>> I beg to differ: I'm trying to write customized versions of t1.etx,
>>>
>>
>> Oh, cool! May I ask to what ends they are customised?
>
>
> To add long s ligatures (in my case, for use with Adobe Caslon Expert
> fonts).

Yep, that's the kind of application where one definitely needs to do some 
customising of the encoding. Though not so much (I would maintain) of the 
ETX file, provided one uses multislot.sty.

>> Is there a reason you don't just do those tasks in the opposite order,
>> i.e., go
>>
>> \encoding
>>
>> % First do my stuff:
>>
>> \nextslot{n}
>> \setslot{whatever}...\**endsetslot
>>
>> % Then fill in the rest as in T1 encoding:
>> \inputetx{t1}
>>
>> \endencoding
>>
>
> Yes, because either I use multislot, and then end up overriding rather than
> adding to slots, or I don't use multislot, in which case the \inputetx{t1}
> will add to the slots I want to override. I can't both override and add to
> slots either with or without multislot.sty.

The catch is that you don't really add things in the non-multislot case 
either. See below

>> ? Then it is always the first \setslot that does what you want,
>
>
> I want to add to the existing definition.
>
>> You may be lucky with how vptovf deals with multiple definitions here.
>> (Which in principle one shouldn't rely on, but OTOH as software goes,
>> vptovf is probably one of the more fixed fulcrums one might come across.)
>
>
> Exactly, I'd rather not rely on this.
>
>
>> Could you clarify what you mean by "add to a slot" here? I don't see what
>> it could possibly correspond to in a virtual font.
>
>
> I want to add a ligature rule to an existing glyph, i.e.
>
> \inputetx{t1}
>
> \setslot{some glyph defined in t1.etx}
>    \ligature{...}
> \endsetslot

After having RTFS'ed vptovf, I can tell you that the above (without 
multislot) rather has the effect of replacing than the effect of adding to. 
If t1.etx for example goes

\nextslot{102}
\setslot{f}
   \ligature{LIG}{f}{ff}
   \ligature{LIG}{i}{fi}
   \ligature{LIG}{l}{fl}
\endsetslot

and you later say

\nextslot{102}
\setslot{f}
   \ligature{LIG}{longs}{f_longs}
\endsetslot

then without multislot.sty, the only ligature that takes effect is the 
f*longs->f_longs one. The ligkern program of the second \setslot has not 
been added to that given in the first \setslot, but it has rather replaced it.

More technically, what happens is that each \setslot...\endsetslot block 
causes fontinst to write a

    (LABEL D n) (COMMENT glyphname)
    ...
    (STOP)

section to the LIGTABLE of the VPL file. Without multislot.sty, fontinst 
doesn't even notice whether the same LABEL appears twice. Vptovf, on the 
other hand, will notice this and considers it to be an error (reported via 
err_print). The way it recovers from this error is that it lets the new 
LABEL override the previous one, with the effect that the ligtable section 
of the first \setslot is now forgotten. Well not completely lost, as it will 
probably still be taking up space in the ligtable of the generated TFM file, 
but there will no longer be anything that points to it, so TeX will never 
have a reason to execute the ligkern instructions of the first \setslot; 
they are merely junk in the table.

So in summary: If without multislot.sty, you could get all the ligatures you 
wanted for a slot by putting one extra \setslot for it after \inputetx{t1}, 
then with multislot.sty, you can get the exact same set of ligatures by 
putting the same \setslot before \inputetx{t1}, while avoiding the 
embarrasment of having vptovf complain about errors. Conversely, if you with 
multislot.sty don't get all ligatures by putting some \setslot before 
\inputetx{t1}, then you wouldn't have gotten all those ligatures without 
multislot.sty (and reverse order of \setslots) either! It's an easy thing to 
miss, however, that some ligaturing instructions one expected aren't 
actually present in the result.

>> t1.etx is not particularly in flux, so shipping the patched versions is
>> probably far more user-friendly than shipping a bunch of patches.
>
> I don't think so, as you can't read a patched version to see how it's
> different. A patch is both easy to read, and easy to apply.

In my experience, more people have a working diff utility than have a 
working patch utility, so recreating the patches (if one prefers that view) 
is actually less an obstacle than applying them. In addition, there are a 
number of different patch formats being used, and not everybody prefer the 
same format.

Not that it matters much, considering that I have above established that 
multislot.sty actually will suffice for what you want to do.

Lars Hellström