[Rainer Schoepf <Schoepf%SC.ZIB-BERLIN.DBP.DE@uga.cc.uga.edu>: use of PK founts under MS-DOS]

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

the following exchange, begun on uktex, has continued on tex-euro.
although the motivation for the original question seemed to be
access to fonts by multiple device drivers, the question of naming
is also raised.  although the fonts discussed here are mf fonts,
there is a parallel to the problem of like names for the same
magnifications for different devices in the case of non-mf fonts
>From different foundries with similar "given" names.
redundant parts of these messages are edited for brevity.
						-- bb
                ---------------

   1) 25-Feb Rainer Schoepf  use of PK founts under MS-DOS
   2) 25-Feb CHAA006%VAX.RHB RE: use of PK founts under MS-DOS
   3) 25-Feb Rainer Schoepf  Forward from Eberhard Mattes: [us
   4) 26-Feb Rainer Schoepf  RE: use of PK founts under MS-DOS
   5) 27-Feb "Konrad Bernloe Font file conventions / Re: use o

Message 1 -- ************************
Date: Mon, 25 Feb 91 14:38:40 CET
Reply-To: TeX-Euro Distribution List for European TeX Users
	  <TEX-EURO@DHDURZ1>
From: Rainer Schoepf <Schoepf%SC.ZIB-BERLIN.DBP.DE@uga.cc.uga.edu>
X-To: UKTeX@tex.AC.UK
X-cc: CUDAT@CU.WARWICK.AC.UK, texhax@cs.washington.EDU,
      tex-euro@dhdurz1
Subject: use of PK founts under MS-DOS

   From:    CUDAT@CU.WARWICK.AC.UK

   I have recently been setting up LaTeX for someone on an IBM PC
   compatible.  I have been using DVISCRS (version 1.3i) from the emTeX
   collection as a previewer, and DVITOPS (by James Clark)
   to convert DVI files to PostScript.

   Both DVISCRS and DVITOPS use the fount name, printer resolution
   and fount magnification to find the required PK file for a fount.
   To do this, DVITOPS can substitute (resolution x magnification)
   in the name of a file it is looking for (the resolution is in
   dots per inch).  DVISCRS does something similar, but it
   uses (resolution x magnification x 5).

   This makes it awkward to have the previewer and the printer driver
   use the same set of founts.  (DVISCRS gives pretty good results
   with 300 d.p.i. founts and it seems silly to have two sets of PK files
   when one will do.)  Fortunately DVITOPS is persistent enough
   to look in all the MS-DOS directories it is given until it
   finds exactly the right fount file, so I name the directories
   according to emTeX's convention and tell DVITOPS about each
   directory individually.  This is a nuisance as the directory
   names then need to be kept short so that they can all fit into
   an MS-DOS environment variable.

   Is there any chance that developers might be encouraged to agree
   on the general principles of how to locate a required fount file?

This is yet another chapter of a very sad story...

The (resolution x magnification x 5) convention is an old one, and I
don't see any reason why it should still be used.  Actually, I don't
see a reason why the directory names should contain the resolution.
There should be one directory for every output device (thus implicitly
or even explicitly containing the resolution of that particular
device), with subdirectories for different magnifications, each
one containing the appropriate .PK files.  The names of these
subdirectories should not contain the resolution, but the
magnification, for a very simple reason: I find it very awkward to
remember that cmr10 for \magstephalf is contained in, say, pk329 for a
HP Laserjet, and in 1395pk for a 1270dpi Linotype.  Instead, both
directories should be named something like "mag1095".

Driver programs should

(1) be able to read a font substitution definition file,
(2) have settable paths for the pk directories, preferably with
    variable parts to conform to different conventions,
(3) no longer use .PXL files instead of .PK files.

I think we should finally put away those old conventions that have
ceased to be useful.

Rainer Sch\"opf

   Dr. Rainer Schoepf
   Konrad-Zuse-Zentrum fuer Informationstechnik Berlin
   Heilbronner Strasse 10
   D-1000 Berlin 31
   Federal Republic of Germany
   <Schoepf@sc.ZIB-Berlin.dbp.de> or <Schoepf@sc.ZIB-Berlin.de>

