\documentclass{article}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{2026}{\dots}% …
\usepackage{amsmath}
\begin{document}
\[\left\{a \dots \right\}\]
\[\left\{a … \right\}\]
\end{document}
O espaçamento ao redor das reticências não é o mesmo para \dots
e …
no documento acima (o terceiro caso é se eu remover \DeclareUnicodeCharacter{2026}{\dots}
):
Como posso obter o mesmo espaçamento com \dots
e …
? Espero que isso possa ser feito sem alterar nada na fórmula em si, apenas no \DeclareUnicodeCharacter
código, caso contrário, provavelmente esquecerei o hack na maioria das vezes e as fórmulas serão menos concisas.
O problema desaparece se eu não estiver usando o amsmath
.
Responder1
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
%\DeclareUnicodeCharacter{2026}{\dots}% …
% \u8:… ->\IeC {\dots }
\expandafter\def\csname u8:\detokenize{…}\endcsname#1{\dots#1}
\begin{document}
$\left\{a \dots \right\}$\vline
$\left\{a … \right\}$\vline
\end{document}
\dots
olha para o próximo token para ver se deve usar pontos baixos ou centralizados. \DeclareUnicodeCharacter
envolve sua definição em \IeC{...}
onde \IeC
(aqui) é apenas uma macro que não faz nada além de usar seu argumento.
Mas o principal problema é que \dots
usa \futurelet
(em vez de say \@ifnextchar
) para não pular o espaço em branco enquanto procura o próximo token. isso geralmente não importa, pois \dots
o espaço em branco é ignorado após um nome de comando, mas não depois de ... (que é o problema \IeC
abordado, para garantir que os caracteres enc de entrada não tenham definições que terminem com um token que força o branco espaço a ser ignorado se gravado em um arquivo externo, como índice analítico.
Então aqui eu defino ... pegar um argumento e retorná-lo, o que é uma maneira (mais ou menos segura) de forçar o espaço após o caractere ser ignorado, para que os \dots
testes \}
não vejam um espaço. A única parte insegura sobre isso é que {…}
causaria um erro de análise, pois o analisador de argumentos atingiria o final do grupo enquanto procurava por #1
.