从你描述的场景来看，这绝对是Crystal Reports那些“隐性环境依赖”导致的经典问题——明明代码、报表、Runtime版本全一致，结果不同机器上渲染结果天差地别。结合你的排查情况，我整理几个最可能的成因：

1. 系统DPI/屏幕缩放设置不一致 #

Crystal Reports的页面渲染非常依赖系统的显示缩放比例，哪怕都是64位系统，只要某台机器（比如你的开发/验收服务器）设置了非100%的DPI缩放（比如125%、150%），就会导致报表元素的实际渲染尺寸和设计时的厘米值不匹配。

举个例子：你设计时详细节高度是10cm，在100%缩放的机器上，这个高度对应的实际像素占用更小，刚好能在横向A4的可打印区域里放下两个；而本地/生产服务器如果是125%缩放，10cm的实际像素占用会被放大，一页只能容纳一个，完全符合你遇到的现象。当你把高度调到11cm时，缩放后的尺寸超过了100%缩放机器的可打印区域，就触发了页面尺寸不足的报错。

2. 虚拟打印机的默认纸张/边距设置隐性差异 #

你说所有机器默认打印机都是Microsoft Print To PDF，但这个虚拟打印机的默认配置可能在不同机器上被修改过：

• 比如有的机器默认纸张是A4横向，但边距设置不同（比如本地边距是1cm上下，服务器边距是0）；
• 甚至有些服务器可能被设置了自定义纸张尺寸，导致可打印区域的高度比其他机器大。

Crystal Reports在渲染PDF时，会优先使用默认打印机的纸张尺寸和可打印区域来计算页面布局，哪怕你报表里设置了固定页面尺寸，要是打印机的可打印区域和报表设置不匹配，就会出现“能放下2个”或者“页面不够大”的报错。

3. 打印服务(Print Spooler)的上下文缓存或配置差异 #

哪怕你移除了Remote Desktop Easy Print驱动，Print Spooler服务可能还残留了之前的打印机配置缓存。不同服务器上的Print Spooler状态、权限或者残留配置不同，会导致Crystal Reports获取的打印机上下文不一致——CR在计算页面元素位置和高度时，会依赖这个上下文来做尺寸转换。

比如某台服务器的Print Spooler服务曾经异常重启过，或者残留了其他打印机的配置信息，就可能让CR错误地计算了可打印区域的高度。

4. CR Runtime的注册/安装细节差异 #

虽然你说所有机器都是13.0.20.2399版本的64位Runtime，但安装过程中的细节可能不同：

• 比如本地是用管理员权限安装，而服务器是用普通用户权限，导致某些组件没有正确注册；
• 或者注册表中某些深层的渲染配置键值有差异——你可能对比了表面的键，但像HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Crystal Reports\Export\PDF下的页面缩放设置，或者PageSettings相关的键值，可能没注意到；
• 另外，64位系统下，CR可能同时加载32位的某些组件（如果之前安装过32位Runtime残留），导致渲染逻辑不一致。

排查建议 #

针对这些可能，你可以试试：

• 把所有机器的DPI缩放强制设置为100%，重启后再测试报表；
• 打开所有机器的Microsoft Print To PDF属性，检查纸张尺寸（确保都是A4横向）、边距（统一设置为相同值，比如上下各0.5cm），然后重置打印机为默认；
• 在有问题的服务器上重启Print Spooler服务，甚至删除所有打印机后重新添加Microsoft Print To PDF；
• 导出本地和服务器的CR相关注册表项，用对比工具（比如WinMerge）找出差异；
• 直接在服务器上用Crystal Reports XI打开报表，预览看详细节的实际高度和页面可打印区域的关系，看是否和本地一致。

内容的提问来源于stack exchange，提问作者Hispeedbunny