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

Re: Behaviour of \latinfamily




> Are you saying that when you execute a \latinfamily command, fontinst
> (eventually) looks for:

> pckm8a.afm then
> pckm8r.afm them
> pckm8r.mtx

> And what if it finds pckm8a.afm?  pckm8r.afm?  pckm8r.mtx?

Sorry, there was some confusion about this.  Forget about 8r-encoded
AFM files for a moment.  What you normally have is 8a-encoded AFM files
and 8r-encoded .mtx files and nothing else.

What fontinst needs to do its work is <fam><weight><shape>8r.mtx.  

In some cases, it can produce a suitable .mtx file directly from 
<fam><weight><shape>8a.afm with a call of 

  \transformfont{pckm8r}{\reencodefont{8r}{\fromafm{pckm8a}}}

which produces as a side effect

  <fam><weight><shape>8a.mtx
  <fam><weight><shape>8r.mtx

This is followed by a call of \installrawfont which produces

  <fam><weight><shape>8r.pl

which can later be converted to .tfm with a pltotf.

In other cases, it will have to fake a shape using previously
generated <fam><weight><other_shape>8r.mtx files and a different
call of \installrawfont.

> Do you mean that the command above tells fontinst to look for
> pckm8r.mtx, and if it fails to find that, it'll look for pckm8r.afm
> and convert it into an mtx file, and that this procedure is followed
> by fontinst at *any* time it's looking for an mtx file?

I believe that converting AFM to MTX _without_ reencoding is indeed
handled automatically.  However, if some transformation is needed 
such as reencoding, slanting or expanding a font, the calling macro 
will have to issue the appropriate call to \transformfont.

>> All this extra stuff for 8r-encoded AFM files is primarily intended
>> for ttf2afm, which until recently happened to drop all the unencoded
>> characters if you told it to produce 8a-encoded AFM files.

> I'll take your word for it :-)

I wouldn't have engaged into this hackery, if it wasn't necessary.

Cheers, Ulrik.