Message 2 -- ************************
Date: Mon, 25 Feb 91 15:55:21 BST
Reply-To: RHBNC Philip Taylor <P.Taylor%Vax.Rhbnc.Ac.Uk@uga.cc.uga.edu>
Sender: TeX-Euro Distribution List for European TeX Users
	<TEX-EURO@DHDURZ1>
From: CHAA006%VAX.RHBNC.AC.UK@uga.cc.uga.edu
Subject: RE: use of PK founts under MS-DOS

Rainer Sch\"opf wrote:

>>> There should be one directory for every output device  [...]
>>>   Instead, both
>>> directories should be named something like "mag1095".

It is with extraordinary trepidation that I dare to cross swords with Rainer in
public, but I feel justified on this occasion.  His proposed scheme, which has
considerable merit, overlooks, I believe, one very important aspect of TeX: one
can load fonts at {\stress absolutely} any size (within the limits of integer
arithmetic on scaled points/RSUs), and it is therefore possible to load a large
but finite number of sizes, all of which can only be approximated by `mag1095'.
Users should be able to load fonts at any desired size, expressed in points or
whatever units they feel most comfortable with, and indeed users {\stress are}
able so to do within TeX proper. But a scheme which seeks to restrict users to
only those sizes which can be expressed in integer values of \mag, rather than
recognising that a system is needed which allows for arbitrary real font sizes,
continues to impose arbitrary restrictions on font size selection.

I therefore believe that Rainer's second suggestion:

>>> (2) have settable paths for the pk directories, preferably with
>>>     variable parts to conform to different conventions,

has within it the necessary flexibility to allow a totally general solution to
the problem.  One needs to be able to specify an extensible set of directory
hierarchies, with a common theme but varying detail.  For example, Rainer's
proposal could be expressed as [I am assuming the existence of a hierarchical
directory structure, which is essential to the proposed scheme] as

	<device>.<resolution>.mag.<integer-magnification>

while a user more comfortable with font sizes expressed in points could use

	<device>.<resolution>.pt.<integer-part>.<real-part>

and a poster designer could use

	<device>.<resolution>.cm.<integer-part>.<real-part>

or

	<device>.<resolution>.in.<integer-part>.<real-part>

In a system which supports file aliases, all of these could be a pointer to
files contained in a canonical hierarchy

	<device>.<resolution>.sp.<integer-value>

I would welcome Rainer's and other's comments on this proposal.

					Philip Taylor
			    Royal Holloway and Bedford New College,
			    ``The University of London at Windsor''

Message 3 -- ************************
Date: Mon, 25 Feb 91 18:50:12 CET
Sender: TeX-Euro Distribution List for European TeX Users
	<TEX-EURO@DHDURZ1>
From: Rainer Schoepf <Schoepf%SC.ZIB-BERLIN.DBP.DE@uga.cc.uga.edu>
X-To: texhax@cs.washington.EDU, uktex@tex.AC.UK, tex-euro@dhdurz1
X-cc: mattes@azu.informatik.UNI-STUTTGART.DE
Subject: Forward from Eberhard Mattes: [use of PK founts under MS-DOS]


   >   dots per inch).  DVISCRS does something similar, but it
   >   uses (resolution x magnification x 5).
   Use (for instance)
       /pf\texfonts\canon\$rpk
   with dviscrs to use resolution x magnification. $r will be replaced
   with the font size (resolution x magnification). The 1.4d release
   of dvidrv ceased to use resolution x magnification x 5, but still
   supports $s for the old (pxl) convention.

   > Driver programs should
   > (1) be able to read a font substitution definition file,
   > (2) have settable paths for the pk directories, preferably with
   >     variable parts to conform to different conventions,
   > (3) no longer use .PXL files instead of .PK files.
   All this can be done with the emTeX drivers. The
      /texfonts/canon/cmr10.300pk
   font naming scheme will be supported by the next release.
   You may want to use dvips 5.47, it can read the emTeX font libraries.

       Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Message 4 -- ************************
Date: Tue, 26 Feb 91 16:18:12 CET
Reply-To: TeX-Euro Distribution List for European TeX Users
	  <TEX-EURO@DHDURZ1>
From: Rainer Schoepf <Schoepf%SC.ZIB-BERLIN.DBP.DE@uga.cc.uga.edu>
X-To: P.Taylor@Vax.Rhbnc.AC.UK, TEX-EURO@DHDURZ1
Subject: RE: use of PK founts under MS-DOS

   From: CHAA006@VAX.RHBNC.ac.uk
   Reply-To: "RHBNC Philip Taylor" </G=P/S=Taylor/@Vax.Rhbnc.ac.uk>

   Rainer Sch\"opf wrote:

   >>> There should be one directory for every output device  [...]
   >>>   Instead, both
   >>> directories should be named something like "mag1095".

   It is with extraordinary trepidation that I dare to cross swords with Rainer
   [...]
        system is needed which allows for arbitrary real font sizes,
   continues to impose arbitrary restrictions on font size selection.

I see your point.  My main point is to separate the device-dependent
information (resolution) from the device independent information
(magnification).  Whether these directories are called mag1095 or
mag1.095 or mag1095.000 or whatever, I don't care, as long as the
names are the same for all output devices.

There's another problem: what about machines with a flat file system?

Rainer Sch\"opf

Message 5 -- ************************
Date: Wed, 27 Feb 91 14:15:00 N
Reply-To: TeX-Euro Distribution List for European TeX Users
	  <TEX-EURO@DHDURZ1>
From: "Konrad Bernloehr (BERN@DHDMPI50)"
      <BERN%DHDMPI50.BITNET@uga.cc.uga.edu>
Subject: Font file conventions / Re: use of PK fonts under MS-DOS

I agree with Rainer Sch\"opf that there is no reason why the old
(resolution * magnification * 5) convention should still be used.
In fact that convention (which originated from 200 dpi printers in
the early days of TeX) has been used for PXL files only.
The convention for PK files is to include the resolution (in
dots per inch) at which the characters are at their design size
in the directory name. This convention makes sense. Although
for 'single-resolution' output devices like most printers a naming
convention like the one suggested by Rainer ('mag1095' etc.) may
be reasonable as well, only the first one is reasonable for
'multi-resolution' output 'devices' like most (good) previewers.
A good previewer should be able to zoom in and out, usually in
magsteps but better in any arbitrary steps. While simulating a 300 dpi
resolution a font file for 300 dpi might be used at its design size but
when a 121 dpi resolution is simulated the same 300 dpi font file would
be used at \magstep5. Or is there anybody out there who wants to suggest
an independent series of font files for any possible simulated resolution
of a previewer?
The reason for the numeric part is simply that the device driver can locate
the files much easier. An alternative would be to define each directory
(or even each font file) and its corresponding \magnification or resolution
in a font definition file (and that separately for each device or even each
possible resolution of each 'device'). Sounds like a lot of work for setting
things up. An alternative (for PK files only) would be to open all files
and read the resolutions from the files. But you would probably start such
a device driver only before going out for lunch.

In addition to Rainer's suggestion that
>>>
>>> Driver programs should
>>>
>>> (1) be able to read a font substitution definition file,
>>> (2) have settable paths for the pk directories, preferably with
>>>     variable parts to conform to different conventions,
>>> (3) no longer use .PXL files instead of .PK files.
>>>
I would also like driver programs

(4) to use the available nearest neighbours if a font isn't available at the
    requested size, and ultimately
(5) to enlarge or shrink the characters of such fonts to the requested size
    if requested and available size are too far from each other. (I know that
    this causes some loss of details but my own experience with that kind of
    character 'zooming' is very good).

Finally a few words to the scheme proposed by Philip Taylor (i.e.
>>> <device>.<resolution>.mag.<integer-magnification>
>>> <device>.<resolution>.pt.<integer-part>.<real-part>
plus several others of that kind, where file aliases should allow users
to use the naming scheme they prefer. Apart from the work to set all those
aliases up that sounds nice. The problem is that I know only one group
of operating systems (*IX) that could do this job but the subject line
of Philip's email is 'RE: use of PK fonts under MS-DOS'.

Konrad Bernl\"ohr
-------