![这是几何问题还是 pgfpages 错误?](https://linux22.com/image/423091/%E8%BF%99%E6%98%AF%E5%87%A0%E4%BD%95%E9%97%AE%E9%A2%98%E8%BF%98%E6%98%AF%20pgfpages%20%E9%94%99%E8%AF%AF%EF%BC%9F.png)
\usepackage[showframe]{geometry}
在 pgfpages 布局中插入会2 on 1
产生意外结果。我上周更新了 latex,之前没有出现过这个问题
\documentclass{article}
\usepackage{lipsum}
\usepackage[showframe]{geometry}
\usepackage{pgfpages}
\pgfpagesuselayout{2 on 1}[a4paper,border shrink=5mm,landscape]
\begin{document}
\lipsum[1-5]
\newpage
\lipsum[1-5]
\end{document}
这是更新之前的样子。
答案1
这个问题已通过添加修复程序firstaid
(作为 LaTeX 格式的一部分)暂时解决。此修复程序已发送给 CTAN,因此它应该会在今天或明天到达主要发行版,从那时起应该会像以前一样再次工作。
正如@AndrewStacey 所观察到的,内核需要提供一个接口,以便在页面构建的最后阶段、在将其发送到 dvi/pdf 文件之前接管控制权,因为应用程序想要pgfmorepages
进一步控制这个阶段发生的事情(而不是简单地将页面发送出去)。
然而,这不能通过新的钩子管理的“钩子”来完成,因为这不是添加额外的代码(其中几个包可以添加代码,唯一需要解决的问题是按照什么顺序),而是改变过程,并且只有一个过程可以执行。
这里的模型必须是这样一个模型:一个进程可以替换为另一个进程,但只有一个进程始终处于活动状态。我对此的临时术语是“配置点”,我们目前正在努力解决该接口和概念。一旦可用,我们将与软件包维护人员合作如何应用它们,然后取出当前的“急救”。
答案2
这不是答案,而是问题的描述。我确信这个问题很快就会得到妥善解决。
pgfpages
它(以及它的扩展,我坚持认为)的工作方式pgfmorepages
是对 LaTeX 说,“你构建全部的按照你想要的方式进行分页,然后就在之前你把它运出去,我会把它拿去存起来,以后再考虑。”然后过了一会儿,他们说:“好的,现在我要你把它运出去确切地这一页。”。
从该描述中,希望可以清楚地看出pgf[more]pages
需要在最后一刻中断发货程序。页面需要完整,包括页眉和页脚、背景和边框。
从探索latex.ltx
,我发现 LaTeX 团队一直在幕后努力简化 LaTeX 核心。其中一部分包括钩子在各个点允许包裹钩住以比以前更有序的方式重新定义各种例程。我猜这样做的目的是为了解决所有试图重新定义相同命令、环境或例程的冲突包造成的混乱。
因此,对于 shipout 例程,新的 LaTeX 内核在发出新页面时添加了自己的代码,该代码提供了对所有这些钩子的访问。顺便说一下,其中一个钩子用于geometry
将框架放在页面周围(geometry
不知道这 - 感谢 LaTeX 团队的神奇能力,很多软件包应该只是工作无需修改)。
因此,目前我们有一个竞争条件,即 LaTeX 和pgf[more]pages
都试图将其代码插入到 shipout 例程中,并且都通过替换\shipout
其代码来工作。应该会发生的情况是 LaTeX 的代码先起作用,然后pgf[more]pages
第二个起作用。不幸的是,由于 LaTeX 在 之前加载pgf[more]pages
,因此实际上会发生的情况是pgf[more]pages
先执行,然后执行 LaTeX 代码。这意味着 这样的代码geometry
仅showframes
在页面加载时执行实际上发货时未pgf[more]pages
存储页面。这就是框架不正确的原因。
似乎需要的是“发货前”挂钩,以便pgf[more]pages
在最后一刻介入。目前尚不存在,但从 LaTeX 团队的评论来看,他们似乎已经意识到了这个问题,并将很快解决它。