cryptic scheme for mode_def names in modes.mf

[karl@cs.umb.edu (Karl Berry)]

Before releasing the next version of modes.mf, I'd like to have another
round of discussion on mode names.  At the moment, things are
exceedingly muddled.

In theory, it makes sense that the names should be taken from the print
engine, not the actual printer.  After all, what difference does it make
if the box on a Canon CX engine says `Apple' or `Sun' or
`Hewlett-Packard'?

But in practice, in most cases, I don't think this works out.  There are
two problems: 1) people don't always know (and it's not always easy to
find out) what the engine in their printer is;  2) printer manufacturers
often change things around, a little or a lot, so that one printer with
a Foo 81 engine should not, after all, have the same mode settings
as another.

I don't think it's feasible, however, to use only the actual device
name, like XeroxFourFiveZeroZero.  This has several problems, which
Rocky pointed out in postings in early April:

1) You end up with long, unwieldy names, that are a pain to type
   (currently we get around this by having random aliases, like `cx' for
   CanonCX').

2) The names can't be used as pathname components (currently people use
   the aliases, when necessary).

3) The names aren't descriptive of what's in the mode_def, so that a
   person with a new device can't easily find related mode_def's (I
   don't think this one is too bad, as it's not all that hard to explore
   the mode_def parameter space from scratch).

4) Using different mode_def's for different fonts on the same device
   leads to names like XeroxFourFiveZeroZeroTypewriterSixPoint.  Not
   very extensible, or readable.

5) New devices which have the same characteristics as old devices end up
  getting new names.
  
I don't think any of these are exactly earthshattering problems, but I
do think they're real.  I don't think there's any way to solve problems
#2 (mode_def names as pathnames) and #4 (different mode_def's for
different fonts) except by making the mode_def name be entirely derived
>From its parameter settings.

Of course, the full names of devices and print engines, should be kept
in modes.mf, as aliases for the short, encoded, names.   But not all
encoded names will have other names (as from #4).

So, I think Rocky's proposal (from April 2), about coding the mode_def
settings in the name, should be adopted in principle.  My particular
idea for the encoding follows.  

We can use eight plus three characters for the name.  (I think.  Are
there systems where you can't give a directory name an extension?)
Here we go:

 M BB FF AA _ RRR

where:
M is the marking process -- `b' for write-black, `w' for write-black.
BB is the blacker value.  Call the first B B1 and the second B2.
  B2 encodes the fractional part of the number -- `z' for zero,
    `a' for .05, `b' for .1, ..., `s' for .95.
  B1 encodes the whole part: `z' for zero,
    `a' for 1, ..., `l' for 10, `y' for -1, ...`o' for -10.
  (I may be off by one on some or all of these, but whatever.)
  (Yes, I know these numbers are never supposed to be negative; but some
   extant mode_def's set them that way, and I don't see any disadvantage
   to allowing it in the encoding.)

FF is the fillin and the AA is the aspect ratio, encoded in the same way.
If the aspect ratio is one, it's omitted.

_ turns into `.'.

RRR is the resolution, encoded as a (sigh) base 26 number (leading zeros
removed).  Again, I like my probably-weird idea of having `z' mean 0 and
`a' mean one.  For things like this, it's really too bad Metafont
doesn't allow numbers in identifiers.

I think we can omit the o_correction, because any mode_def's which
differ in o_correction are virtually certain to differ in something else
(resolution, most likely).

Here is an example:

mode_def CanonCX =                      % e.g., Apple LaserWriter [NTX]
  mode_param (pixels_per_inch, 300);
  mode_param (blacker, 0);
  mode_param (fillin, .2);
  mode_param (o_correction, .6);
  mode_common_setup_;
enddef;

(The mode_param function just check if the parameter has already been
assigned; if not, it assigns the expr on the right to the variable on
the left.  [This allows redefinition of some parameters, e.g.,
fontmaking, from the command line, while leaving the others alone.])

This is going to turn into:

  bzzzd.kn

(write-black, zz = zero blacker, zd = fillin .2, kn = 11 * 26 + 14 = 300)
(wow that looks weird)


Comments?

karl@cs.umb.edu