# [tex-live] What do to with cm-super

Ralf Stubner ralf.stubner at physik.uni-erlangen.de
Sat Jun 3 15:39:34 CEST 2006

Vladimir Volovich <vvv at vsu.ru> writes:

> sure - since the LM fonts are of better quality, it is good to use
> them whenever possible instead of the cm-super fonts.
>
> if their metrics for the T1 and TS1 encodings are compatible with the
> EC fonts (which i don't know/didn't check),

Unfortunately they are not compatible even for identical design size. I
have reencoded lmr10.pfb and sfrm1000.pfb with appropriate encoding
vectors to T1 encoding (lm-ec.enc and cm-super-t1.enc) and used
Reinhard's t1diff to compare the results. If anybody is interested, I
can make the resulting PDF file available. In addition I have also build
a LaTeX file that shows /some/ of the differences (process with
pdflatex):

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage[T1]{fontenc}
\pdfmapline{=ecrm1000 LMRoman10-Regular "enclmec ReEncodeFont" <lm-ec.enc <lmr10.pfb}
\begin{document}

{\font\x=ecrm1095 at 10pt\x
\makebox[10em][r]{EC font EC metrics:}
n\"{\i}n \k{i} \k{o} \S 1 \S 2 \S 3 \S 4 \S 5 \S 6 \S 7 \S 8 \S 9
}

\makebox[10em][r]{LM font EC metrics:}
n\"{\i}n \k{i} \k{o} \S 1 \S 2 \S 3 \S 4 \S 5 \S 6 \S 7 \S 8 \S 9

\fontfamily{lmr}\selectfont
\makebox[10em][r]{LM font LM metrics:}
n\"{\i}n \k{i} \k{o} \S 1 \S 2 \S 3 \S 4 \S 5 \S 6 \S 7 \S 8 \S 9

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

The \pdfmapline command does what has been suggested, ie using LM fonts
together with EC metrics. Next, 11pt EC is optically scaled down to 10pt
for reference. As we know this is not the same as 10pt EC, but for the
present purpose this is good enough. You can compare 11pt at 10pt with
10pt at 10pt by commenting \pdfmapline. The next line then uses 10pt EC
metrics but with LM fonts. Finally, the LM fonts are used with their own
metrics.

IMNSHO it is clear that the top EC/EC and the bottom LM/LM lines are
good (with the exception of \k{i} in the case of LM), but the middle
line which uses the LM fonts with EC metrics is not acceptable, since
the 'ï' is offcenter, the ogonek accents are to far to the right, and
the numbers are way to close to the section mark. All this and probably
more is the result of lmr10 and sfrm1000/ecrm1000 having different
metrics. Of course, there is the additional problem that EC has many
more design sizes than LM.

>From my point of view one must not use a font with incompatible metrics.
If one follows this, there are two posssibilities, if one wants to get
rid of (parts of) cm-super in order to save space:

1) Change the t1cm*.fd files to point to TFM files from LM instead of
those from EC. This is a radical and incompatible change, though,
since LM and EC differ wrt to metrics and design sizes. (And wrt the
interpretation of some code points in the T1 encoding.)

2) Stick to EC for metrics /and/ fonts, but inlcude only a part of
cm-super, hence unchanged documents will use Type3 fonts in some
places now, where they used to use Type1 fonts before. The excluded
extended to handle this case, too.

As one can see, both cases have their drawbacks. There is no free lunch ...

In the second case, one still has to decide which subset of the cm-super
fonts should be included. I see four possibilities:

1) The teTeX approach: No cm-super at all. Tell people to use LM
instead. Easy to implement, maximal space saving, but also maximal
problems with Type3 fonts.

2) The type1ec approach: Include only the 10pt design size and tell
fonts. Not difficult to implement, large space saving, still many
problems with Type3 fonts.

3) Try to define a subset of design sizes to include, maybe based on the
ones used by fix-cm.sty. In addition, one could exclude all design
sizes of Dunhill, Fibonacci Medium/Slanted, Funny Roman/Italic and
probably a few more. Not easy to implement, probably one half of
cm-super can be excluded that way. Problems with Type3 fonts should
be minor, especially when fix-cm.sty is used.

4) Leave it as it is, ie include all of cm-super. Easy to implement, no
problems with Type3 fonts, but also no space saving at all.

Again, each possibility has its own set of (dis)advantages and it is a
question of priorities which route to follow.

BTW, the closest one can get to a 'free lunch' is probably the usage of
pfb2t1c and t1c2pfb, both available from CTAN:ps-type1/cm-super/debian.
The idea behind these programs is that a Type1 font can be reencoded in
such a way that compression is much more effective. A real life example
from cm-super:

\$ ls -l sfrm1000.*
total 1104
-rw-r--r--  1 ralf ralf 138204 2006-06-03 14:36 sfrm1000.pfb
-rw-r--r--  1 ralf ralf 137661 2006-06-03 14:37 sfrm1000.pfb.gz
-rw-r--r--  1 ralf ralf 518467 2006-06-03 14:37 sfrm1000.raw
-rw-r--r--  1 ralf ralf  96385 2006-06-03 14:37 sfrm1000.raw.gz
-rw-r--r--  1 ralf ralf 137594 2006-06-03 14:36 sfrm1000.t1c
-rw-r--r--  1 ralf ralf  66202 2006-06-03 14:37 sfrm1000.t1c.gz

(The raw files are produced with t1disasm.) So by shipping t1c files,
one can save about a factor of two in compressed size. Of course,
dvips/pdftex/... do not understand this t1c format, hence the files have
to be converted back on installation, which makes this step more
difficult. In addition, the 'Live' version would have to inlude the pfb
files. One could add a 'mktexpfb' script that calls t1c2pfb as needed,
but I am not sure if it is worth the effort.

Usage of pfb2t1c is not limited to the cm-super fonts. However, right
now it does not work with LM, probably because the LM fonts include an
explicit default encoding vector instead of using StandardEncoding (I
have no idea why the LM fonts are build that way). This looks like a bug
in pfb2t1c. If this bug can be fixed, applying pfb2t1c to all Type1
fonts in TL would give quite nice space saving.

This message has gotten pretty long, but I think I ahve covered all
possibilities. I am not in the position to make any decisions, though.

cheerio
ralf