Is this a bug?

[Rebecca and Rowland]

>> Anyway...  I got fontinst to run on:
>
>> \latinfamily{pck}{}% Caslon Book BE
>> \latinfamily{pckx}{}% Caslon Book BE
>> \latinfamily{pck9}{}% Caslon Book BE
>
>> With these afms present:
>
>> pckb7d.afm
>
>I'd prefer to call it pckbj8a.afm, given that OsF fonts have a full
>set of glyphs, of which only a few differ from the normal font.

My copy of the fontname documentation states that 7d is used for OsF (yes,
stated exactly like that) called oldstyle digit encoding; while j is for
oldstyle digits.

To me, this seems that you should use 7d for a fount with a full set of
glyphs which includes oldstyle digits; while j should be used for founts
with oldstyle digits and little else.

>Anyway, these fonts aren't used, as the oldstyle digits, if any,
>are taken from the expert fonts.

Right.

>> pckb8a.afm
>> pckb8x.afm
>> pcki7d.afm
>
>Should be pckri7d.afm or pckrij8a.afm, but don't forget the `r'!

Oh yes.  Stupid boy that I am.

>> pckm8a.afm
>> pckm8x.afm
>> pckmc8a.afm
>> pckr8a.afm
>> pckr8x.afm
>> pckrc8a.afm
>> pckri8a.afm
>> pckri8x.afm
>
>> And I noticed three strange things:
>
>> Firstly, that fontinst seemed to be running something like 1/5 of
>> the speed I'd seen previously.  Have the recent modifications slowed
>> it down, or should I look for another cause?
>
>I don't think it should have slowed it significantly, but the number
>of kerns might have some effect.


>> Secondly, the pck8r.fd was created correctly, but pckx8r.fd and
>> pck98r.fd weren't.
>
>It should have created 8rpck.fd, 8rpckx.fd and 8rpck9.fd, followed by
>the same for OT1 and T1.

It created 8rpckx.fd and 8rpck9.fd, but they both had no entries:

\ProvidesFile{8rpckx.fd}
   [1998/06/05 Fontinst v1.7 font definitions for 8r/pckx.]
\DeclareFontFamily{8r}{pckx}{}
\endinput

Thierry seems to think this is correct behaviour; I'll believe him.

>> And thirdly, the resulting fount families: pck, pckx, and pck9
>> appear to be identical when I print a test sheet.  In particular, I
>> only get oldstyle numerals with small caps, but I get them with pck,
>> pckx, and pck9.
>
>The first \latinfamily{pck}{} should have produced 7t and 8t fonts
>without oldstyle, since the expert set isn't used.

This is what I see (aside from sc)

>  Similarly, a
>\textcompfamily{pck}{} should produce 8c fonts with missing glyphs
>in the slots for oldystyle digits.

Can you say a little more about \textcompfamily?  I've never heard of it
before now, and it's not in the v1.3 or v1.5 documentation

>The small caps fonts will have oldstyle digits as their default set.

Yes.

>The second \latinfamily{pckx}{} should have produced 9t and 9e fonts
>with expert glyphs (e.g. ff-ligatures), but without oldstyle numbers.

That's what I see, so this seems okay.  Interesting, fontinst has done an
astonishingly good job of faking the missing ligatures: there's no visible
difference between the `real' ligs and the fake ones when printed on my
300dpi inkjet at 10pt.  The only obvious difference even at 90pt is that
the break in the cross-bar is obvious where two `f's are next to each other.

>\textcompfamily{pckx}{} should produce 9c fonts with oldstyle numbers
>and perhaps a few more expert glyphs than are available in 8c.
>
>The third \latinfamily{pck9}{} should have produced 9t and 9e fonts
>with expert glyphs (e.g. ff-ligatures) and with oldstyle numbers.

I get the 9t and 9e founts, but no oldstyle numerals.  Given that I did a
single fontinst run, asking for:

\latinfamily{pck}{}% Caslon Book BE
\latinfamily{pckx}{}% Caslon Book BE; expert
\latinfamily{pck9}{}% Caslon Book BE; old style numerals

I'd expect that the vpl files created by \latinfamily{pck9}{} would
over-write those created by \latinfamily{pckx}{}.

This looks like a problem to me.  Can anyone explain what's going on?

>These should actually be called 9o and 9d, as per Alan's v1.511.

This seems to be the problem: it seems that when fontinst made the 9t/9e
founts after \latinfamily{pck9}{}, the result really *was* 9t/9e when it
should have been 9o/9d.  Does this mean fontinst has a bug and needs fixing?

>\textcompfamily{pckx}{} should produce 9c fonts identical to the
>previous case.

Right, I think.

>Independent, of whether or not you get expertized 9t or 9e fonts,
>the small caps fonts will always have oldstyle digits by default.

Right; this is because I've got `real' sc founts, correct?

>> Can anyone explain these observations?
>
>> In particular, I'd like to know exactly which (virtual) founts are
>> supposed to end with oldstyle numerals, and what difference there is
>> supposed to be between pck, pckx, and pck9.
>
>Hope I just did.

Not quite - it's very useful, but...

You've given a perfectly clear explanation of what *should* happen, and
I've added yet more incredibly useful stuff to my big file of notes on how
fontinst works.

The problem is that I didn't get what you said I ought to get.  Does this
mean that fontinst is mis-behaving?

>P.S.  Given that we already have 9* encoding names, I'd really like
>to get rid of using `9' as a variant letter.  Can we agree on 'j' ?

Is it necessary to have a distinction between `old style digit encoding'
and `old style digits', as is made in the fontname documentation?  If not,
changing to `j' makes sense, and it probably makes sense to tell Karl Berry
about the change to see what he thinks.  Given that the fontname scheme is
very important to fontinst's behaviour when executing \latinfamily (and, I
assume, the undocumented \textcompfamily command), it probably makes sense
to change fontname unless there's a good reason to keep 9 as the OsF
variant letter.

>Furthermore, would it be acceptable to hack fontinst, so that
>\latinfamily{<fam>9}{} automatically does \latinfamily{<fam>j}{} ?

Hmm...  I'd say no.  Certainly change fontinst to act on
\latinfamily{<fam>j>}{}, but the documentation should make it clear exactly
which variant letters are acted on and exactly what each variant letter
makes fontinst do, so there should be no reason for anyone to try <fam>9.
(This is assuming that the `9' variant is replaced by the `j' variant).

Rowland.