Fontinst modifications

[Ulrik Vieth]

Lars Hellstrom wrote:

> I'm happy to see that my suggestion for a discussion caused so much
> positive activity. Having the creation of a new, official, DOCed,
> well-documented fontinst v1.8 on the way is certainly more than I
> had hoped for when I wrote my email.

As for fontinst v1.8, I must admit that I got carried away with some
experiments rather than working on finshing something for a release.
I still hope to get it out in the next few days, depending on how
much time I can afford.

> As there has been some interest in my packages, I will send them to
> Ulrik Vieth and Sebastian Rahtz (these two seems to be the ones most
> likely to be the ones who will be involved in writing the next
> version of fontinst).  

Yes, please.  In particular, I'd be interested in the reglyph stuff
you mentioned last time, even more than the rekern stuff.  

Over the weekend, I've come up with an idea to extend \transformfont
along the lines

  \transformfont{<font>j8r}
	{\reencodefontslots{8r}{resetosf}{\fromafm{<font>8a}}

where the first argument of  \reencodefontslots  is the .etx file
used as the target encoding (e.g. 8r.etx), and the second argument
(i.e. resetosf.etx) is an .etx file which contains instructions 
to rename slots, such as
 
  \nextslot{48}
  \resetslot{zero}{zerooldstyle}\endsetslot
  ...

Does this look like a generally useful feature and does it bear
any similarity to what your reglyph is supposed to do?

(You can, of course, achieve a similar effect at .mtx level as well, 
by instructions such as

  \setglpyh{zerooldstyle}\glpyh{zero}{1000}\endsetglpyh

but then you also have to take care of reshuffling the kern pairs

  \ifnum\kerning{#1}{#2}>0
    \setkern{#1oldstyle}{#2oldstyle}{\kerning{#1}{#2}}
  \else\ifnum\kerning{#1}{#2}<0
    \setkern{#1oldstyle}{#2oldstyle}{\kerning{#1}{#2}}
  \fi\fi

which is rather tedious.)

> If there is a wider demand for them, I could also post them to other
> people or to the fontinst mailing list. But be warned: The only
> documentation there is is the comments in the source code (very
> fontinst style, perhaps a little longer at times) and I have only
> had the time to use them with fontinst v1.504 so I cannot tell
> whether they will work with the newer versions. 

I think there are only minor differences between 1.504, 1.6 and 1.7,
so I don't see any particular reason why your stuff shouldn't work.  
OTOH, there were really signficant changes between 1.335 and 1.504,
so very old stuff might be troublesome.

> (In case they will be posted to the mailing list, can anyone tell me
> whether it delivers attachments or should I include the files in in
> the main body?)

Technically I think attachments are always part of the message and
should be delivered by the mailing list all right.  It's just that
different people are using different mailing software and cannot
always cope with attachements.  I usually seem to be getting along.

> As for all this stuff about what various font variants should be
> called, isn't it time the fontname scheme is given a major update?
> As far as I understand it, much of the reason there are so many
> alternative names is that there is not room for full specifications
> even of quite common fonts within the eight character limit imposed
> by some CD file system standard.

I have privately been working on an update of some of the fontname
tables, including a completely new adobe.map with some extra fields.
I don't think the real problem is the eight character length limit 
for font variants, but the 26 x 36 = 936 limit ([a-z] x [a-z0-9]) 
for two-character font family codes.

> I have also heard that some new standard for file systems will allow
> filenames up to 255 characters, thus effectively rendering the eight
> character limit obsolete. 

Most Unix filesystems do have 255 characters, indeed, and they allow
all sorts of characters in the filenames, inlcuding several dots,
whereas ISO-9660 CD-ROM filesystems only allow 8+3 with a single dot.
Recalling the lenghty discussions on the TeX Directory Standard (TDS),
all I can say is that you'll have to stick with the lowest common
denominator, i.e. 8+3 characters, if you want to stay compatible.  
You cannot easily assume a different naming scheme without cutting 
off a major part of the user community.  Such attemps are futile.

> Another observation I have made about "Filenames for fonts" is that
> it is primarily written for people who want to decode font
> filenames, not for people who want to find out what to name a font.

Sure, tell this Karl Berry, if you have any suggestions how to improve
the documentation.  The easisest method is probably looking up the
name in a huge table, but then you need someone to maintain the tables.

Incidently, the Fontname scheme doesn't give a clear specification
how to order the variant codes if there are several, and it may take
some discipline to ensure that font names are built consistently.
For instance, I always put 'i' first and 'j' or 'c' or 'w' variants
after that.  For alternate fonts, I tend to use <font>a8r, if it is
a complete font with only some characters replaced by alternates, 
but <font>7a, if it is a font consisiting only of alternate glyphs.

I could make my tables available, if you like, but be warned that
it contains several incomplete file names for lack of family codes.

Cheers, Ulrik.