感谢@zeroth的不懈努力,我让TikZ的外部化得以运行todonotes
,TikZ图像由环境和宏以及我的自制编译脚本拼凑在一起。特别是,我不使用-shell-escape
外部作业,而是“手动”运行外部作业(更适合输出流收集)。
在我的序言中,我
\usepackage{tikz, pgfplots}
\usetikzlibrary{external}
\tikzexternalize
\tikzset{external/mode=list and make}%
\tikzset{external/export=false}%
并且external/export
针对单个图像启用。没有其他显式(全局)TikZ 设置,不包括样式定义。
但结果却令人警醒:构建时间约为加倍!
显然,翻译这些图像本身就是方式比仅仅将它们作为主文件的一部分进行翻译更昂贵。当然,pdflatex
调用 2 到 n(在我的情况下是 5)要快得多,但这似乎并没有抵消开销。观察到的文档包含大约 40 张图像,大多数图(pgfplots
++gnuplot
数据文件)。
如果第一次构建花了那么长时间,我可以忍受。但是,tikz/external
它显然不会检查图像自上次构建以来是否发生了变化;它总是创建一个完整的图像.figlist
,而我(这是我的保守脚本)必须重建所有图像。
当然,我可以检查每个图形是否有合适的 PDF,如果存在则不重建。但是,这会导致图像的更改被忽略,直到以某种方式强制重建。
我看不到任何有用的辅助输出,我(我的脚本)可以使用它们来检查图像是否已更改。因此我的问题是:
有没有办法
- 强制 TikZ 检查仍然有效的外部化结果或
- 从外部检测是否需要重新运行 TikZ 外部化作业?
答案1
我担心external
TikZ 的库处理的用例与我在这里理解的稍有不同。
该external
库的构建考虑了以下假设/要求:
允许图像外部化而不改变原始 TeX 文档(除了对序言的非侵入性更改)
一旦图像被外部化,它就被视为静态的,并且外部图像可以重复使用多次。
因此,当且仅当满足(2.)时,才可以节省时间。如果(2.)满足,外部库将要减少时间。
但是,从您的评论中我了解到,您每次构建时都会重新计算每个图形。在这种情况下,该external
库会“遭受”其要求 (1.) 和 pdftex 的“缺失功能”:为了创建一个外部图像,它必须处理主文件.tex
(并丢弃不属于图片的所有内容)。
虽然“丢弃不属于图片的所有内容”可以进行一些优化,从而显着减少编译时间(例如丢弃所有非封闭tikzpictures
和所有非封闭的语句),但预期的行为是使用外部图片\includegraphics
创建每张图片+主文件的总运行时间.tex
增加.tex
与完全不进行外部化处理的主文件相比。
两个因素是不幸的,但对于一份巨大的文档来说可能会发生。
以下是我对解决该问题的建议:
解决方案 1
考虑使用standalone
-package 而不是 TikZ external
lib。它也会导致图像被外部化,但它没有要求 (1.),因此导致开销大大减少。它可能更接近您当前所做的。
解决方案 2 考虑更改您的最新检查。每次运行构建时,真的有必要重新创建每个外部图形吗?为什么有必要?是否可以以牺牲可靠性为代价来放宽标准?
换句话说:尝试满足假设(2):一旦大多数图像确实是静态的,您将节省大量时间。
为了获得可靠的解决方案,您仍然应该在最终发布之前重新运行整个过程.pdf
。根据图片的类型,您甚至可能希望external
在最终运行中完全禁用库(如果您在图片中使用动态内容,如clickable
库pgfplots
)。
解决方案 3
您可以接受该库不适合您当前的用例,并通过定制其优化功能(即减少确定可以安全跳过external
主文件的哪些部分的时间)来解决其弱点。.tex