Re: maintaining modes.mf

[rocky@watson.ibm.com (Rocky Bernstein)]

>I think that instead of trying to come up with a relatively cryptic scheme
>which maps parameter values to mode_def names, we should use a single mode_
>def name for all fonts for a given device and have a "smart program" (when
>needed) which reads a file of names and blacker/fillin values.

>---Tom Reid

One problem I am trying to address is: How do I organize
font directories or servers which make fonts available,
so that users can determine which fonts would be best for
a given printer (or device). I would like to set things up as simply
as possible, with the least amount of confusion, and in a way that minimizes
operating-system dependencies.

Factors:
  Often servers provide fonts in only rasterized form, such as in PK
  format, no MetaFont source is around.

  It would be nice to have a scheme that does not rely on the existence
  of modes.mf (or access to the mode_def file, the program used by
  creator of the rasters, or an auxiliary program). I may not have
  access to these files/programs, or access only to a different version
  that doesn't contain the necessary information, e.g. New devices
  spring into existence.  Also having a scheme gives regularity and
  assistance when new names (or MetaFont parameters) are needed.

  Many people are not MetaFont wizards. It is desirable to make things
  as explicit as possible. Who's going to know that you really have to
  run another program to extract information?
  And currently, many of the servers that provide PK
  fonts do not even have this information in the PK files. For example,
  because most of the AMS fonts use ``end'' rather than ``bye'', and
  given the way waits.mf, modes.mf, or U_Wash.mf used to/currently work,
  this information is not in the file.  For these kinds of rasters, one
  can still provide help to users by just putting the fonts in a
  directory that has a useful name.

One approach that has been tried before is to create directories
which list the dots-per-inch of the device (e.g.
..tex/fonts/300dpi/...  That Tom Reid, myself, and others use multiple
settings of blacker, fillin, ... for a given pixels_per_inch, suggests
the inadequacy of such a scheme.

I don't see how using a single mode_def name improves anything. In
fact it looks like it makes things harder unnecessarily. If you can
create a mode_def on the fly, is it that much harder to create on the
fly a useful name? If you hypothesize ``smart programs'' to extract
the information, then from your standpoint it shouldn't matter what
format of name others might find useful.

Compared with the problems involved with providing a ``smart'' program
for every operating system and hypothesizing that mode_special
information will be in GF and PK files, it seems easier just to
standardize names that convey what kinds of devices a given rasterized
font file would be most useful on.

Perhaps one shouldn't think of the proposal as a way to to assign mode_def
names, but as way to assign a part of the directory or disk name to
give a rough idea of how the MetaFont rasters were created; however I
that think that it is convenient for using as the mode_def name.

Clarification on why modes.mf should be might sorted by
pixels_per_inch and then by blacker: My thought was merely to make it
easy for someone to find the next used value in the sequence.
Currently modes.mf is sorted alphabetically. (Sorting alphabetically
is not inconsistent with sorting by pixels_per_inch and within that
blacker---it depends on the encoding.)

It might be helpful to give printer models alphabetically or by
logical printer group for the purpose of making it easier to find a
given device. This can be done by collecting the additional variable
assignments in one place rather than have them interspersed with the
mode_def, and organizing the assignments in a convenient way.

rocky