我通常使用newtxtext
来处理大多数文档,但我正在尝试从 pdfLaTeX 切换到 XeTeX。Unicode 字符 ¿ 和 ¡newtxtext
在 LuaTex 和 XeTeX 上使用时会显示为 £ 和 ą,所以我fontspec
现在就使用。请注意,如果我使用标准命令(如)输入字符,则不会发生这种情况\textquestiondown
。我认为这只是与新引擎的某种不兼容,尽管我还没有在任何地方读到它们不应该在这些引擎中使用。
[
polyglossia
同样,我也遵循使用而不是的做法,babel
因为我读过polyglossia
被设计为babel
XeTeX 中的后继者,但是有什么真正的理由不继续使用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 中看到恰好位于191
T1 字体编码中的插槽位置的字形。
\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 插槽¿
。