[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: maintaining modes.mf

>A first question which comes in my mind: Shall a mode_def be used for
>the creation of all fonts for one device, or shall there be different
>mode_def's for some fonts?

Good point, but this is yet another reason to use characteristics
rather than printer engine or printer model. (No one has yet to suggest
printer *name*, i.e. ``Fred'' or ``Tania.'' Sorry, I haven't been
getting enought sleep.)

I know that for the 240 dpi printers I've played with,
cmtt's diagonals for M's and W's looked better with less blacker. However,
the font then didn't match in weight with the rest of the fonts. I
also couldn't get agreement that it was that much better either.
What I did was have a smarter program
calling Metafont to  look up in a table what mode name to use given
the font name, device and magnification.

However the proposal of using the font characteristics in the name is
independent of whether one mode_def is used for a device or not.

By using the characteristics, the mode names would probably be close
for a given printer: e.g. 240DPI-Black.5... vs. 240DPI-Black.4...

On the train in today, I was spec.ing out name spaces. I figure, I can
easily fit in all the information I need in eight characters and
simply letters. To wit:

Two letters for the pixels_per_inch
One letter  for the blacker
One letter  for the fillin
One letter  for the aspect_ratio
One letter  for the whether write_white or not,
One letter  for different variations of the above that fall within the
            same name

This leaves 1 letter left! (Karl, eat your heart out.)

With two letters for the pixels per inch, this gives
26 * 26 = 676 possibilities. Using one combination for a range of 10
pixels per inch I think should be enough.
(Even if 6760 dpi is not large enough, at that resolution, you
know the what the blacker, o_correction, and fillin are going to be and
can use these fields.)

Blacker increments of .1 between 0 and 1 might be okay.
For safety I suppose we could go with .05. Comments?

For fillin increments, we would probably have to accommodate the
negative numbers that are already there. Increments of .1 between -1
and 1?  Or between -.2 and 1? Again, I have no feel for what ranges
and increments should be used.

To map aspect ratios into one of 10 or 20 (or 26) values a
a suggestion is something like 1/1, 1/2, 1/3, ... and 2/1, 3/1,
where 1/1 really means between 1/2 and 2/1. I just throw this out as
an idea. I think one would want to have a lot more granularity around
1 than what I have here. For example, 10/10, 9/10, 8/10, ... and
11/10, 12/10, ...

Although I hate complex codes where simple ones will do (perhaps this
is due to an overexposure in the environment I am in) I don't see any
way around a coded mode_def naming scheme.
I have it in the back of my mind that if such a
scheme were used, I would to modify the ? macro in modes.mf to
display in more verbose terms what each mode meant. Also, I would try
to provide a program that decodes/encodes a name. (I was thinking I'd
write it in TeX or Metafont so it would be portable.)

Also, I would suggest (this is independent of the name) that
modes_def's in modes.mf be sorted by pixels_per_inch and within that by
blacker. (After this I don't care if it is by write_whiteness next or
fillin, or o_correction or name.)