[tex-k] METAFONT: Issue with generating display-size CM fonts

[Laurence Finston]

Hello Karl et al,

An issue has come up with `mode' when generating CM fonts in display (i.e., large) sizes:

`modes.mf' states the following:

% A common use for modes nowadays is to make high-resolution bitmaps from
% \MF-only fonts to include in PDF output or for autotracing. The
% |dpdfezzz| mode is an 8000$\,$dpi mode with canonical parameter values,
% intended for this purpose.  (Running {\tt dvips -Ppdf} will use this.)
% If you want a lower resolution, similar canonical modes are |supre|
% at 2400$\,$dpi mode and |ultre| at 1200$\,$dpi.

In `cmssbx10ldf.mf' (see attached tarball), `numeric factor' is used to multiply the various sharped dimensions that are the
parameters of the font.  Depending on the mode (set in the calls to `mf' in the rules in `Makefile') and the value of `factor',
one may or may not get an error similar to this when a value exceeds 4096 - eps:

! Value is too large (4247).
<recently read> ;

beginchar->...rdp:=(EXPR3);w:=hround(charwd*hppp);
                                                  h:=vround(charht*hppp);d:=...
l.502 beginchar("D",13.5u#,cap_height#,0)
                                         ;
?

In `cmssbx10ldf.mf', I list a couple of values that either work or don't.  They were arrived at by trial and error:

numeric factor;
%factor = 4.65; %% 4.65 works with 8000gf (dpdfezzz), 4.66 doesn't.  LDF 2022.01.11.
%factor = 4.66;

if known mode:
   factor = 15.5;  %% 15.5 works with 2400gf (supre), 16 doesn't.  LDF 2022.01.11.
else:
   factor = 1;
fi

8000 is a pretty high value for dpi and not necessary for testing purposes.  The problem is that there's a big gap
between `dpdfezzz' at 8000 and the next lowest canonical mode `supre' at 2400.  Obviously, I could just define my own
modes but then everyone with this problem would have his or her own ad hoc solution.

However, `modes.mf' also states this:

% Unfortunately, the number of modes eats up a lot of memory; if your
% \MF\ has not increased the table sizes, you may need to remove
% some of the modes from this file (please rename it to something else then,
% e.g., {\tt local.mf}). If you can suggest a way to redefine |mode_def|
% and/or |mode_setup|, even better; right now, the amount of memory
% used is approximately four times the length of the |mode_def| names.

I haven't had a chance to look at the definitions of `mode_def' or `mode_setup' yet.  On the other hand,
for a given run of MF only one mode is needed.  Would it be a possible solution to change the calling convention of MF, or, if this is immutable, to write a wrapper that would input the needed mode "on-the-fly" so that unneeded modes would never be defined?

Incidentally, the only indication that this list is the one to obtain support for MF is the MF page at CTAN:  https://www.ctan.org/pkg/metafont

However, the tex-k info page at https://tug.org/mailman/listinfo/tex-k makes no mention of MF.  This is the heading:
tex-k -- Kpathsea, Web2c, Dviljk, Dvipsk, Xdvik, etc.

The webpages https://tug.org/web2c/, https://tug.org/kpathsea/ and https://tug.org/metapost.html all exist, but there is no https://tug.org/metafont.  Millions of MF users demand action!

Thanks,

Laurence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ttemp.tgz
Type: application/x-compressed-tar
Size: 149543 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex-k/attachments/20220114/9a79d338/attachment-0001.bin>