# Re: Is this a bug?

• To: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
• Subject: Re: Is this a bug?
• From: Rebecca and Rowland <rebecca@astrid.u-net.com>
• Date: Thu, 11 Jun 1998 14:43:25 +0100
• Cc: fontinst@cogs.susx.ac.uk
• References: <l03130300b19e29bf2172@[194.119.133.57]> (message from Rebeccaand Rowland on Sat, 6 Jun 1998 01:09:55 +0100)

```>Rowland wrote:
>
>>> 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.
>
>I was just saying, that I don't agree with what the fontname doc
>says in that case.  I'd rather use j8a or j8r for raw OsF fonts
>and maybe 7d for fonts, in you have extracted the oldstyle digits
>and left out everything else.

Righto - that makes some sort of sense.

>>> 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
>
>Could it be that something went wrong and you started over again
>without deleting the files produced by the previous run?

That seems likely; I had an early exit because the TeX format wasn't big
enough the first time round.

>>> 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 definition of \textcompfamily used to be in a separate file
>textcomp.tex.  As of fontinst-1.8, I'll integrate the functionality
>into \latinfamily.

Righto; it'd help if you could say a little something about what it does,
so I can have a play with it and attempt to document it.

[snip]
>IIRC, \parse_family does a \setcommand\digit#1{#1oldstyle} to get
>oldstyle fonts rather than using a different set of .etx files.
>Could it be that it doesn't work after \setcommand\digit#1{#1},
>if you presviously did a non-oldstyle installation.

Quite possibly; I've just done a fontinst run with all the previously
generated files cleared out of the way and asking for this only:

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

And I've got a set of vfs most of which have oldstyle numerals in them.
The one exception is the small caps founts: they have `missing glyph'

Given that all the other founts have oldstyle numerals, this seems a bit
odd.  Can anyone explain why this is?

>> 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?
>
>Yes, more or less.  It turns out that Alan's v1.511 had some extra code
>for oldstyle encodings 9d/9o, while Sebastian's v1.6 is based on v1.504.

Ah.  I see.  Yet more confusion...

[snip]

>\latinfamily{<fam>j>}{} and \latinfamily{<fam>9>}{} *are* identical
>in behaviour in Alan's v1.511 and I want to do the same in v1.8.
>However, even if we agree on <fam>j, we still have many copies of
>the LGC, which states that can use both.

I see - thanks.

Rowland.

```