[comp.text.tex] Rational for the location of TeX fonts

ramsdell@linus.mitre.org (John D. Ramsdell) (07/24/90)

I have always wondered why TeX font files are stored in the particular
directories given by most TeX distributions.  Consider this: the
library directory for METAFONT contains just the data one needs to
process METAFONT source files.  It stands to reason that the library
directory for TeX should contain just the data one needs to process
TeX source files, which includes TeX font metric files, but not the
generic font files or any of the other related font formats.  Why
aren't the fonts files for printing and previewing stored in a
separate library directory, called say DVI, along with any other data
required to processes DVI files?
John

kris@diku.dk (Kristoffer H. Holm) (07/25/90)

This posting advocates standardisation & customisation of
font file locations.

John D. Ramsdell writes
> I have always wondered why TeX font files are stored in the particular
> directories given by most TeX distributions.  Consider this: the
> library directory for METAFONT contains just the data one needs to
> process METAFONT source files.  It stands to reason that the library
> directory for TeX should contain just the data one needs to process
> TeX source files, which includes TeX font metric files, but not the
> generic font files or any of the other related font formats.  Why
> aren't the fonts files for printing and previewing stored in a
> separate library directory, called say DVI, along with any other data
> required to processes DVI files?
> John

You are absolutely right, and in fact many programs expect
this. The `proper` way to do it in my opinion (at least on
un*x) is to ensure that every DVI previewer/driver looks up
an environment variable for a `:'-separated list of
directories where bitmap fonts (or ****Script, or whatever
:-) are stored.  The xdvi program (posted on comp.sources.x)
carries this a bit further by looking up both

  XDVIFONTS	`:'-separated list of directory patterns,
		where
		  %f means fontname
		  %d means magnification
		  %p means font family
		(thus the standard would be to set
		  XDVIFONTS=/usr/local/lib/tex/fonts/%f.%d%p).

  XDVISIZES	`:'-separated list of choices for %d above.

This has the added advantage of being able to have your own
additional fonts in you home directory.  It would be nice if

  .	all previewers/drivers looked in environment
	variables DVIFONTS and DVISIZES, and

  .	print spoolers made it possible for users to set up
	these variables for particular print jobs (so that
	we may still use lpr -d on BSD :-).

Hoping that someone listens :)

	
--
--------------------------------------------------------------------
Kristoffer H{\o}gsbro Holm			      <kris@diku.dk>
Computer Science Dept. (TOPPS group), University of Copenhagen
Universitetsparken 1, DK-2100 Copenhagen O, DENMARK    +45 31396466
--------------------------------------------------------------------

ramsdell@mitre.org (John D. Ramsdell) (07/26/90)

Kristoffer H. Holm writes
   You are absolutely right, and in fact many programs expect
   this. The `proper` way to do it in my opinion (at least on
   un*x) is to ensure that every DVI previewer/driver looks up
   an environment variable for a `:'-separated list of
   directories where bitmap fonts (or ****Script, or whatever
   :-) are stored.  The xdvi program (posted on comp.sources.x)
   carries this a bit further by looking up both

     XDVIFONTS	`:'-separated list of directory patterns,
		   where
		     %f means fontname
		     %d means magnification
		     %p means font family
		   (thus the standard would be to set
		     XDVIFONTS=/usr/local/lib/tex/fonts/%f.%d%p).

     XDVISIZES	`:'-separated list of choices for %d above.

I think this proposal is absolutely wrong.  First, the default
location of the fonts is in the TeX library, which is what I was
asking about in my original posting.  Second, and much more important,
the proposal does not allow easy support for fonts generated with more
than one METAFONT mode.  Suppose you have imagen (300 DPI) fonts and
NeXT (400 DPI) fonts.  It would be quite confusing to put both fonts
in the same directory.  An additional advantage of requiring that your
previewer knows which METAFONT mode is used to generate its fonts, is
that the previewer can initiate the creation of any missing fonts.
Please add a font mode pattern as follows:

     DVIFONTS	`:'-separated list of directory patterns,
		   where
		     %f means fontname
		     %m means the font mode used to make the font
		     %d means magnification
		     %p means font family
		   (and set the standard to be
		     DVIFONTS=/usr/local/lib/dvi/fonts/%m/%f.%d%p).

     DVIMODE	The font mode used to make the font using METAFONT.

John

PS.  Here is how my TeX library is organized:  

	| -- inputs --- | ...
	|
tex --- | -- formats -- | ...
	|
	| -- bib ------ | ...
	|
	| -- tex.pool
	|
	|		| -- tfm ------	| ...	
	|		|
	|		| -- vf ------- | ...
	|		|
	|		| -- imagen --- | ...
	|		|
	| -- fonts ----	| -- linotronic | ...
			|
			| -- sun_hires  | ...
			|
			| -- sun_lowres | ...
			|
			| -- ps ------- | ...

It seems that everything in the font directory but the tfm directory
belong in a dvi library.  Do you agree?

spqr@ecs.soton.ac.uk (Sebastian Rahtz) (07/27/90)

   I think this proposal is absolutely wrong.  First, the default
   location of the fonts is in the TeX library, which is what I was
I don't understand this. in what sense is this `default'? TeX only
knows about TFM files, and doesn't give a fig for PK files, and there
is no `standard' (yet) for what dvi drivers should do when looking for
a PK file. So the question you asked, which is perfectly interesting,
is nothing to do with TeX, but with device drivers that use fonts for
which they need to pick up a bitmap. If you happen (as I do) to use
LaTeX for straight text with PostScript fonts, PK bitmap files are
irrelevant anyway. 

sebastian `lets differentiate properly between TeX and CMR' rahtz



--
Sebastian Rahtz                        S.Rahtz@uk.ac.soton.ecs (JANET)
Computer Science                       S.Rahtz@ecs.soton.ac.uk (Bitnet)
Southampton S09 5NH, UK                S.Rahtz@sot-ecs.uucp    (uucp)