[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Behaviour of \latinfamily



At 12:43 pm +0200 28/5/98, Ulrik Vieth wrote:
[snip]
>> 1) What calls \latin_shapes and when.
>> 2) What \latin_shapes does.
>
>That's what I tried to explain last time.

And this time, I think it's worked.  Thanks very much.

>You call e.g. \latinfamily{ptm}{}, which calls \parse_family to
>intialize some variables such as \font_familly and \latex_family.
>
>Then it calls \latin_weights, which does a number of calls such as
>
>  \latin_weight{r}{m}
>  \latin_weight{s}{sb}
>  \latin_weight{b}{b}
>
>Each of these calls stores the arguments in the variables \font_weight
>and \latex_weight and continues to call \latin_widths.

Right. (I think).  Is \latex_weight used as the specifier in the fd file,
and \font_weight used to find an appropriate afm/mtx file to build an
output mtx/pl file from?

>\latin_widths, in turn, does a number of calls such
>
>   \latin_width{}{}
>   \latin_width{n}{c}
>
>Each of these calls stores the arguments in the variables \font_width
>and \latex_width and continues to call \latin_shapes.

Is \latex_width the width specifier used in the fd file?  What exactly is
\font_width used for?  Is it used to find an appropriate mtx/afm file?

>\latin_shapes, in turn, does a number of calls such
>
>   \latin_shape{} {} {} {n}
>   \latin_shape{c}{c}{} {sc}
>   \latin_shape{o}{o}{} {sl}
>   \latin_shape{i}{i}{i}{it}
>
>Each of these calls stores the arguments in the variables \font_shape,
>\raw_shape, \encoding_shape and \latex_shape and continues to do some
>actual processing for some particular combination of family, weight,
>width, and shape.

Excellent!  This is making sense (very nearly ;-)  One question:

\latinshape{\font_shape}{\raw_shape}{\encoding_shape}{\latex_shape}

Is \latex_shape the specifier used in the fd file?  What do the other three
refer to exactly?  (I'd guess that \font_shape is used to find an
appropriate afm/mtx file to turn into an output mtx/pl file, but what about
the other two?)

[snip useful stuff]

>* For the small caps shape, \fake_shape_c is called, which first looks
>for a corresponding 8a-encoded .afm file of a real small caps font.
>If it exists, it calls \fake_shape_ to do the same steps as above,
>which implies running
>
>   \afmtomtx{<font>c8a}{<font>c8a}
>   \mtxtopl{<font>c8a}{<font>c8a}
>   \mtxtomtx{<font>c8a}{<font>c8r}
>   \mtxtopl{<font>c8r}{<font>c8r}
>
>If a real small caps font isn't found.  \raw_shape and \encoding_shape
>are redefined to {} to {c}, before calling \fake_shape_ once again.
>This wil produce an 8r-encoded .mtx file for the default shape,
>if that hasn't been done already before.
>
> The effect of setting \encoding_shape will come into play later when
>\latin_encodings is called, in which case it will use a different .etx
>file (T1c.etx or OT1c.etx) to generate a faked small caps font.

Now then...  the <font> specifier is <foundry><family><weight>, right?  So
fontinst looks for:

FNNWc8a.afm in the first place.  AFM files in this form full of `normal'
glyph names, rather than stuff like `Asmall' etc., which is why a different
etx file is used for `real' and `faked' sc founts.  Is that right?

[snip]

>Hope this explanation was a little clearer this time.  Still, so far
>we have only dealt with .mtx and .pl files for 8r-encoded raw fonts.
>I haven't looked at what happens, when \latin_encodings is called to
>produce .vpl files for the OT1 or T1 encoding.

This is *incredibly* useful.  It's probably enough to keep me busy for a
week or two - it's cleared up a lot of questions I had (and raised a
handful more).

Thanks very much (yet again)
Rowland.