【问题标题】:How to make docx file render/load/add and retain all w:LastRenderedPageBreak如何使 docx 文件呈现/加载/添加并保留所有 w:LastRenderedPageBreak
【发布时间】:2021-04-05 22:11:01
【问题描述】:

我目前正在处理 docx 文件,并且我正在使用 w:lastRenderedPageBreak 作为每个页面内容的标记。我有必要确定一个页面是否已经结束。

我现在的代码是这样的:

from docx import Document
document = Document(file)
for p in document.paragraphs:
  if 'lastRenderedPageBreak' in p._element.xml:
     # do something
  # rest of code here

现在我遇到的问题是一个有 4 页的 docx 文件只有 2 个 w:lastRenderedPageBreak 标签。我尝试打开 docx 文件并保存它,但 w:lastRenderedPageBreak 标签没有增加。

w:lastRenderedPageBreak 正确显示分页符的唯一时间是我打开 docx 文件并将其另存为 XML 文件时。

在使用 python-docx 解析文本和格式化时,有什么方法可以跳过另存为 XML 部分以正确查看 lastrenderedpagebreaks?如果可能的话,我想用 python、win32com 或 vba 来做。

编辑: 我想要 w:lastRenderedPageBreak 的原因是在解析内容时处理脚注时遇到问题,因为它们的格式与普通文本相同(源问题且无法修复)。唯一的区别是它们的开头有一个上标数字。这里需要确定页面是否已经结束,因为当前如果脚本不知道页面是否已经结束,它将继续将下一页的文本包含到脚注中,直到找到 w:lastRenderedPageBreak。

例如: 我希望 docx 的 XML 从此改变:

脚注 1:此处为文字。 \p 此处属于脚注 1 的附加文本。 脚注 2:此处为文字。 新页面文本从这里开始...

进入这个:

脚注 1:此处为文字。 \p 此处属于脚注 1 的附加文本。 脚注 2:此处为文字。 新页面文本从这里开始...

所有文本都包含在框架中,因此无需担心页面大小、方向和边距。只要可以在内容或 xml 中标记页面的结尾或新页面的开头,docx 的外观并不重要。

【问题讨论】:

  • 除非您明确输入分页符,否则文档中没有明确的页面。如果文件打印在不同类型的纸张上,例如 A4 与 Letter,页面将会改变。这适用于所有文字处理器,而不仅仅是 Word。如果您打印或显示文档,页面及其内容将在运行时根据介质的大小、边距等进行计算。
  • 另一方面,PDF 既不是可编辑的,也不是文字处理格式。它本质上是打印命令(特别是 Postscript)。如果您尝试在不同的介质上显示或打印 PDF 文件,您将使用相同数量的页面进行拉伸或裁剪以适应介质。这就是为什么在手机上阅读 PDF 文档如此痛苦的原因
  • 忘记添加了,文件中的所有文本都包含在文本框/框架中。我检查了 XML 并且这些框已经有一个 h:x 和 h:y 所以我的文件是以 A4 页面格式还是字母格式打开并不重要。我只想在加载后添加和保留分页符。
  • I just want pagebreaks to be added 然后你必须自己添加。同样,Word 不是 PDF 或桌面发布应用程序。就像 HTML 或 LaTeX 一样,页面是根据媒体和内容动态计算的,而不是相反
  • 脚注不是这样工作的。它们是a special <footnote> element,存储在FootNotes 部分中,并始终显示在 分页后的页脚中。同样,Word 与 LaTex 几乎没有什么不同(除了 part-as-XML 文件...... pat)。您无需知道页面的分页方式即可找到其脚注或其引用。这就是 Word 的目录和脚注、图像列表的工作方式。

标签: python vba docx win32com python-docx


【解决方案1】:

w:lastRenderedPageBreak 有太多限制,无法用作分页指标:

  1. 如果一个文档从未被渲染,则不会有w:lastRenderedPageBreak 元素。

  2. 如果文档在呈现后发生了更改,则现有的 w:lastRenderedPageBreak 元素将过时。

  3. 渲染取决于目标媒体的特性。

  4. 渲染可能取决于换行和分页算法或它们的实现细节。

  5. 即使可以忍受 #1 到 #4 的限制,w:lastRenderedPageBreak 也是 has historically had reliability issues

更多详情,请参阅:

【讨论】:

  • 感谢您的总结。我可以忍受 1-4 并且 #5 中的一些问题已经由我的脚本中的逻辑处理。到目前为止,我还没有在我测试过的文档中看到表格和图像。所有内容都放置在框架中,因此页面大小和边距并不重要,因为我只想知道页面在哪里结束,这样我就可以完善处理内容连续性的当前逻辑。
  • 你接受地面是流沙,但你仍然希望在上面建造。祝你好运。
猜你喜欢
  • 1970-01-01
  • 2014-11-24
  • 2015-09-27
  • 2013-10-08
  • 2015-11-30
  • 1970-01-01
  • 2017-03-13
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多