首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >可靠和快速的方式来转换一个成千上万的ODT文件在PDF?

可靠和快速的方式来转换一个成千上万的ODT文件在PDF?
EN

Stack Overflow用户
提问于 2010-05-25 10:24:40
回答 5查看 2.6K关注 0票数 6

我需要预先生成一百万或两个PDF文件从一个简单的模板(几页和表格)与嵌入式字体。通常,在这种情况下,我会保持较低的水平,并使用像ReportLab这样的库编写所有东西,但我后来加入了这个项目。

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

对于ODT到PDF的转换,我在服务器模式(以及PyODConverter w/命名管道)中使用openoffice,但它不是很可靠:在一批文档中,最终会有一个点将所有处理过的文件转换为垃圾(页面上到处都是错误的字体和字母)。

问题不是可以预测的(不依赖于数据),出现在Ubuntu、XP、Server 2003和Windows7中的OOo 2.3和3.2中。我的Heisenbug检测器正在滴答作响。

我试图缩小批处理的大小,并在每个批之后重新启动OOo;但是,有一小部分文档被搞砸了。

当然,我会在Ooo邮件列表上写到这一点,但与此同时,我已经有了一次送货,而且已经浪费了太多的时间。

我该去哪?

  1. 完全避免ODT格式,转而使用另一个模板系统。
代码语言:javascript
复制
- Suggestions? Anything that takes a few seconds to run is way too slow. OOo takes around a second and it sums to 15 days of processing time. I had to write a program for clustering the jobs over several clients.

  1. 保留格式,但选择另一个工具/程序进行转换。
代码语言:javascript
复制
- Which one? There are many apps in the shareware or commercial repositories for windows, but trying each one is a daunting task. Some are too slow, some cannot be run in batch without buying it first, some cannot work from command line, etc.
- Open source tools tend not to reinvent the wheel and often depend on openoffice.

  1. 转换为中间.DOC格式可能有助于避免OOo错误,但它将使处理时间增加一倍,并使已经太多毛的任务复杂化。
  2. 试着生产两次PDF并比较它们,如果有什么问题就丢弃整个批。
代码语言:javascript
复制
- Although the documents look equal, I know of no way to compare the binary content.

  1. 处理每个文档后重新启动OOo。
代码语言:javascript
复制
- it would take a lot more time to produce them
- it would lower the percentage of the wrong files, and make it very hard to identify them.

  1. 选择ReportLab并以编程方式重新创建页面。这就是我几分钟后要尝试的方法。
  2. 学习正确格式化项目列表

非常感谢。

编辑:看起来我根本不能使用ReportLab,它不允许我嵌入字体。我的字体有TrueType和OpenType版本。

TrueType one写着"TTFError: TTFError不允许子设置/嵌入(0100)“。

OpenType版本说“TTFError. postscript大纲不受支持”。

非常有趣。

EN

回答 5

Stack Overflow用户

回答已采纳

发布于 2010-05-25 13:27:05

我可能最终会找到某种方法来确定批处理何时发生混乱,然后在它失败之前不久重新处理所有的东西。如何确定何时进行混乱?这将需要分析一些正确的PDF和一些失败的PDF,以寻找它们之间的相似之处:

  • 生成的文件与它们的源代码相比大小不合适
  • 这些文件不包含某些字符串(比如字体的名称)
  • 一些数据并不在预期的位置。
  • 当转换回文本时,它们不包含模板中的预期数据
  • 当转换成位图时,文本不在正确的位置

我怀疑将它们转换回文本并寻找预期的字符串将是最精确的解决方案,但也很慢。如果在每个文件上运行太慢,那么每隔1/100次左右运行一次,然后在最后一个已知的好文件之后重新转换每个文件。

票数 2
EN

Stack Overflow用户

发布于 2010-05-26 18:56:09

对于创建如此庞大的PDF文件,OpenOffice似乎是错误的产品。您应该使用一个真正的报告解决方案,它是为创建大量PDF文件而优化的。有很多不同的工具。我会推荐I-净结算报告 (以前被称为i水晶清除)。

  • 我希望一个PDF文件的创建速度更快,就像使用OpenOfice一样。
  • 创建2个PDF文件和比较它将花费很大的速度。
  • 它可以嵌入真正的字体。
  • 有了API,您可以在循环中工作。
  • 有试用证,你可以在批次上工作90天。

缺点是必须重新启动开发。

票数 3
EN

Stack Overflow用户

发布于 2010-05-25 10:31:01

对于您的场景来说,Reportlab +似乎是一个很好的选择,包括模板和电话支持,可以让您快速运行。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/2903774

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档