我正在使用eco包裹并收到以下警告：
design size mismatch in local font ecrm2074 in virtual font ecorm2074.vf ignored.
编译以下 MWE 时：
\documentclass{book}
\usepackage{eco}
\begin{document}
{\huge This causes a warning}
\end{document}
\huge如果我不使用(或eco)，警告就会消失。
关于如何摆脱它，您有什么想法吗？
答案1
TeX 在加载虚拟字体时会发出“设计尺寸不匹配”信息ecorm2074；这意味着它是其他字体的引用容器。当 TeX 加载此字体时，它会意识到引用的字体加载的尺寸参数与字体本身中所述的尺寸参数不同。
create.sh从字体源代码中的第156行来看eco，记录的大小参数为20.74，而引用的字体（ecrm2074和tcrm2074）带有20.7400055。
在如此大的尺寸下，舍入误差是可以预料的。同样的事情也发生在
ecorm1728：17.28 对 17.279999ecorm1440：14.40 对 14.399994
但不适用于ecorm1200更小的尺寸。
当我运行vftovp有问题的.vf文件时，程序说
Design size in VF file being replaced by TFM design size
当 TeX 加载字体并实际纠正不匹配的条目时也会发生同样的情况：差异非常小，因此不会发生任何相关的事情。
然而这应该被视为eco分布中的一个（小）错误。
可以.vf借助 Bash 脚本重新生成文件：创建一个名为的目录，ecocorrected并在其中输入以下regenerate.sh脚本
#!/bin/bash
for i in /usr/local/texlive/2011/texmf-dist/fonts/vf/public/eco/*
do
j=$(basename $i)
vftovp $i > ${j%.*}.vpl
done
for i in *.vpl
do
vptovf $i
done
rm -i *.tfm *.vpl
运行以下 shell 命令
cd ecocorr
bash regenerate.sh
然后ecocorrected可以将目录移动到正确的位置：
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
当eco分布被纠正时，您可以删除该ecocorrected目录（并重新运行mktexlsr）。
实际上，运行此过程表明该eco发行版有几个小问题，这些小问题不容忽视，但无论如何危害不大。不过，就我个人而言，我会接受这些警告
答案2
这太长了，无法放入评论中，而且也只是部分答案。切换到不同的编译器可以解决问题。也许其他人可能会根据以下内容提出想法：
编译时
pdflatex会产生“设计尺寸不匹配”字体警告。pdffonts产生：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使用
latex->dvips->进行编译ps2pdf不会产生警告。pdffonts产生：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使用编译
xelatex不会产生警告。pdffonts产生：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
这显然是字体编码问题。因此，切换到拉丁现代fonts （via \usepackage{lmodern}）也通过以下pdffonts输出避免了这个问题：
使用 进行编译
pdflatex，pdffonts生成：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使用
latex->dvips->进行编译ps2pdf，pdffonts生成：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使用 进行编译
xelatex，pdffonts生成：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