【问题标题】:Replace words/phrases in existing PDF or docx with other words将现有 PDF 或 docx 中的单词/短语替换为其他单词
【发布时间】:2018-04-11 10:45:39
【问题描述】:

我正在尝试将动态 PDF 生成器作为 .NET Core API。我想获取现有的 PDF 或 .docx 文件并对其进行编辑,以便将当前名称 (John Doe) 替换为可以替换的名称,例如 #NAME_PLACEHOLDER

然后我想转换#NAME_PLACEHOLDER -> John Doe(或KeyValuePairDictionary<string, string> 中的任何内容)。

我在 Docker 环境中运行它,所以我可以轻松执行命令,我也愿意这样做。

到目前为止,我已经尝试了一些事情:

  • 1) pdf2htmlEX
    • pdf2htmlEX file.pdf 执行
    • 做得很好
    • 可以使用 Google Chrome 无头或类似工具转换回 PDF
    • 问题:只有PDF中使用的字符可以用来替换。所以如果我只使用A, B, C 作为字符,它会将D 变成Times New Roman(或默认字体)
  • 2) LibreOffice ODT 转 PDF
    • 这很好,因为我可以简单地解压缩 .odt 文件,打开 content.xml,搜索并替换,然后再次将其保存为 .odt 文件
    • 可以使用soffice --convert-to pdf 轻松转换为 PDF
    • LibreOffice 很不错
    • 问题 1:Microsoft Word -> 另存为 ODT 往往会破坏格式,因此我们必须使用 LibreOffice 将其重新改回
    • 问题 2:我们不想放弃 Microsoft 的 Office 套件
  • 3) 使用 Chrome Headless 将 HTML 转为 PDF
    • 所见即所得
    • 目前为止最好的选择,如果我们都是开发人员 aa 并且有无限的时间
    • 问题 1:只有我们的开发人员可以进行更改,因为我们的营销部门不懂 HTML
    • 问题 2:我们现有的 PDF 必须用 HTML 重写

如您所见,我已经尝试了很多方法。除了 Chrome Headless,它们都没有达到我的期望。我真正喜欢#3 的是所见即所得。我可以在 HTML 中制作整个内容,按 CTRL+P 并查看它作为完成的 PDF 的样子,基本上。

不过,我正在寻找更好的解决方案。它可以支付。它可以是免费的。我所需要的只是动态地用其他词改变单词/短语,这显然是一件很难做到的事情。

【问题讨论】:

  • “我所需要的只是……这显然是一件很难做到的事情”,这几乎可以概括。
  • @usr2564301 如果我能找到一个好的 docx 到 PDF 转换器,我可以轻松地完成这一切。然后我可以简单地编辑 docx 文件的内容(解压缩并再次压缩),然后将其转换为 PDF。唯一的问题是:看起来,付费选项实际上是每月 1000 美元以上。我愿意购买终身许可证,但不是每月 1000 美元以上的废话。

标签: pdf .net-core pdf-generation libreoffice google-chrome-headless


【解决方案1】:

感谢您清楚地说明您已经找到的内容。提供简洁的答案很有帮助。

转换总是很棘手 - 我确定您知道 Word 本身无法显示/编辑某些 Word 文档。

我有关于第 2 点“LibreOffice ODT 到 PDF”的经验,可以提出一些测试建议:

  1. 不要使用微软做 docx->odt 转换。如你所知,这并不好。使用 LibreOffice 本身来执行此步骤。您的其余流程保持不变。
  2. 对于某些文档,Libre Office 的 doc->odt 效果要好得多。因此,您可以改为使用 DOC 格式并获得更好的结果,而无需进行任何其他更改。
  3. 您无法从流程中移除开发人员,但您当然可以减少他们的角色,让您的业务/营销团队获得更直接的意见,只需:

    • 将起点文档提供给开发人员以运行转换过程。开发人员可以“清理”文档以使其转换良好。
    • 将此版本的文档作为“官方”起点。业务或技术团队可以加载、调整它,然后将其放回流程中。
    • 如果可能,向业务团队公开一个测试平台,以便他们可以下载、调整、上传和呈现为 PDF。这个循环意味着他们将能够取得更多成就,如果他们表现出色,无需任何开发人员投入就可以做出令人印象深刻的事情。
    • 上述步骤只是意味着不要期望完美转换任意复杂的文档。从(甚至是复杂的)工作基线开始非常棒。

其中一些可能会告诉您,您的 #2 实际上会获得最佳的整体结果。

希望对你有帮助。

【讨论】:

  • 非常感谢您的意见!使用 LibreOffice 的问题之一是,业务团队不想离开 Word。如果我们都使用 LibreOffice,这将是显而易见的。你会说这样更好吗: 1)在 Word 中制作文档并另存为 docx。 2) 使用 soffice 命令将 docx 转换为 odt。 3) 编辑 odt 文件并保存(全部可编程)。 4) 使用 soffice 命令将 odt 转换为 pdf。我们现在的替代方案是 Acrobat + PDF 表单输入,但是对于文档的每次迭代,我们都需要编辑原始文档并再次插入所有输入。繁琐的过程。
  • 不客气。当然,如果您的团队习惯使用 MS Office,那么显然他们应该坚持使用 MS Office。所以“是”是我对你问题的回答。业务/开发人员始终使用 MS Office 文档,您的应用程序使用 Libre Office 将其转换为 PDF。您可以在 DOCX 或 ODT 阶段进行编程操作 - 适合您的环境。请记住上面我的回答 3. 下的第一点 - 让开发团队(您自己)创建 DocX 的第一个基线,因为您知道它将通过 Libre Office 很好地转换。
  • 所以我尝试使用soffice 来转换我的 docx -> odt -> pdf。它确实有效,而且看起来不错,但它没有做两件事:在标题中右对齐文本(使用TAB 在左侧、中心和右侧之间进行制表符)并将其中一个图像放在中心的表格中而不是向右(3 列和中心列是空的,但现在它有一个图像)。但是,当我在 LibreOffice 的桌面应用程序中打开 docx 时,它也会出现图像错误。
  • 并非所有可能的布局都实现了 100% 的转换,但大多数问题都可以通过对文档进行少量更改来解决。完成后,您就拥有了良好的基准版本。
猜你喜欢
  • 2022-11-06
  • 2014-04-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-05-16
相关资源
最近更新 更多