[Fontinst] \resetslot in multislot.sty would be nice to have working
Lars.Hellstrom at residenset.net
Mon Aug 5 23:35:38 CEST 2013
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
Is there a reason you don't just do those tasks in the opposite order, i.e., go
% First do my stuff:
% Then fill in the rest as in T1 encoding:
? 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
> 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
> 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
> 2. Allow multislot.sty to take the last definition, not the first. Then I
> could do:
> % Add to a slot
> \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
> 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.
More information about the fontinst