[tex-live] Using LM instead of CM (was: What do to with cm-super)

[Ralf Stubner]

karl at freefriends.org (Karl Berry) writes:

> P.S. A somewhat related question: can you easily adapt your test file to
> compare LM and *CM*?  (I briefly tried and failed.)  I.e., are LM
> outlines usable with CM metrics?  Knuth himself has said that various of
> the improvements in LM are desirable ... just wondering, at this point.

Do you remember which changes Knuth considered desirable?

Anyway, replacing CM in its Type1 incarnation from Bluesky Research with
LM is easier than replacing EC with LM, since the former possibility has
been explicitly taken into account. For example, LM contains uppercase
greeks and many other glyphs just to take care of the rather odd
encoding of the CM fonts (cmr5 and cmr10 having different encoding etc).
LM even comes with a set of encoding vectors and map files for using it
instead of CM (text, CS, PL, and VN variant, no math; lm-rep-*.map).
AFAIK bsr.map and bsr-interpolated.map have allready been split into
parts that can be replaced by LM and parts that cannot (ie math fonts).

How good does this work? I have reencoded several fonts from LM with the
appropriate encoding vector and compared the resulting fonts with the
appropriate font from CM. From the limited set I have tested, it seems
as if the metrics are identical. The outlines are almost identical,
however the position of some accents has been changed. This can cause
problems when the original accent position is taken as basis for further
macros. The simplest example for this is the \hbar macro that in LaTeX
simply overprints a mathitalic 'h' and a macron accent. The macron
accent in LM is slightly higher than in CM which somewhat distrubes the
look of \hbar. Here is an example file:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}

\pdfmapline{=cmr10 LMRoman10-Regular "enclmrepcmrm ReEncodeFont" <lm-rep-cmrm.enc <lmr10.pfb}
\usepackage[ngerman,english]{babel}
\usepackage{graphicx}
\newcommand{\teststring}{\'e \`e \"a \"o \"u 
  \foreignlanguage{ngerman}{\"a \"o \"u} $\hbar$}
\begin{document}

\makebox[10em][r]{CM font CM metrics:}
\scalebox{1.08}{\small\teststring}

\makebox[10em][r]{LM font CM metrics:} 
\teststring

\makebox[10em][r]{CM font CM metrics:} 
\scalebox{0.85}{\large\teststring}

\makebox[10em][r]{LM font LM metrics:}
{\fontencoding{T1}\fontfamily{lmr}\selectfont\teststring}

\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The argument to \pdfmapline comes straight out of lm-rep-cmtext.map. The
next lines compare scaled up 9pt CM, 10pt LM with 10pt CM metrics,
scaled down 12pt CM, and 10pt LM with 10pt LM metrics and T1 encoding.

One can see from this example that in the lines where 10pt LM is used
for the macron accent (2. and 4.), the bar in \hbar is uncomfortably
close to the top serif of the 'h'. 

In addition, one can see the changes that have been made to some
accents. The accute and grave accent have been shifted horizontally,
while the dieresis has been shifted down. In principle, the latter is a
good thing. At least to my german eyes the first set of 'ä ö ü' looks
better, when LM is used. The problem is, that the too high dieresis in
CM has been known for a long time, which is why german.sty and its
descendants contain code to lower it. This is what one sees in the
second set of 'ä ö ü'. Here CM (1. and 3. line) and LM with precomposed
glyphs (4. line) look good. On the second line, which we are interested
in, the dieresis is a bit to close, especially for the ü.

I don't know if there is any other code around that is based on the
explicit position of the accents in CM. If yes, similar problems to the
ones shown above should be expected. Also I have only tested fonts from
the bsr collection so far, not from the cs, pl, or vn variants.

There is a further problem that the hinting of the LM fonts is rather
strange at the moment (v0.99.3), as they contain many unnecessary hints.
Actually I am surprised that up to now I have only found one problem
that is visible in real life (small cap 't' appears smaller than, eg,
small cap 'e' or 'f'). But then, I haven't searched systematically for
hinting problems. (That's one of the most boring works I can imagine.
;-)

The problems shown above are less severe than those shown for the
EC->LM replacement. But the potential gain is also smaller, since bsr,
cs, pl, and vnr fonts together bring in less than 10M of PFB files. And
at least for bsr, only a part can be replaced by LM.

cheerio
ralf