处理大型词汇表?

处理大型词汇表?

我有包含 20k 个缩写(基因名称)的 1.1MB 文件。我没有在文本中使用所有缩写词,但尝试编译时仍然会收到以下错误消息。我该如何避免这种情况?

(./tex/glossary.tex (./genes.tex
Runaway definition?
->,{A1BG},{A1CF},{A2M},{A2ML1},{A3GALT2},{A4GALT},{A4GNT},{AAAS},{AAC\ETC.
! TeX capacity exceeded, sorry [main memory size=5000000].
\glolist@acronym ...UFB2},{NDUFB3},{NDUFB4},{NDUFB
                                                  5},{NDUFB6},{NDUFB7},{NDUF...
l.10470 ...ssed, developmentally down-regulated 1}

答案1

一种快速而(肮脏的)方法(很可能我重新发明了一些glossaries轮子;-)

思路如下:

  • 重新定义\gls(和其他类似的宏),将使用的宏放入已使用的 gls 条目列表中
  • 将这些值存储到单独的文件中,例如\jobname.used
  • 先读入这些值\loadglsentries,然后重新定义\newacronym,只使用与已存储条目匹配的条目,而忽略其他条目。

\documentclass{article}

\usepackage{xparse}
\usepackage{letltxmacro}
\usepackage{glossaries}

\makeglossaries

\LetLtxMacro\newacronymdefault\newacronym
\LetLtxMacro\glsorigdefault\gls

\newwrite\usedentries
\AtBeginDocument{
  \immediate\openout\usedentries=\jobname.used
}



\newif\ifshrinkglossaryentries

\shrinkglossaryentriestrue

\ExplSyntaxOn

\newcommand{\listofused}[1]{%
  \seq_gset_from_clist:Nn \gls_loaded_seq {#1}
}

\seq_new:N \gls_used_seq 
\seq_new:N \gls_loaded_seq

\ifshrinkglossaryentries

\RenewDocumentCommand{\newacronym}{O{}+m+m+m}{%
  \seq_if_in:NnT \gls_loaded_seq {#2} {%
    \newacronymdefault[#1]{#2}{#3}{#4}%
  }%
}
\fi
\ExplSyntaxOff

\InputIfFileExists{\jobname.used}{}{}


\loadglsentries{genes}

\ExplSyntaxOn
\RenewDocumentCommand{\gls}{+O{}+m}{%
  \glsorigdefault[#1]{#2}%
  \seq_gput_right:Nn \gls_used_seq {#2}
}  

\makeatletter
\AtEndDocument{%
  \immediate\write\usedentries{%
    \string\listofused{\seq_use:Nnnn \gls_used_seq { ,}{,}{}}
  }
  \immediate\closeout\usedentries
}
\makeatother

\ExplSyntaxOff    


\begin{document}

\gls{PIGH}

\gls{ZZZ3}

\printglossaries

\end{document}

答案2

glossaries性能页面使用基础提供的多种不同方法,比较包含 1000 个条目定义的某些文件的文档构建结果glossaries包和glossaries-extra扩展包。特别是,检查按字母顺序排列(子集)部分。这些测试中的文件不如您的文档那么大,但可以查看哪些方法对大型数据集的表现更好。

对于文档中只需要子集的大量条目,最好的方法是glossaries-extra使用bib2gls。这可以节省大量资源,因为只有文档中真正需要的条目才需要存储在 TeX 中。(当然,bib2gls需要足够的内存,但它是一个 Java 应用程序,因此它的内存管理比 TeX 更好。)

相关内容