Diferentes implementações de TeX (por exemplo, MiKTeX e TeX Live) devem produzir arquivos DVI idênticos?

Question

Diz-se que o TeX deve funcionar de forma idêntica em todos os sistemas. Por exemplo,KnuthdeTeste de viagemexiste para garantir que qualquer programa possa ser chamado de “TeX” apenas se fizer certas coisas com determinadas entradas. E o próprio programa TeX toma certas medidas para evitar que fatores dependentes do sistema causem diferenças no comportamento, por exemplo, para dimensões, em vez de números de ponto flutuante, o TeX usa números de ponto fixo: múltiplos inteiros de 1 sp(ponto escalonado) que é 1/65536 de 1/72,27 de polegada.

1º trimestre: Mas (além de passar no teste de viagem) o que significa comportar-se de forma idêntica?

Como a saída do TeX é um arquivo DVI contendo instruções de composição (escolha a fonte F, mova para a direita nas unidades W, defina o caractere 97 lá, etc.), uma interpretação natural (me parece) é que os arquivos DVI devem ser idênticos , exceto, é claro, pelos bytes que constituem o carimbo de data/hora. Equivalentemente, se executarmos dvitypenos dois arquivos, ecomparardepois de filtrar a linha do carimbo de data/hora, eles devem conter instruções idênticas (é uma interpretação).

Mas mesmo com arquivos de entrada bastante simples, vejo discrepâncias nos arquivos DVI (ou seja, além da linha de carimbo de data e hora), entre o MiKTeX e o TeX Live. Especificamente, considere o seguinte .texarquivo de entrada mínimo (parte de um parágrafo deUma introdução suave ao TeX):

The DVI file is then read by another program (called a
device driver) that produces the output that is readable by
humans. Why the extra file? The same DVI file can be
read by different device drivers to produce output on a dot
matrix printer, a laser printer, a screen viewer, or a
phototypesetter. Once you have

\end

Quando executo o arquivo acima por meio de dois programas chamados TeX, a saber:

MiKTeX-TeX 2.9.6300 (3.14159265) (MiKTeX 2.9.6600)

e

TeX 3.14159265 (TeX Live 2017)

ambos no mesmo computador (macOS 10.13.3 High Sierra), a saída do TeX (os arquivos DVI)olharvisualmente idênticos, mas têm tamanhos diferentes (número diferente de bytes). Quando as instruções reais (opcodes) contidas nos arquivos DVI são comparadas (executando dvitypeem cada arquivo), existem centenas de pequenas diferenças. Neste caso, o primeiro é

10c10
< Postamble starts at byte 561.
---
> Postamble starts at byte 564.

que é causado por uma diferença que ocorre posteriormente abaixo:

< 436: w0 261236 h:=9392617+261236=9653853, hh:=611 
< 437: setchar112 h:=9653853+364090=10017943, hh:=634 
< 438: setchar114 h:=10017943+256683=10274626, hh:=650 
< 439: setchar105 h:=10274626+182045=10456671, hh:=662 
< 440: setchar110 h:=10456671+364090=10820761, hh:=685 
< 441: x2 -18205 h:=10820761-18205=10802556, hh:=684 
< 444: setchar116 h:=10802556+254863=11057419, hh:=700 
< 445: setchar101 h:=11057419+291271=11348690, hh:=718 
< 446: setchar114 h:=11348690+256683=11605373, hh:=734 
< 447: setchar44 h:=11605373+182045=11787418, hh:=746 
< 448: right3 271931 h:=11787418+271931=12059349, hh:=764 
< 452: setchar97 h:=12059349+327681=12387030, hh:=785 
---
> 436: right3 261235 h:=9392617+261235=9653852, hh:=611 
> 440: setchar112 h:=9653852+364090=10017942, hh:=634 
> 441: setchar114 h:=10017942+256683=10274625, hh:=650 
> 442: setchar105 h:=10274625+182045=10456670, hh:=662 
> 443: setchar110 h:=10456670+364090=10820760, hh:=685 
> 444: x2 -18205 h:=10820760-18205=10802555, hh:=684 
> 447: setchar116 h:=10802555+254863=11057418, hh:=700 
> 448: setchar101 h:=11057418+291271=11348689, hh:=718 
> 449: setchar114 h:=11348689+256683=11605372, hh:=734 
> 450: setchar44 h:=11605372+182045=11787417, hh:=746 
> 451: right3 271932 h:=11787417+271932=12059349, hh:=764 
> 455: setchar97 h:=12059349+327681=12387030, hh:=785 

