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

在 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 的引擎”下这么快就放弃了?

相关内容