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

[Lars Hellström]

Reuben Thomas skrev 2013-08-03 22.02:
> multislot.sty says (at least in the version currently on CTAN, marked
> "Second version":

FWIW, what constitutes the "first version" is a private extension to 
fontinst v1.504 that I wrote back in 1997. When I took over development in 
1999, I also started to integrate the features of that extension (e.g. 
\resetkern) into the master fontinst, but \resetslot and such never made it 
--- partly because they didn't work all that correctly, and partly because 
the command interface was clumsy --- even though the \..._etx_pass_hook 
macros was introduced specifically for such a mechanism to hook into.

The current (second) version is a rewrite from 2009, during an effort to 
record and collect the development history of fontinst. It has a sane 
command interface, but it still faces some fundamental technical limitations.

> % This is of course a BUG, and there doesn't seem to be any way
> % around it, short of adding another pass of reading ETX files. Doing
> % so would probably not be worth the effort, since the usefulness of
> % a \resetslot command is not clear; unlike \resetglyph, it cannot be
> % used to amend an existing \set..., but only to override it.
>
> 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?

> updating a now-lost package of Ulrik Vieth's in which he simply supplied
> patched versions of that file. That has all the usual maintenance problems
> described in newlatin.mtx [sic]. Currently, the best I can do is something
> like:
>
> \inputetx{t1}
> \nextslot{n}
> \setslot{whatever}...\endsetslot

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

? Then it is always the first \setslot that does what you want, so there's 
no need to reset any slot. Which is part of why I labelled its usefulness as 
"unclear".

> which lets me add to slots(at least, despite warnings that a slot is
> multiply-defined, that seems to be the effect it has, which is exactly what
> I want),

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

> but since there's no way to remove the kerns and ligatures of an
> existing slot (since the buggy \resetslot doesn't do that),

The catch is that during \etxtovpl, fontinst maintains lists (organised per 
glyph) of in which slot(s) each glyph is placed, since those are needed when 
encoding kerns and ligatures in terms of slots (as the (V)PL format 
requires). Removing items from these lists would be *extremely* difficult, 
and a \resetslot wouldn't even know what list to remove anything from in the 
first place! The only practical solution would therefore be to hold off on 
making slot assignments until after all \setslot commands had been looked at 
once, but that in turn would require making an extra zeroeth pass over the 
ETX file just to figure this out. And my feeling (expressed in the quoted 
comment) is that Yet Another ETX Pass just isn't worth it.

> there's no way
> properly to override a slot; with multislot.sty I can do:
>
> \input multislot.sty
>
> \nextslot{n}
> \setslot{whatever}...\endsetslot
>
> \inputetx{t1}
>
> but then I can't add to a slot.

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 can see two solutions:
>
> 1. Make \resetslot work properly, then a slot can be overridden with
> multislot.sty.
>
> 2. Allow multislot.sty to take the last definition, not the first. Then I
> could do:
>
> \inputetx{t1}
>
> % Add to a slot
> \nextslot{n}
> \setslot{whatever}...\endsetslot
>
> \input multislot.sty
> \multislottakelast % Take last definition of a slot, not first

There's simply no way that could work. Bear in mind that fontinst makes 
*four* passes over each ETX file when generating a font! There's simply no 
such thing as a position halfway through an encoding where you could start 
to redefine the way things work, because any point in an ETX file is both 
preceeded (processing-wise) by the whole file and succeeded by the whole 
file, due to the situation with multiple passes.

> % Override a slot
> \nextslot{n}
> \setslot{whatever}...\endsetslot
>
> I'd argue that it's also more logical this way around, because that's how
> "overriding" normally works: you load the original version, then you
> override it.

There are indeed two possible principles for handling multiple definitions: 
first definition wins or last definition wins. If the latter is more common, 
then it is probably because it is the easiest to implement when each 
definition is like a variable assignment; defining just overwrites old contents.

Fontinst is however quite consistent in rather adhering to the "first 
definition wins" principle, at least in commands named \set<something>. For 
metrics, this comes at some cost, but is motivated by the observation that 
earlier definitions (in particular those made in font metrics files) are 
likely to be more specific and thus more authorative.

For encodings, it is really misleading to imagine the data being specified 
as a simple variable assignment; the reality is much more one of setting up 
a correspondance between things (e.g. glyphs and slots). This correspondance 
is in general not 1-to-1, so it is nothing like a simple assignment, and the 
way data that is actually stored more resembles having the "values" know 
where they are "stored" than "variables" knowing what is "stored in" them. 
So "first definition wins" is not only the consistent principle for this, it 
is also the by far easiest to implement!

> With multislot.sty as it stands, you have to put overrides
> first, and both overriding and adding to slots is impossible (unless I've
> missed something).

Hard for me to say, as I don't see what technical effect you seek to achieve 
by "adding to slots". Or what it amounts to.

> At present I can see only two rather unsatisfactory options:
>
> 1. Ship diffs to t1.etx and have my build process produce patched versions.

t1.etx is not particularly in flux, so shipping the patched versions is 
probably far more user-friendly than shipping a bunch of patches.

> 2. Ship a modified multislot.sty which implements \multislottakelast

Creating that in the first place would be a /highly/ nontrivial task.

> If there's a workaround I haven't thought of, I'd love to hear it.


Lars Hellström