Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I'm using the eco package and am getting the following warning:

design size mismatch in local font ecrm2074 in virtual font ecorm2074.vf ignored.

when compiling the following MWE:


  {\huge This causes a warning}

the warning goes away if I don't use \huge (or eco).

Any ideas as to how I can get rid of it?

share|improve this question
\huge is a font switch and not a command with arguments. You should use {\huge text} instead of \huge{text}. –  Gonzalo Medina Nov 7 '11 at 4:20
@GonzaloMedina: changed it, same warning though... –  mpr Nov 7 '11 at 4:25
Yes, I know that the message will still be there. My previous comment was only meant to correct the use of \huge. –  Gonzalo Medina Nov 7 '11 at 4:29
@GonzaloMedina: thanks anyway :) I never thought about it not being a command. –  mpr Nov 7 '11 at 4:40

3 Answers 3

up vote 3 down vote accepted

The "design size mismatch" is issued by TeX when it loads font ecorm2074 which is a virtual font; this means that it's a container of references to other fonts. When TeX loads this font it realizes that the referenced fonts are loaded with a size parameter that differs from what's stated in the fonts themselves.

Judging from line 156 in create.sh in the sources of eco fonts, the recorded size parameter is 20.74, while the referenced fonts (ecrm2074 and tcrm2074) carry 20.7400055.

At such a big size, rounding errors can be expected. The same happens with

  • ecorm1728: 17.28 against 17.279999
  • ecorm1440: 14.40 against 14.399994

but not with ecorm1200 and smaller sizes.

When I run vftovp on the offending .vf files, the program says

Design size in VF file being replaced by TFM design size

The same happens when TeX loads the font and actually corrects the mismatching entry: the difference is very small, so nothing relevant happens.

However this should be regarded as a (small) bug in the eco distribution.

One can regenerate the .vf files with the help of a Bash script: create a directory called, say, ecocorrected and in it put the following regenerate.sh script

for i in /usr/local/texlive/2011/texmf-dist/fonts/vf/public/eco/*
  j=$(basename $i)
  vftovp $i > ${j%.*}.vpl
for i in *.vpl
  vptovf $i
rm -i *.tfm *.vpl

Run the following shell commands

cd ecocorr
bash regenerate.sh

Then the ecocorrected directory can be moved in the correct place:

mv regenerate.sh ..
cd ..
sudo mkdir -p /usr/local/texlive/texmf-local/fonts/vf/public
sudo mv ecocorrected /usr/local/texlive/texmf-local/fonts/vf/public
sudo mktexlsr

When and if the eco distribution will be corrected, you can remove the ecocorrected directory (and rerun mktexlsr).

Actually, running this procedure tells that the eco distribution has several little annoyances, which shouldn't be ignored, but are not very harmful anyway. Personally, I'd live with the warnings, though

share|improve this answer
That was illuminating :) Any idea how I can fix this small bug? (I'm an absolute illiterate in fonts, font encodings and the like). –  mpr Nov 7 '11 at 11:57
@mpr All .vf files for sizes from 14.4 upward should be regenerated with the correct design size. Just live with the innocuous message until someone corrects the small bug. Or regenerate the .vf files yourself. –  egreg Nov 7 '11 at 13:07
Is there any way I can contribute and upload the corrected versions (assuming I get them to work)? if so... how? –  mpr Nov 7 '11 at 14:06
I would contact the maintainer of the eco package. –  egreg Nov 7 '11 at 14:07

This is too long to put into a comment, and also only a partial answer. Switching to a different compiler solves the problem. Perhaps others may have an idea based on the following:

  • Compiling with pdflatex produces the "design size mismatch" font warning. pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    ZLOGBE+SFRM1000                      Type 1            yes yes no       4  0
    WPERDS+SFRM2074                      Type 1            yes yes no       5  0
  • Compiling with latex->dvips->ps2pdf does NOT produce the warning. pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    MPHKJZ+SFRM2074                      Type 1C           yes yes no      10  0
    OTJKZH+SFRM1000                      Type 1C           yes yes no       8  0
  • Compiling with xelatex does NOT produce produce the warning. pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    VSQWHV+SFRM1000                      Type 1C           yes yes no       4  0
    RQEQJE+SFRM2074                      Type 1C           yes yes no       5  0

It is clearly the font encoding. As such, switching to Latin Modern fonts (via \usepackage{lmodern}) also avoids this problem with the following pdffonts outputs:

  • Compiling with pdflatex, pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    JVWJQI+LMRoman10-Regular             Type 1            yes yes no       4  0
    NHHVPB+LMRoman17-Regular             Type 1            yes yes no       5  0
  • Compiling with latex->dvips->ps2pdf, pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    MPHKJZ+LMRoman17-Regular             Type 1C           yes yes no      10  0
    OTJKZH+LMRoman10-Regular             Type 1C           yes yes no       8  0
  • Compiling with xelatex, pdffonts produces:

    name                                 type              emb sub uni object ID
    ------------------------------------ ----------------- --- --- --- ---------
    VYDDOZ+LMRoman10-Regular             Type 1C           yes yes no       4  0
    ICNJUT+LMRoman17-Regular             Type 1C           yes yes no       5  0
share|improve this answer
I fear I lack the TeXpertise to fully comprehend your answer... What's pdffonts? Why do different toolchains produce different encodings? How can I ask for a particular one (I'm guessing 1C) in the offending line? –  mpr Nov 7 '11 at 4:56
I am also very unfamiliar with font encodings, hence my "non-answer" answer. However, it showed that switching to (say) lmodern is a possibility. pdffonts is a command-line program that outputs information on fonts contained within a PDF. –  Werner Nov 7 '11 at 5:09
indeed switching to lmodern solves the issue... but I lose oldstyle numbers with it. Maybe unrelated, but I get Argument of strip@CM@prefix@ has an extra } errors when using lmodern with mmap (the error comes from mmap). –  mpr Nov 7 '11 at 5:28

OK, I think I've got it now:

The eco package somehow messes up the fonts and trouble arises with certain combination of sizes, shapes and weights. In this particular case, the problems where in the title pages and on the part headings.

Luckily, I was already using the sectsty package and managed to get out of the latter with:


(the \fontfamily{cmr}\selectfont "trick" I learned from another question of mine).

For the title pages it was enough to say \fontfamily{cmr}\selectfont where appropriate.

Hope this helps someone else trying to get rid of that pesky little warnings!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.