itextpdf停止正确转换pdf [英] Itextpdf stop transform pdf correctly

问题描述

我下一个关于itextpdf的问题.

I have a next issue with itextpdf.

private void generatePdf() throws Exception {
    FileOutputStream fos = null;
    try {
        PdfReader reader = new PdfReader("template.pdf");
        fos = new FileOutputStream("test.pdf");
        PdfStamper stamper = new PdfStamper(reader, fos);

        stamper.close();
    } catch (Exception e) {
        throw e;
    } finally {
        if (fos != null) {
            try {
                fos.close();
            } catch (IOException e) {
                throw new Exception(e);
            }
        }
    }
}

此方法必须读取模板并将其保存到新的pdf中.但是，如果我查看结果pdf，我只会看到空白页(4-与模板数量相同). 有趣的是，在jboss服务器上的Web应用程序上下文中调用了此方法.但是，当我像简单的Java应用程序中的main方法(带有main()方法的Class)一样调用此方法时，它可以正常工作. 我还能补充一点，模板具有将来必须填写的可编辑字段，但现在没有任何编辑. 有人可以假设这里有什么问题吗?

This method have to read a template and save that to a new pdf. But if I looked into a result pdf I just see blank pages (4 - the same amount as a template has). What interesting that this method is invoked in a context of web app on jboss server. But when I invoke this method like main method in simple java application (Class with main() method) it works fine. Also what can I add that the template has editable fields that have to be filled in future but nothing edits now. Can anybody assume what can be wrong here?

最好的问候， 谢尔盖

推荐答案

原因

在评论中，事实证明OP在maven中创建了他的Web应用程序，template.pdf文件作为maven资源提供，并且激活了对资源的过滤(即，文本变量替换).

The cause

In comments it turned out that the OP creates his web application in maven, that the template.pdf file is supplied as a maven resource, and that filtering (i.e. text variable replacements) of the resources is activated.

但是，不幸的是，过滤资源意味着将资源文件视为最终使用UTF-8字符编码存储的文本文件.

Unfortunately, though, filtering resources implies that the resource files are treated as text files eventually stored using UTF-8 character encoding.

这实际上破坏了所有压缩流内容(尤其是页面内容和字体程序)和一些元信息字符串，并且还使交叉引用不正确(写为UTF-8引入了其他偏移偏移量的字节).

This essentially destroyed all compressed stream contents (especially page contents and font programs) and some meta information strings, and also rendered the cross references incorrect (writing as UTF-8 introduced additional bytes which shifted offsets).

在为损坏的文件创建交叉引用表之后，iText仍可以读取PDF，因为在这些流和字符串之外，结构仍然正确.因此，写入读取后的损坏的PDF包含正确数量的页面和某些表单字段，但是页面内容丢失了.

iText could still read the PDF after creating a cross reference table for the mangled file because outside those streams and strings the structure was still correct. The result of writing the read mangled PDF, therefore, contained the right number of pages and some form fields, but the page contents were lost.

解决方案是不过滤PDF资源.例如如此处所述进行操作网站:

The solution is to not filter PDF resources. This can e.g. be done as explained here on the Apache Maven site:

默认情况下，带有扩展名(jpg，jpeg，gif，bmp和png)的文件将不再被过滤.

By default, files with extensions (jpg, jpeg, gif, bmp and png) won't be filtered anymore.

用户可以添加一些额外的文件扩展名，以使用以下配置不应用过滤:

Users can add some extra file extensions to not apply filtering with the following configuration :

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <version>2.7</version>
        <configuration>
          ...
          <nonFilteredFileExtensions>
            <nonFilteredFileExtension>pdf</nonFilteredFileExtension>
            <nonFilteredFileExtension>swf</nonFilteredFileExtension>
          </nonFilteredFileExtensions>
          ...
        </configuration>
      </plugin>
    </plugins>
    ...
  </build>
  ...
</project>

这篇关于itextpdf停止正确转换pdf的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！