ou se quiser vê-lo verticalmente lado a lado:

436: w0 261236 h:=9392617+261236=9653853, hh:=611             | 436: right3 261235 h:=9392617+261235=9653852, hh:=611 
437: setchar112 h:=9653853+364090=10017943, hh:=634           | 440: setchar112 h:=9653852+364090=10017942, hh:=634 
438: setchar114 h:=10017943+256683=10274626, hh:=650          | 441: setchar114 h:=10017942+256683=10274625, hh:=650 
439: setchar105 h:=10274626+182045=10456671, hh:=662          | 442: setchar105 h:=10274625+182045=10456670, hh:=662 
440: setchar110 h:=10456671+364090=10820761, hh:=685          | 443: setchar110 h:=10456670+364090=10820760, hh:=685 
441: x2 -18205 h:=10820761-18205=10802556, hh:=684            | 444: x2 -18205 h:=10820760-18205=10802555, hh:=684 
444: setchar116 h:=10802556+254863=11057419, hh:=700          | 447: setchar116 h:=10802555+254863=11057418, hh:=700 
445: setchar101 h:=11057419+291271=11348690, hh:=718          | 448: setchar101 h:=11057418+291271=11348689, hh:=718 
446: setchar114 h:=11348690+256683=11605373, hh:=734          | 449: setchar114 h:=11348689+256683=11605372, hh:=734 
447: setchar44 h:=11605373+182045=11787418, hh:=746           | 450: setchar44 h:=11605372+182045=11787417, hh:=746 
448: right3 271931 h:=11787418+271931=12059349, hh:=764       | 451: right3 271932 h:=11787417+271932=12059349, hh:=764 
452: setchar97 h:=12059349+327681=12387030, hh:=785           | 455: setchar97 h:=12059349+327681=12387030, hh:=785 

e depois disso, tudo ocorre três bytes depois neste último arquivo (aquele gerado pelo TeX Live tex), incluindo finalmente o postâmbulo. Correspondem à seção printer, a, e como podemos ver, há uma diferença de 1 unidade entre a cola que foi usada nos dois casos, que voltou a sincronizar após essa execução do texto, e também uma diferença de a w0versus uma right3instrução, o que fez com que todas as instruções futuras iniciassem em bytes diferentes.

2º trimestre: Essa discrepância entre MiKTeX e TeX Live é um bug em algum deles? Evidentemente, os dois programas devem ter implementado o arredondamento de forma diferente, em algum lugar. Algum deles está falhando em fazer isso da maneira “certa” (se houver)?

Eu sei que a discrepância é pequena. Uma diferença de 1 unidade no arquivo DVI (unidade DVI?), corresponde, se bem me lembro, a 1 sp, que é uma diferença de cerca de 5 nanômetros, menor que o comprimento de onda da luz visível. Mesmo que a unidade não seja exatamente 1 sp, já vi em algum lugar essas unidades chamadas “RSUs”, para “Unidade Ridiculamente Pequena”. Portanto, a menos que os arquivos DVI fossem produzidos com alguma resolução e/ou ampliação ridícula (fisicamente impossível), a diferença não importaria na prática, na medida em que fosse capaz de distinguir visualmente a saída.

No entanto, há uma diferença, e o TeX não deveria produzir resultados idênticos em todos os sistemas? (Observe que não estou usando pdfTeX ou eTeX, mas apenas o que deveria ser o TeX de Knuth.) Essa diferença torna difícil saber quando duas implementações de TeX estão se comportando de forma idêntica. Então, as últimas perguntas:

