[bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn): Re: Postscript fonts Times-Bold.t]

[bbeeton <BNB@MATH.AMS.COM>]

these two messages have just appeared on comp.text.tex.  both touch
on the matter of file names for fonts and the first also on the
encoding arrangement of postscript fonts.  these are two topics
that really do need attention and agreement on some common approach
if we are to avoid chaos.  (perhaps we already have chaos ...)
                ---------------

   1) 17-Sep bkph@wheat-chex Re: Postscript fonts Times-Bold.t
   2) 17-Sep Damian.Cugley@p METAFONTware: mff (METAFONT wrapp

Message 1 -- ************************
Newsgroups: comp.text.tex
Date: 16 Sep 91 12:08:06 GMT
From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
Subject: Re: Postscript fonts Times-Bold.tfm vs timesbf.tfm

In article <958@ltb.ltb.bso.nl> wierda@ltb.ltb.bso.nl (Gerben Wierda) writes:

Gerben Wierda writes:

   there are two sets of postscript fonts for TeX. I have Times-Roman and their
   ilk and I have timesbf and their ilk.  The difference is that the latter
   has a character table layout that has the accents on the place where plain 
   and lplain expect them.

   The Times-Roman versions are part of dvips, but the other ones I have on my
   NeXT, and I do not remember where they come from (or if they were originally
   there). Can anybody tell me what the status is of these fonts in the TeX
   community?

This is one of a small number of issues that is in desparate need of
standardization.   It is particularly urgent now that more and more people
are using non-CM fonts in TeX.  non-CM fonts can be used in a number of ways:

	(a) encoded as they come - `raw' `native' encoding
	(b) reencoded as in a related TeX font - e.g. `TeX text' encoding
	(c) reencoded to ANSI encoding
	(d) reencoded to ISOLatin1
	(e) reencoded to some other scheme
	.
	.

(The encoding vector is the mapping from character code (0 - 255) to
character glyph (or character name)).

One can come to grief when the TFM files that TeX has access to were made
using a different encoding than that assumed by the DVI-to-whatever
proceessor.  And since TFM files (unlike AFM files) do not make provision
for fully specifying the encoding vector, there is no way to really check
(Yes, there is an optional field for specifying the name of an encoding, but
there are only 8 names that are in any way considered `standard' and the
field is optional).

With TeX 3.0 one of the main reasons for reencoding fonts (inability to
handle characters above 127) has been removed.  In many cases the encoding a
font comes with works quite well.  Using the `raw' encoding helps avoid
confusion.

If the font HAS to be remapped (for use with TeX before 3.0 say), then it
usually is best to use one of the eight standard TeX mapping 
(`TeX text' for a `roman' font, `TeX italic' for an `italic' font etc.)
Then, to avoid confusion, use a different name for the TFM file (and other
font files) from that used for the unmolested version. 

So, for example, `por.tfm' corresponds to `raw' Palatino Roman, while
`porx.tfm' corresponds to Palatino Roman reencoded to `TeX text' layout.  
By the way, using the font file name supplied by the font vendor as a base
for the names of TFM files also helps cut confusion.


To summarize:  

there is a problem with reencoding of non-CM fonts and with font file naming.


The following may help:

(*) avoid reencoding a font unless there is a really good reason.

(*) use one of TeX's eight standard reencodings if possible.

(*) if one of TeX's `standard' encoding vectors won't do, then try 
    another well known standard such as ANSI, ISOLatin1, TrueType 
    standard, or Adobe StandardEncoding.

(*) use the font vendors font file names for constructing TFM file name.

(*) add an `x' to the font file name(s) if the font has been reencoded.


At the very least, one has to be very explicit about:

(a) What encoding was used when a TFM file was generated, and

(b) What encoding the DVI processor thinks it should be using.


You may not be aware of potential problems resulting from these issues,
because somebody has set up your environment so that TeX's TFM files and the
files used by the DVI processor are compatible.  But if you ever move your
files to another environment (say to electronically submit a paper or book
to a publisher) then these difficulties may very well affect you - and in
nasty ways that are not at first apparent!

Message 2 -- ************************
Newsgroups: comp.text.tex,comp.fonts
Date: 16 Sep 91 15:28:20 GMT
From: Damian.Cugley@prg.ox.ac.uk (Damian Cugley)
Organization: Computing Laboratory, Oxford University, UK
Subject: METAFONTware: mff (METAFONT wrapper) release 2.8.1 available

A new version of mff is now available from the Oxford University
Computing Laboratory archives.  (See below for what mff is.)

As well as some bug fixes and portability enhancements, there are now
five sample font programs bundled with it (Ditko, METAFONT logo,
Computer Modern, CM Typewriter and CM Sanserif Typewriter).  It includes
"man pages" for its command-line arguments parser in lieu of proper
documentation (which is half-written and may stay that way until I have
some time free).

 ---- Damian Cugley -------------------------------- pdc@prg.ox.ac.uk ---
     Computing Laboratory, 11 Keble Rd, Oxford  OX1 3QD  Great Britain   
 ------------------------------------------------------------------------
      malvern-request@prg.ox.ac.uk		   "share and enjoy"
 ------------------------------------------------------------------------

WHAT MFF IS

    mff grew out of a UNIX shellscript I had for running METAFONT and
    installing the TFM and PK files.  Its unique feature is that it will
    parse a font name "fmvbi10" as "10pt bold italic" and run
    METAFONT with variables like |weight| and |italicness| set appropriately
    (all that is user-definable, of course).  The driver file understands
    these and sets stem widths etc. based on them.  The practical upshot of
    which is that I have *one* driver file malvern.mf and a command like

	mff fmv{r,ri,bx}{8,10,12}

    creates 3*3 = 9 fonts automagically.  mff isn't vital but it is *very*
    convenient for creating fonts on the fly.

    mff comes with five sample meta-fonts thrown in for free!


HOW TO GET IT

    At present it is on the Oxford archive-server.  This program will
    not send files of more than 100K bytes and will not send two shar
    files in one mail message, so you have to send N requests (in N
    separate mail messages) to get an N-part package.

    Send a message of the form

	send prog FILE

    to <archive-server@prg.ox.ac.uk>, where FILE is one of:

	mff-1.shar	)   mff 2.8.1 (a C program for UNIX
	mff-2.shar	)   but mostly tested on Suns).
	mff-3.shar	)   

	mff-28-1.shar	)   the old version (2.8), for those that like
	mff-28-2.shar	)	outdated software
				
	mff-patch00.shar    patch files to convert mfjob 2.7.1 -> mff 2.8
	mff-patch01.shar    patch files to convert 2.8 -> 2.8.1

    The server also understands the messages "help" and "index CATEGORY".

    The files are sent as "shell archives" -- ".shar" files.  On UNIX
    systems they are unpacked by running the Bourne shell (/bin/sh) on
    them.  Each part of the package unpacks into a directory named after
    the version number to prevent clashes.


CURRENT STATE OF PLAY WITH MALVERN

    Since Malvern release 0.3, I have modified some character programs
    to "compress" -- rather than just distorting curves into
    elliptical shapes, letters like "O" become oval and other curves
    change to suit.  0.4 will come when I've finished most of that.  The
    "supplement" pack may be folded into the distribution.  I'm also
    adding a couple of files to make it easy to use Eberhard Mattes'
    MFjob to create Malvern fonts.  I can only work on it during my
    scant spare time, however, so these simple changes may take some
    time.
-------