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

[Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU>]

-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 ...)
 
We already have chaos, but...

-From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
-Subject: Re: Postscript fonts Times-Bold.tfm vs timesbf.tfm

-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:

I'll agree here with the preceding statement.

-	(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
-	.
-	.

-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.

This is one of the biggest misconceptions about TeX that I've
encountered and it pops up rather frequently. TeX could always
(well maybe not pre-WEB, but TeX82 at least) handle 256 character
fonts. The PXL format as defined can only handle 128 characters
but there are so many reasons for avoiding PXL fonts that's not
even an issue.

I have always argued (and one can ask people who were present at
the TUG meeting in Montreal about this if you have doubts) that
the driver should deal with fonts on the output device in the
encoding that they appear on that device by default. That means
that Times Roman on a PostScript printer will have its f-ligs
somewhere over 128 along with all the accents etc. Remapping
should be handled by virtual fonts (a la Tom Rokicki's
dvips/afm2tfm package) with the remapped font corresponding to
the proposed encoding from Cork (or some relative thereof. I find
some characters in the coding spurious (when's the last time you
saw per-mil anywhere but in a font character inventory?) and the
lack of vacant spaces for additional design-specific ligatures is
a bit disturbing (a current design that I'm developing would look
best if a shortened L could be substituted for the normal L when
LA appears in the output. Where to put the alternative L along
with the two variant Q's and the ft and fj ligatures?) But I
digress). Use of virtual fonts means that support for native
fonts might require changes to some existing device drivers, but
any standardized scheme will require similar changes.

-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. 

Well, the remapping will always occur and obviously two names are
needed.

-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.

Why not use the existing convention called for by Karl Berry's
scheme of prefixing with 'r' for the "raw" font? Thus, we have
plr for Palatino as the user sees it and rplr for the raw
version.

Using the font vendor's name is simply not practical. For one
thing some vendors assume that the font is only going to be used
on one platform (almost always Macintosh) and so give it a name
that won't work elsewhere. Others have different names depending
on who's buying the font. Adobe calles Times Roman Times-Roman on
the Macintosh and TIMES on the PC.

-To summarize:  

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

Aside from the arbitrary mapping of accented characters by
afm2tfm, I think Tom Rokicki's package deals with the problem in
the best possible way.

-The following may help:

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

You mean like being able to use the \' command? Use of VF
remapping makes this consideration irrelevant.

-(*) 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.

I'm sorry but these suggestions seem like they have come out of a
vacuum. Isn't the whole idea of proposing standards so that they
can
  (a) be USED
and
  (b) be AMMENDED if they turn out to have inadequacies.

I've pointed out earlier the problems with some of your
proposals.

-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.

With VF, the issue becomes moot.

-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!

Which is, I assume part of the reason why things like Karl
Berry's proposal and the Cork standard were proposed, n'est ce
pas?

-dh

Don Hosek                  
dhosek@ymir.claremont.edu  
Quixote Digital Typography 
714-621-1291