问题：

使用Adobe Reader将一份pdf文件通过我的虚拟打印机输出后（输出的是中间文件，等同于EMF文件），查看的时候发现有时候是乱码。最简单的必现步骤：

1、使用Adobe Reader打开pdf文件，选择我的虚拟打印机打印（取消掉adobe打印高级选项中“作为图像打印”），生成中间文件。

2、此时可以通过工具查看这个中间文件（EMF），发现并没有乱码。

3、关闭刚才打印的Adobe Reader打开的Pdf文件，再次查看中间文件，这时候就乱码了。

分析：

根据上面的必现步骤，再测试使用FoxitReader、JisuPdf打开pdf文件然后选择我的虚拟打印机打印，都没有复现。此外，生成中间文件后，即使重新用Adobe Reader打开pdf，查看中间文件的时候，仍然是乱码。

根据上述现象，去对比使用JisuPdf和Adobe Reader执行打印后生成的中间文件的区别，发现存在比较大的区别。猜测Adobe Reader在打印输出的时候为不存在的字体创建了临时字体文件，所以Adobe Reader在没关闭的时候查看不会乱码，一旦关闭了就删掉了临时文件，所以就乱码了。

比如我第一次输出的是中文文件A，不关闭Adobe Reader，查看A正常。关闭Adobe Reader查看A乱码，再次打开Adobe Reader并打印出B，查看A乱码，B不乱码。由此说明，创建的这个临时字体文件，还是和对应的中间文件相关联的，并不是所有的都一样。

我分别比较上述A和B文件内容上的区别，发现其中一个区别就是EMR_EXTCREATEFONTINDIRECTW结构中的字段不一样，而且有个比较明显的字段内容lfFaceName不一样。

查看MSDN上对EMR_EXTCREATEFONTINDIRECTW的介绍，基本可以确定就是Adobe Reader在打印输出这个pdf文件的时候创建了临时字体文件，所以一旦Adobe Reader进程关闭了，就会删除临时字体文件导致中间文件乱码。这也说明了为什么直接输出到打印机时不会，而通过我的虚拟打印机输出中间文件，如果在同一台机器上不关闭Adobe Reader进程时将中间文件输出到真实打印机不会乱码，而在另一台机器上输出会乱码。

为了确认这个问题，我使用JisuPdf和FoxitReader再分别打印出中间文件C和D。用A和C、A和D比较，发现C和D中都不存在EXTCREATEFONTINDIRECTW这个记录，由此证明以上结论。

也就是说，我这个pdf文件中使用了非内嵌并且系统尚未安装的字体，pdf阅读器在打开的时候使用了相关的字体去替换显示。

进一步分析：

现在问题转变成，为什么Adobe Reader在打印时会调用CreateFontIndirect（生成EXTCREATEFONTINDIRECTW记录），而JisuPdf和FoxitReader却不会？

另外如果生成的EMF中有EXTCREATEFONTINDIRECTW记录，如何根据这个记录创建好需要的字体从而不乱码显示呢？

经过自己解析EMF中的记录进行绘制，发现是可以通过调用CreateFontIndirect函数去实现这条EXTCREATEFONTINDIRECTW记录的，但是仍然是乱码，也就是说无法找到实际能与之匹配上的字体。

解决方案：

问题拖了比较久，最终也没找到好的解决方案，目前采用的办法是对于这种情况，要么直接使用勾选上adobe reader的矢量图打印（这种方式比较万能，原理是将每页文档都转变成一张图片，相应的占据的空间也大，并且慢很多），要么就干脆换一个pdf阅读器，比如国产的foxit。