What's in a name? A mode by any other name...

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

There seems to be a miscommunication somewhere between Joachim Schrod
(and perhaps others) and me. Perhaps people haven't received the all
of the notes sent---every now and then I get messages from
``MAILER-DAEMON@uunet.uu.net'' about undelivered mail. Perhaps I
haven't been very clear.

For example, I never advocated using a fonts scheme such as
../tex/fonts/300dpi... Just that such schemes have been used and they
are inadequate. (Here is where I think Joachim and I agree though.)
However in the same vein, I feel that a ``printer engine'' name is
inadequate as well.

And I am not sure I completely understand Joachim. For example is a
``specific device'' a single piece of hardware or many of them? If the
idea is that a ``specific device'' is any of the set of devices that
makes the rasters in it look good, then again we are not in
disagreement. I however think it a mistake to call that directory
something like ../fonts/CanonCX.... (I confess though that the servers I've
have set up here in fact use that name.)

A reiteration of the points.

There are problems with using the ``print engine'' as the mode_def name.

1) The print engine is often not known. Some printer vendors conceal this
so as to have the flexibility to vary this. (See Barbara Beeton's
comment in TUGBoat Volume 8 No. 2 on page 132.) It is true that some
printer vendors list a ``print engine'' name and model. However if you
open up the printer, it is not likely that you will find a designation
such as ``CanonCX'' anywhere. I will give Joachim (or anyone else) a
case of smoked herring from Lubec Maine if (s)he can tell me the print
engine for the IBM 4216 model 031 printer. (Astute readers might
suspect that this is a trick question.)

2) (related to 1) There are variations within a given print engine.

Specifying the resolution, darkness of the font, aspect ratio, write
whiteness, is actually more abstract and more helpful to someone
trying to select a font library than using a printer model or print
engine. PK and GF fonts are for raster devices. Therefore it makes
sense to refer to their abstract properties.

This is why I don't understand Joachim's comment about
specification versus implementation. If the same sets of rasters look
good on two output devices, it doesn't matter to me whether the
devices were made by different manufacturers or are referred to as
different print engines. Similarly, it is irrelevant to me
that two specific printers have the same or a common name
if I have to use vastly different sets of rasters to get the best quality
output on each of the printers.

The closest analogy I can think of is with shoe sizes. It used to be
around here that when one went into a shoe store, they had a gadget
you plopped your foot down into which gave a ``shoe size.''  (I
hear Joachim yelling ``specification, not implementation---I want
Converse sneakers, not that I need a 14A shoe.'')

Although it was assumed that the output of such a measuring device was
one's true shoe size, it didn't necessarily mean that one would walk
out wearing a shoe of that size, say 14A. First, the store might not
have had that particular show size. (Likewise a font repository might
not have the exact rasters that make a given output device render the
best.) But second, even if the store had the ``right size,'' shoes were
typically tried on first. If the customer complained that a shoe was
to tight, appealing to the scientific accuracy of the machine (or a
shoe-standardization committee) probably wouldn't have had any effect;
trying a looser shoe would. However this is where the ``cryptic'' name
is useful: 14B is wider than 14A; 13A is smaller than 14A. Likewise
for raster fonts.

I believe a good mode_def naming proposal should:

1) Take into account the fact that there may be variations in a single
   printer (or class of printers)
2) Take into account variation of individual's tastes
3) Expose the issues and not conceal or confuse them.
   (If one believes modes.mf, then RicohFourZeroEightZero
   is an exact replacement for CanonSX and is to be preferred
   over CanonCX. However the latter two
   have deceptively close names, and the former is made by a different
   vendor.)
4) Be easily determinable without reference to anything other than the
   the output of such a device
5) Give assistance for finding the right ``size'' rasters and
6) Give assistance in assigning a new name, since names will probably
   be given in a distributed fashion.

With respect to the above, a ``print engine'' name does not do as well as
one proposed before.

I've probably beat these points into the ground, so I'll stop. I'd
really like to hear other points of view and other proposals.

rocky
IBM Research