[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[email@example.com (Berthold K.P. Horn): Re: Postscript fonts Times-Bold.t]
- To: firstname.lastname@example.org
- Subject: [email@example.com (Berthold K.P. Horn): Re: Postscript fonts Times-Bold.t]
- From: bbeeton <BNB@MATH.AMS.COM>
- Date: Tue 17 Sep 91 10:06:29 EST
- Mail-System-Version: <VAX-MM(229)+TOPSLIB(132)+PONY(256)@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 -- ************************
Date: 16 Sep 91 12:08:06 GMT
From: firstname.lastname@example.org (Berthold K.P. Horn)
Subject: Re: Postscript fonts Times-Bold.tfm vs timesbf.tfm
In article <email@example.com> firstname.lastname@example.org (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
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
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.
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 -- ************************
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 -------------------------------- email@example.com ---
Computing Laboratory, 11 Keble Rd, Oxford OX1 3QD Great Britain
firstname.lastname@example.org "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
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 <email@example.com>, 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-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