P3:É aceitável alguma quantidade de erro de arredondamento/discrepância de ponto flutuante entre implementações de TeX? Em caso afirmativo, quanto exatamente é aceitável? ODocumento de teste TRIPé confuso sobre este assunto, pois diz coisas como (enfatiza o meu):

Configurações de cola noexibiçõesdas caixas TeX estão sujeitas a arredondamentos dependentes do sistema, entãopequenos desvios são permitidos. No entanto, tais desvios aplicam-se apenas aos valores de conjunto de cola que aparecem no final de uma linha \hboxou \vbox;todos os outros números devem concordar exatamente, uma vez que são calculados com aritmética inteira em ummaneira prescrita independente do sistema.

…

O arquivo resultante deve estar de acordo com o TRIP.TYParquivo mestre da etapa 0, exceto quealguns dos valores podem estar um pouco erradosdevido a discrepâncias de arredondamento de ponto flutuante. Além disso, pode haver diferenças entre os comandos 'right' e 'w' e 'x', e entre 'down' e 'y' e 'z'; o principal é que todos os personagens e regras exxxdedeveria estar quase nas mesmas posiçõesconforme especificado no Apêndice F.

4º trimestre: Finalmente, dado que não apenas as posições, mas até mesmo os comandos (e consequentemente todos os bytes subsequentes) podem diferir entre implementações do TeX, como podemos testar se uma nova implementação do TeX está se comportando de maneira adequada/idêntica ao TeX “real”, no sentido de produzindo arquivos DVI “essencialmente” idênticos? Claramente, simplesmente executar diffnos arquivos DVI (depois de dvitype) é impraticável, pois produz profusamente diferenças evidentemente insignificantes. Existe alguma ferramenta (como “você pode querer escrever um DVIcompareprograma” mencionado por Knuth) ou algum outro conjunto de testes?

Answer 1

O TeX se preocupa com a composição tipográfica em um meio físico (por exemplo, papel). Para Don, saída idêntica significa uma aparência visualmente igual e quaisquer cálculos no nível do usuário são exatamente idênticos (é por isso que você não pode acessar alguns aspectos internos do TeX e usar seus valores, pois eles podem diferir de instalação para instalação). Isso significa que as quebras de linha e de página devem estar exatamente no mesmo ponto. No entanto, ele usou deliberadamente o ponto flutuante para calcular partes do manuseio da cola (de uma forma que não pode alterar quebras de linha ou página), mas ao gravar no arquivo dvi, as posições exatas resultantes dos caracteres podem estar erradas por uma pequena fração.

Para responder às suas perguntas explícitas:

Q1: isso realmente mostra o que é explicado no manual do teste TRIP (a parte que você cita no Q3).

Q2: nenhum bug (por causa do que está escrito no manual de teste TRIP)

Q3: não tenho certeza do que há de confuso nessa afirmação. Observe que a "configuração da cola" é quando finalmente se determina os pontos exatos no arquivo dvi, quando a cola é usada dentro do TeX, por exemplo, para determinar quebras de linha ela ainda é usada com ponto fixo para que tais diferenças não apareçam.

Q4 você não pode olhar o arquivo dvi (o que o teste de viagem não faz). Eu não acho que você possa olhar os dados "Caixa concluída enviada" sem mascarar possíveis erros de arredondamento nas peças (conjunto de cola ...) mostradas lá. Mas esse mascaramento é possível e todas as outras partes da exibição simbólica da saída serão exatamente as mesmas e é isso que usamos, por exemplo, no conjunto de testes de regressão LaTeX para comparar a saída após alterações feitas no código LaTeX.

Answer 2

Para web2c, documentei porque todas as diferenças são consideradas aceitáveis ​​em web2c/triptrap/README, ou seja, http://tug.org/svn/texlive/trunk/Build/source/texk/web2c/triptrap/README?view=markup