☰

在 LuaTeX 和 XeTeX 中使用 newtxtext 或 babel 之类的包可以吗？

tag-icon • tag-icon fonts xetex luatex spanish
在 LuaTeX 和 XeTeX 中使用 newtxtext 或 babel 之类的包可以吗？

我通常使用newtxtext来处理大多数文档，但我正在尝试从 pdfLaTeX 切换到 XeTeX。Unicode 字符 ¿ 和 ¡newtxtext在 LuaTex 和 XeTeX 上使用时会显示为 £ 和 ą，所以我fontspec现在就使用。请注意，如果我使用标准命令（如）输入字符，则不会发生这种情况\textquestiondown。我认为这只是与新引擎的某种不兼容，尽管我还没有在任何地方读到它们不应该在这些引擎中使用。

[1]

polyglossia同样，我也遵循使用而不是的做法，babel因为我读过polyglossia被设计为babelXeTeX 中的后继者，但是有什么真正的理由不继续使用babel新引擎吗？为什么同一个任务会有两个大包裹？

值得庆幸的是，我怀疑我会遇到由西班牙语本地化引起的任何大问题或不兼容性，因为它只是 TeX 中已经支持的带有变音符号的拉丁文字，但我可以想象 CJK 语言更容易出现这样的问题。

newtxtext在 XeTeX 或 LuaTeX 上无法正常工作的小示例：

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{newtxtext}
\begin{document}
«¡¿Por—qué?!»

\guillemotleft\textexclamdown\textquestiondown{}Por---qu\'e?!\guillemotright
\end{document}

答案1

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{newtxtext}

永远不要与 xetex 或 luatex 一起使用，[T1]{fontenc}这指定您要使用旧版 tex 特定的 8 位字体编码，因此几乎取消了 xetex 的所有 Unicode 支持。即使字符看起来正确，对于任何非 ASCII 文本，您都会得到不正确的字符（如您所见）和不正确的连字符。

[utf8]{inputenc}除了发出不应使用的警告外，在 luatex 或 xetex 中不执行任何操作。

newtxtext不应使用诸如 most 之类的字体包，因为 pdflatex 的 most 字体包正在设置已在 T1 等编码中为 TeX 重新编码的字体，但有些可以使用，因为它们检测 TU（unicode0 编码并加载字体的 Unicode（通常是 OpenType）版本。正如我刚刚注意到 moewe 在评论中所说的那样，使用 TeXGyre Termes viafontspec可以有效地为您提供 textext 字体所基于的 OpenType 基础字体。

babel很好，polyglossia是作为替代方案开发的，babel但目前babel维护得更积极，因此请尝试两者，看看您更喜欢哪一个。

答案2

为了解释为什么输出不同，请考虑这个例子，仅使用¿。

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\begin{document}

\tracingmacros1
¿
\tracingmacros0

\showoutput
\end{document}

如果你使用 XeLaTeX 进行编译，日志中不会出现任何宏扩展的痕迹。并且\showoutput包含一行

....\T1/lmr/m/n/10 ¿

如果您使用 PDFLaTeX 进行编译，则日志包含此内容（如下所述，在这种情况下，日志文件被 Emacs 视为 iso-latin-1 编码并按此方式解码，但此处粘贴的是 utf-8 编码转换）

Â->\UTFviii@two@octets Â

\UTFviii@two@octets #1#2->\expandafter \UTFviii@defined \csname u8:#1\string #2
\endcsname 
#1<-Â
#2<-¿

\UTFviii@defined #1->\ifx #1\relax \if \relax \expandafter \UTFviii@checkseq \s
tring #1\relax \relax \UTFviii@undefined@err {#1}\else \PackageError {inputenc}
{Invalid UTF-8 byte sequence}\UTFviii@invalid@help \fi \else \expandafter #1\fi

#1<-\u8:¿ 

\u8:¿ ->\IeC {\textquestiondown }

\IeC ->\ifx \protect \@typeset@protect \expandafter \@firstofone \else \noexpan
d \IeC \fi 

\@firstofone #1->#1
#1<-\textquestiondown 

\textquestiondown ->\T1-cmd \textquestiondown \T1\textquestiondown 

\T1-cmd #1->\ifx \protect \@typeset@protect \@inmathwarn #1\else \noexpand #1\e
xpandafter \@gobble \fi 
#1<-\textquestiondown 

\@inmathwarn #1->\ifmmode \@latex@warning {Command \protect #1 invalid in math 
mode}\fi 
#1<-\textquestiondown

还发现

....\T1/cmr/m/n/10 ¾

在日志中。

奇怪的¾是，因为我的 Emacs/AUCTeX 认为日志文件是经过iso-latin-1编码的，并且这是位于插槽 处的字符190。我复制粘贴的缓冲区实际上使用 UTF-8:buffer code: #xC2 #xBE但是file code: #xBE (encoded by coding system iso-latin-1-unix)。

另一方面¿具有 UTF-8 表示file code: #xC2 #xBF (encoded by coding system utf-8-unix)，并且我们在上面看到这会在 (PDF)LaTeX+inputenc[utf8] 端产生很大的混乱，以将0xBF(191) 转换为0xBE(190)，这与 T1 字体编码中的实际位置相匹配。

另一方面，在 XeLaTeX 情况下，inputenc在的情况下不执行任何操作utf8，结果是191保留191，我们可以在 PDF 中看到恰好位于191T1 字体编码中的插槽位置的字形。

\T1\textquestiondown还要注意，如果我们通过以下方式查询 PDFLaTeX 案例中的含义

\expandafter\show\csname T1\string\textquestiondown\endcsname

我们在日志中得到这个：

> \T1\textquestiondown=\char"BE.
<recently read> \T1\textquestiondown 

l.16 ...sname T1\string\textquestiondown\endcsname

我们确实发现0xBE=190这是 T1 插槽¿。

有关的：为什么 inputenc 在“基于 utf8 的引擎”下这么快就放弃了？

相关内容