Ao processar o arquivo simples:
\documentclass{report}
\begin{document}
1234567890
$1234567890$
\end{document}
com pdflatexum, obtenha um PDF com apenas uma fonte (CMR10), mas ao processar com um xelatexou lualatexcom o PDF produzido, use Latin Modern Roman 10 fora do modo matemático e CMR10 dentro.
Quais são as razões por trás disso?
Responder1
Desde o TeX Live 2018, o LaTeX agora é UTF-8 por padrão, porque a “revolução Unicode” foi concluída 1 . Isso torna supérfluo adicionar \usepackage[utf8]{inputenc}ao usar o pdfLaTeX.
No entanto, o suporte UTF-8 no pdfLaTeX é falso e você não pode esperar obter uma saída significativa ao colar caracteres UTF-8 arbitrários na entrada, porque o mecanismo pdfTeX subjacente é inerentemente limitado à codificação de 8 bits.
Isso é bem diferente com Xe/LuaTeX. Esses mecanismos suportam UTF-8 por padrão 2 . As fontes TeX tradicionais são muito limitadas nos glifos que oferecem 3 . Definitivamente, isso não é suficiente para descrever UTF-8, portanto a fonte também deve cobrir todo o intervalo UTF-8 4 . Para este fim, a codificação TU foi introduzida.
Por padrão, o LaTeX carrega a família de fontes Computer Modern (CM). A fonte CMR10 não está disponível na codificação TU (e nunca estará), portanto, seu parente mais próximo, Latin Modern Roman 10, é carregado.
Agora permanece a questão: por que o latim moderno não é usado no modo matemático? Isso ocorre porque no modo matemático as coisas são um pouco mais complicadas. A configuração tradicional era ter famílias diferentes e comandos como \mathbf, \mathcal, etc. mudados para uma família diferente. Isto não é mais possível em Unicode, porque todos os símbolos vêm de uma única fonte. Portanto, a abordagem de troca de família não funciona mais e tem que ser substituída por um sistema muito mais complexo que troca códigos matemáticos entre si. Isso é implementado no unicode-mathpacote. Você também notará por que isso é problemático porque com o unicode-mathpacote o TeX fica subitamente muito mais lento devido à necessidade de reatribuir milhares de códigos matemáticos o tempo todo. É por isso que a codificação OML/OMS padrão atualmente é mantida.
1 Hoje em dia, todo mundo armazena seus arquivos em UTF-8 e a maioria dos softwares entende UTF-8. Basta pensar nos Emojies (eles estão por toda parte). Eles fazem parte do UTF-8, então tudo que pode exibir Emojies deve suportar UTF-8.
2 na verdade o LuaTeX rejeitará seu arquivo se não for UTF-8
3 A codificação T1 só pode codificar 256 glifos
4 se a fonte tem o glifo necessário é outra questão
Responder2
A configuração da fonte para texto e matemática são tarefas bastante separadas no TeX - as fontes de texto precisam se preocupar com coisas como caracteres acentuados e hifenização, fontes matemáticas com muitos símbolos e posicionamento correto de sup e sobrescritos.
Seu exemplo usa apenas alguns glifos que no pdftex podem ser obtidos da mesma fonte. Mas se você adicionar, por exemplo, um sinal de menos (-) ou caracteres (abc), as fontes usadas serão diferentes dentro e fora da matemática. E se você mudar para a codificação T1 recomendada para o texto, \usepackage[T1]{fontenc}haverá diferenças ainda para os números.
Para os motores unicode existe uma diferença mesmo na configuração por omissão visto que a utilização de uma fonte unicode como fonte de texto é mais ou menos obrigatória para obter caracteres acentuados e hifenização correctos (veja por exemplohttps://tex.stackexchange.com/a/470987/2388). Então, no início de 2017, o kernel do LaTeX mudou o padrão para esses motores para que os usuários não fossem mais forçados a carregar o fontspec.
Em matemática, a hifenização e os caracteres acentuados não são realmente relevantes, portanto, a configuração matemática legada funciona no mecanismo Unicode. Mas mesmo que a configuração matemática seja alterada para usar uma fonte unicode, ela não seria a mesma que a fonte de texto, mas, por exemplo, matemática moderna latina.