modeless fonts

[David Kastrup]

   Date: Tue, 19 Sep 1995 06:48:55 -0400
   From: "K. Berry" <kb@cs.umb.edu>
   Cc: dak@Pool.Informatik.RWTH-Aachen.DE
   Content-Type: text
   Content-Length: 1049

	-- PK files not generated by MF go in
	       fonts/pk/modeless/<utility>/dpi<dpi>/<font>.pk
	   [Joachim & Karl]

   The reason for the modeless/ directory, as I recall, is that searches
   should generally take place over (1) the mode-specific directory (if any),
   and (2) *all* mode-nonspecific directories (gsftopk, ps2pk, ...).

   For example, for xdvi, one explicitly has to put the gsftopk// and ps2pk//
   into the path, along with the usual $MODE//. Otherwise the PostScript
   fonts aren't found.

   That said, I'm not sure it's worth making the tree inconsistent just to
   be able to say modeless//. Having the utility name serve as a mode name
   seems natural.

The problem was that the idea of mode directories in the first place
was to separate fonts with equal resolutions designed for different
printers, not to separate Metafont from non-Metafont fonts. The
modeless subdirectory is *not* for non-Metafont files in particular,
but for those fonts where no other design characteristics than the
resolution are of any influence.

The modeless/<utility> naming scheme would, for instance, allow a
directory modeless/metafont as well, if someone used a generic
parameter set (for example, no fillin etc) for generation of the font.

For the font selection mechanism there is no particular reason even to
make a <utility> subdirectory tree under modeless: all fonts are
designed for that size, and that's that. In order to facilitate
searches over this "generic" branch of fonts with equal design
characteristics, it would be useful to have them in one tree. For
purposes of organization, however, one might contrive that sometimes it
might be of interest to separate this into separate trees
again. Specifically if one knows that a certain utility might generate
awful looking fonts which are of use only in emergencies, when no
other utility can generate them.

On the other hand, in the typical setup one will want to search one
mode-dependent font pool, and *all* mode-independent ones. The
"modeless" subdirectory tree warrants that.


       Basic point: The draft doesn't cover PK fonts not created by MF that
       don't have a concept of modes.

   Yes, we do mention this. We say to use the utility name as the mode name.

Yes, but that does not take into account that *all* modeless fonts
have the common property of being usable at the resolution they are
specified for.

Now strictly speaking, as metafont-generatedness and modeness are not
related (one can contrive mode-dependent font-generating utilities
apart from metafont, and vice versa) a general layout of
mode/<utility>/...
would be the logical choice, leading to names like
fonts/pk/CanonDX/metafont/dpi300/cmr10.pk
as opposed to fonts like
fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk for a differently named
utility generating mode-dependent files.

However, for a TeX-oriented tree, the extra mention of metafont
generaated files might seem a bit exaggerated.

So the <utility> subdivision might be of use mainly in the modeless
hierarchie. At least the distinction CanonDX/modeless is much more
useful than the distinction CanonDX/pstopk, which would imply that no
program other than metafont could ever produce printer specific fonts.

Another possible scheme would be the full <mode>/<utility> scheme
(where <mode> can be modeless as well) where /metafont would always be
left out.

This would have fonts/pk/CanonDX/dpi300/cmr10.pk (from metafont) as
opposed to fonts/pk/CanonDX/fetamont/dpi300/cmr10.pk. Perhaps a tadbit
ugly, but "upwards compatible" to metafont only outfits. And it is
still rather possible to search with appropriate patterns for
metafont-only fonts even in the mode-dependent directories (well,
something like fonts/pk/CanonDX/dpi*/*.pk -- oops, I believe web2c
will *not* currently allow patterns like that, perhaps it should?).

So for a consistent scheme I see two possibilities: either require
that current search strategies are extended to cover wishes like the
above mentioned one, or include metafont as utility name always, or
*never* include the utility name, or not allow any utility except
metafont to generate mode-dependent files.

Not much clarification I offer here, do I? Still found this worth
mentioning, and still think that the modeless directory should be the
alternative to the mode-dependent directories, and that I think it not
unwise to have a separation on name of utility, just in case one might
need it for any purpose, or just to prefer one utility over the other,
if deemed appropriate.

-- 
David Kastrup, Goethestr. 20, D-52064 Aachen        Tel: +49-241-72419
  Email: dak@pool.informatik.rwth-aachen.de         Fax: +49-241-79502