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

Re: fontmapping files

In a recent message, Karl Berry writes:
> In a recent letter to dek, I asked if adding a ``fontname mapping file''
> to TeX would compromise its TeX-ness.  He said no, that such a feature
> would be a fine adaptation to local conditions.
> For those who didn't see the earlier messages on the subject, the idea
> is this.  When TeX sees \font\foo = fname
> it would look for fname first in this mapping file, which would specify
> some other, real filename.  For example,
> \font\foo = adobe-times-roman
> might have an entry
> adobe-times-roman ptmr
> and then TeX would actually read ptmr.tfm.

  Well, I like this idea a lot better than the alternatives, so far.
One of the things I liked about Karl's original proposed scheme was that
a font name would be decodable without reference to a table  (if, of course,
you were fairly familiar with foundries, typefaces, etc.); the only problem
was that if the entire world was to follow the entire scheme we don't have
enough characters to do it in, since 3 chars for foundry+typeface ---> despair,
or at least the end of being able to keep the separate chars in the name
as separate fields.  If we supposed we could make the prospect of 
standardizing font filenames attractive to system administrators 
and end-useTeXers I don't know why a standard mapping file could not be 
equally attractive and susceptible to actual acceptance as a standard.

> Some people have suggested adding wildcards, .e.g,
> \font\foo = *adobe-times-roman*
> would match
> isolatin1-adobe-times-roman-blah-blah-blah
> as happens in X.
> I am opposed to this.
  Me too; IMHO the proper place for a wildcard function is 
inside a macro package or via aliasing in the mapfile.  
Tex's consultation of the font-mapping file ought to look just 
like (the current) search for a .tfm---either
it is there or it isn't.  

I think we might likely get into tricky portability issues with 
wild cards again. For instance, on my XYZ9000 at home, I will 
presumably modify my fontmap file to say
-> adobe-times-roman  cmr10
-> bitstream-charter  cmr10
-> otherwise-velveeta cmss10
-> amr10              cmr10
(since my FX-80 ink-ribbon typesetter has a limited selection of fonts)
and locally implement a take-whatever-is-available-and-use-it scheme
without necessitating wildcards in the documents I bring home to TeX,
or even my editing the font calls in the documents I bring home.
How would such a locally implemented scheme interact with a built-in
wildcarding?  As the local editor of the fontmap file, I would not like
to have to weigh the possibility that I might be undoing the intention
(if any) of some document's possibly-carefully-crafted wildcard spec
for choosing exactly the desired font of all available fonts.
I would expect such local aliasing in mapfiles to be
fairly common at sites with restricted font availability, i.e. most
of them.


> Comments?
  How to implement?  A mapping file, if one exists, presumably
would be searched before a .tfm file was searched for; on failing
one presumably should still search for a tfm (this would be for
the benefit of users on a multiuser system who need fonts which
are not installed/supported at the system level---without having to
maintain an edited copy of the entire fontmap in their personal
disk space--- also for convenient testing of new fonts).



- - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Thomas Ridgeway, Director,
Humanities and Arts Computing Center/NorthWest Computing Support Center
35 Thomson Hall, University of Washington, DR-10
Seattle, WA 98195   phone: (206)-543-4218
Internet: ridgeway@blackbox.hacc.washington.edu
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* all the usual disclaimers apply, plus any extras which may 
  be needed to cover anything particularly stupid *
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -