【场景】套打导出PDF，以图片形式导出PDF
功能描述链接：
[套打导出使用图片方式生成PDF文件](https://wenku.my7c.com/article/378226648006817792?productLineId=1&isKnowledge=2)
【发布补丁】PT-146930（2022-11）
部分场景需要（2023-1）才能实现
【详细说明】
这个功能变通解决了套打历史的一些问题。
老版本下的套打实现，依托于DevExpress第三方控件，在历史的分析处理上，常遇见的一些问题 空格空间过大，换行计算不准导致的文本遮挡、字体不支持的问题
<1>空格空间过大
如模板设计：
导出效果：（换行位置对不齐）
使用选项修正后效果：渲染效果更精准
<2>换行计算不准、渲染异常导致的文本遮挡
如模板设计：
导出的可能场景：（存在字体被吞掉）
使用选项修正后的效果：渲染效果更精准
<3>字体不支持:
目前已知的不支持[微软雅黑.粗体]问题（高版本windows，默认的TTC字体）
套打模板：
导出效果：即使服务器存在此字体，且注册表正常依然无法显示（预览、打印正常，仅导出PDF异常）
使用选项修正后的效果：支持对应字体导出PDF
【实现逻辑】
历史逻辑：如果了解套打的实现逻辑，套打本质上是服务端生成了一套前端样式（WPF的Xaml），而后再不同段进行渲染，导致最终在不同的端上有明显的渲染差异
该方案逻辑：在服务端生成一套前端样式后，在应用服务器下对应K3JobProcess将其转换为图片，而后将每页图片拼接为PDF文件，可以独立于渲染框架和渲染设备，保证生成的效果在所有端显示一致
（这一点同样也是解决预览、打印、导出三套渲染框架的一个变通方案，但是目前仅解决套打导出层面的问题）
【方案带来的影响】
<1>**生成的PDF文件由于使用了图片，会变得比原来大，生成速度比越来稍慢**
<2>**保证渲染效果再服务端可控，更加精准**，为后续三端统一提供可能
<3>后续若支持预览、打印时，需要考虑打印机的打印精度是否会导致锯齿，或者打印更慢的可能（图片和文本打印的区别）
【功能不生效的日志排查】
该功能需要依赖本来K3JobProcess进行转换为图片，每次请求时目前都会记录日记，参考如下：
为啥链接下架了？
<audio controls="controls" style="display: none;">
那么可以聊一聊DevExpress为啥不升级么
