我想知道是否可以缩写序言中的一组命令?例如,是否可以给出一行代码将命令从 \documentclass 缩写为 \usepackage{}?具体来说,是否可以编写类似“\setpreamble”的代码来代表命令“\documentclass{article}”和“\usepackage{amsmath}”。
答案1
TeX 和 LaTeX 提供了多种不同的机制来实现这种功能。您可以或应该使用哪种机制取决于多种不同的考虑因素。
命令?在理论你可以定义一个宏来加载包等等。所以这个“有效”:
\def\myspecialcommand{\documentclass{article}\usepackage{amsmath}} \myspecialcommand
但这是一个非常糟糕的想法。它不仅是非标准的和不可移植的:而且它甚至没有真正实现任何东西,因为您仍然必须定义命令,并且定义占用的空间与命令一样多!
\input{}
? 您可以拥有一个包含序言的文件,并将\input
该文件放在适当的位置(甚至可以作为文档文件中的第一件事)。这不是这样的一个坏主意。它的优点是您可以保留“标准”序言,对它的更正将传播到使用它的任何文档,并且它节省了输入。它的主要缺点是没有人(包括您!)可以在没有关键序言文件的情况下编译文档。并且\input
在这种情况下,它几乎无法提供有关此文件可能包含什么的线索 --- 甚至需要什么文档类。编写自己的类文件? 文件的全部意义
.cls
在于使设计者能够组合出一个普遍可用的模板。类文件可以从基本文件继承,可以用来\RequirePackage
添加任何必要的包,可以根据自己的喜好调整字体、纸张大小等等。但是,对于纯粹的个人使用,它具有许多相同的缺点\input
:它提供了第三方(或你如果您丢失了该.cls
文件!),则可能会出现黑匣子,如果无法访问该文件,则很难或无法编译文档。写出你自己的风格? 您可以对个人
.sty
文件执行类似操作。加载大量包的个人样式实际上与个人类文件存在所有相同的问题。包含您经常使用和定义的特定宏的个人样式文件可能更合法。虽然如果文件.sty
丢失,将无法编译文档,但重建(或多或少精确地)此类宏通常更容易,因为它们的上下文通常会告诉您它们试图做什么。使用
config
您经常加载的各种包的设施?相当多的软件包,尤其是“大型”软件包,将允许您设置和读取某种配置文件,以节省您在编写的每个文档中输入选项的时间。例如,biblatex
提供biblatex.cfg
设置全局书目选项;或者 KOMA-Script 的信件类提供.lco
文件来设置信件的各种基本数据。这些设施的主要缺点与其他任何以不可见方式设置非默认值的设施相同(就主文件而言):如果有人没有您的配置文件,他们就无法重现您的工作。但根据文档的不同,这可能不是一个大问题。它的主要优点是它确保了跨文档的一致性你的文档,而不需要您记住一些可能相当繁琐的选项,也不会过度扰乱您的实际文档。“模板”又名剪切和粘贴。最后一个选择在某种程度上是最简单的:保留某种模板文档,然后通过将其物理复制到新文档中来开始工作。如果您对简单的剪切粘贴或重命名这种原始技术感到犹豫,您可以使用提供模板、片段或其他内容的编辑器。
这种方法的主要优点是简单,并且生成的文档(最终)100% 可移植:您只需将活动文件发送给某人,他们就可以精确排版您的文档。主要缺点是很容易出现不同步的情况。在排版一份文档时,您发现并更正了模板中的错误。但您记得更正模板吗?您是否需要返回并更正使用相同模板的所有其他文档?使用其他方法,此类更改会自动向外传播;使用“模板”可能会让您陷入混乱。
编辑添加正如 Au101 在评论中指出的那样,模板的另一个缺点是它们可能会变成垃圾箱,您将任何可能用到的包都添加到其中。除了冒犯那些头脑整洁、资源密集的人之外,这还会导致包冲突和混乱。即使您使用模板作为起点,考虑特定文档的实际需求量,并注释模板以帮助您做到这一点也是很好的做法。
那么你应该怎么做呢?没有一劳永逸的解决方案。我的自己的看法:
如果您的文档是或可能提供给其他人(作为源代码),尤其是合作者,请使其自成体系并符合标准。在大型项目中,可以将项目分成多个部分和/
\input
或\include
多个文件(实际上,这是一种良好做法,大型项目必然包含多个文件,例如.bib
文件):但所有内容都应构成单个集合的一部分,并进行组织,以便可以轻松地将它们捆绑在一起而不会出现任何无意的遗漏。例如,在单个目录或目录结构中。基本上,任何项目都是如此你想要长期维护。您可能确信在更换笔记本电脑时不会忘记将
localtexmf
树复制到新机器上。也许您不会。但不要冒险。对于个人项目,您有更多回旋余地。但在这些情况下,请尝试在序言中包含标准包加载及其选项(例如作为模板)。如果您对其宏进行个人修改(例如重新定义它们),或者如果您有自己的宏定义库,则将它们作为单独的文件进行维护会更有益处,因为它们可能会有缺陷,而且您可能会随着时间的推移开发它们,最好确保更改能够正确传播。
就我自己而言,我不会写我的自己的班级除非我实际上有一种独特的文档类型,我希望其他人和我都能使用。我宁愿坚持使用模板。但其他人持不同观点:拥有自己的类文件当然没有错。这是他们存在的原因之一。我更愿意编写一个个人
.sty
文件来包含宏定义,即使是特殊的宏定义,我发现它经常很有用。无论哪种情况,都要非常小心地安全地保存相关文件(备份、版本控制等)。一般来说,没有理由不在文件中放置一个实际的、可读的序言,其中包括
\documentclass
(及其所有选项)和您加载的每个包\usepackage
(及其所有选项)。如果您确实加载了个人样式文件,模板也应该对此进行注释。只需片刻就可以拥有一个模板,将该文本吐入您要创建的任何新文档中。使用\input
及其同类来代替它通常是一个坏主意,因为它为您节省了一些字符,但却以牺牲将来对其他人和您自己的清晰度为代价。