以PDF格式转换zillion ODT文件的可靠而快速的方法？

Question

我需要从一个带有嵌入字体的简单模板(几页和几个表)预生产一百万或两个PDF文件.通常情况下,我会在这样的情况下保持低水平,并使用像ReportLab这样的库来构建所有内容,但我在项目后期加入了.

目前,我有一个template.odt并在content.xml文件中使用标记来填充数据库中的数据.我可以顺利地创建ODT文件,它们看起来总是很严谨.

对于ODT到PDF的转换,我在服务器模式下使用openoffice(和使用命名管道的PyODConverter),但它不是很可靠:在一批文件中,最终有一个点,之后所有处理过的文件都被转换成垃圾(遍布整个页面的错误字体和字母).

在OOo 2.3和3.2中,在Ubuntu,XP,Server 2003和Windows 7中,问题不可预测地重现(不依赖于数据).我的Heisenbug探测器正在滴答作响.

我试图减少批量的大小并在每个批次之后重新启动OOo; 仍然,一小部分文件搞砸了.

当然我会在Ooo邮件列表上写下这个,但与此同时,我有一个交付,已经失去了太多时间.

我要去哪？

完全避免使用ODT格式并转到另一个模板系统.
- 建议？任何需要几秒钟才能运行的东西都太慢了.OOo需要大约一秒钟,总计15天的处理时间.我不得不编写一个程序,用于将作业聚集在多个客户端上.
保留格式,但转到另一个工具/程序进行转换.
- 哪一个？共享软件或商业存储库中有许多用于Windows的应用程序,但尝试每个应用程序都是一项艰巨的任务.有些太慢,有些不能先批量运行,有些不能从命令行等工作.
- 开源工具往往不会重新发明轮子,往往依赖于openoffice.
转换为中间.DOC格式可以帮助避免OOo错误,但它会使处理时间加倍并使已经太毛茸茸的任务复杂化.
尝试生成两次PDF并进行比较,如果出现问题则丢弃整批.
- 虽然文档看起来相同,但我知道无法比较二进制内容.
处理完每个文档后重新启动OOo.
- 生产它们需要花费更多的时间
- 它会降低错误文件的百分比,并且很难识别它们.
转到ReportLab并以编程方式重新创建页面.这是我将在几分钟内尝试的方法.
学习正确格式化项目符号列表

非常感谢.

编辑:好像我根本不能使用ReportLab,它不会让我嵌入字体.我的字体有TrueType和OpenType版本.

TrueType表示"TTFError:字体不允许子集化/嵌入(0100)".

OpenType版本说"不支持TTFError [...] postscript轮廓".

非常非常好笑.

Answer 1

我可能最终会找到某种方法来确定批处理何时失控，然后重新处理失败前不久的所有内容。如何判断它何时失控？这需要分析一些正确的 PDF 和一些失败的 PDF，以寻找它们之间的相似之处：

我怀疑将它们转换回文本并查找预期的字符串将是最准确的解决方案，但也很慢。如果对每个文件运行速度太慢，请每隔 1/100 左右运行一次，然后在最后一个已知的正确文件之后重新转换每个文件。