[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Behaviour of \latinfamily
- To: Ulrik Vieth <vieth@thphy.uni-duesseldorf.de>
- Subject: Re: Behaviour of \latinfamily
- From: Rebecca and Rowland <rebecca@astrid.u-net.com>
- Date: Tue, 2 Jun 1998 22:57:13 +0100
- Cc: fontinst@cogs.susx.ac.uk
- In-Reply-To: <199806020903.LAA01434@attila.uni-duesseldorf.de>
- References: <l0313030eb19511d0e6bb@[194.119.133.49]> (message from Rebeccaand Rowland on Sat, 30 May 1998 02:51:25 +0100)
At 11:03 am +0200 2/6/98, Ulrik Vieth wrote:
>>> It tries all the weights in \latin_weights, all the shapes in
>>>\latin_shapes,
>>> and all the widths in \latin_widths. (Well, not really. There's a switch
>>> that determines whether fontinst attempts to fake narrow fonts, or whether
>>> it only uses those narrow fonts, which are provided as real fonts.)
>
>> Can you explain what the switch is, and what you need to do to change it?
>> Does fontinst ever change this switch on its own?
>
>IIRC, this switch is called \if_fake_narrow. It is never changed by fontinst
>itself, but there is a macro \fakenarrow{WIDTH FACTOR} to change it.
It certainly looks like it:
\newif\if_fake_narrow_
\_fake_narrow_false
\def\fakenarrow#1{
\_fake_narrow_true
\gdef\fake_narrow_width{#1}
}
As far as I can tell from reading the source code, this controls whether or
not \latinfamily will attempt to fake a narrow fount; if \if_fake_narrow_
is false, it'll happily create vpls for `real' narrow founts if you've got
them under any circumstances. Is this right?
>>> (BTW, the present CTAN version was missing some weights, which were
>>> simply ignored. In addition there were some weight mapping which lead
>>> to problems, such as regular (or book) and medium being mapped to the
>>> same LaTeX weight. I don't know when Sebastian will put up the new
>>> version, in which these problems have been fixed.)
>
>> Is this mapping the `m' weight (fontinst name) to `mb' (fd file weight)?
>
>Yes. The `mb' designation was my idea, since it was inappropriate to
>map both 'r' nad 'm' to the same code. Presumably, it was mistake that
>NFSS codes used 'm' for regular in the first place, but it's too late
>to change it now.
Good stuff - thanks for this.
Rowland.