> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/mais-topicos/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# Como o Overleaf criou os dados de referência das primitivas TeX

Este artigo descreve os métodos e técnicas usados para produzir as duas tabelas de referência cruzada dos comandos primitivos do TeX:

* [Primitivas do TeX listadas por motor TeX](/latex/overleaf-learn-latex-pt/mais-topicos/46-tex-primitives-listed-by-tex-engine.md) e;
* [Primitivas do TeX listadas por motor TeX CJK](/latex/overleaf-learn-latex-pt/mais-topicos/45-tex-primitives-listed-by-cjk-tex-engine.md).

Esta informação é fornecida para leitores interessados nos pormenores mais finos, mas não é um pré-requisito para usar a própria tabela de referência cruzada. Para responder às necessidades de diferentes leitores, fornecemos uma versão de resumo muito curta juntamente com uma explicação mais longa para quem deseja explorar as questões com maior profundidade.

## Versão curta de resumo/visão geral

Para construir a tabela de referência cruzada, a Overleaf processou o código-fonte de 9 motores TeX para extrair a lista de primitivas suportadas por cada um: esse processo produziu 9 ficheiros de texto (1 ficheiro por motor TeX). Esses 9 conjuntos de primitivas foram combinados para criar uma “lista-mestre”, que era, na prática, a união dos conjuntos individuais de primitivas: resultando num total de cerca de 1000 primitivas únicas distribuídas pelos vários motores. Para cada motor, a sua própria lista de primitivas foi cruzada com o ficheiro-mestre (o conjunto de todos os comandos) para determinar quais desses \~1000 comandos ele suportava: essas comparações estão tabuladas nas duas tabelas seguintes:

* [Dados de referência cruzada das primitivas do TeX](/latex/overleaf-learn-latex-pt/mais-topicos/46-tex-primitives-listed-by-tex-engine.md)
* [Dados de referência cruzada das primitivas do TeX (para motores CJK)](/latex/overleaf-learn-latex-pt/mais-topicos/45-tex-primitives-listed-by-cjk-tex-engine.md)

## “Construção de software” 101: O que isso significa?

Ao longo do restante deste artigo, fazemos referência à noção de “construir motores TeX”, que pode ser um conceito desconhecido se você não é programador, ou não programa em linguagens compiladas como C ou C++. Para os nossos propósitos, construir software—isto é, motores TeX—é o processo de criar um programa TeX executável a partir das suas partes constituintes—os ficheiros de código-fonte escritos na linguagem de programação usada para desenvolver o programa.

## Versão completa: Quer os detalhes? Continue a ler...

Cada motor de composição tipográfica baseado em TeX suporta um “dialeto” da linguagem TeX: um conjunto particular de comandos primitivos que controlam as funcionalidades de composição tipográfica de cada motor e fornecem os blocos de construção para criar/definir macros: sequências de comandos definidas pelo utilizador. Cada macro, seja escrita para LaTeX, plain TeX ou qualquer outro pacote de macros, é, em última análise, construída a partir de comandos primitivos—embora possa ser necessário aprofundar bastante, passando por camadas de macros adicionais, antes de chegar à “camada rochosa” das primitivas do TeX. O conjunto dos 9 motores TeX analisados para produzir os dados de referência dos comandos primitivos, é claro, tem muitos comandos em comum, mas cada motor TeX também tem os seus próprios comandos primitivos, adicionados pelos seus programadores, para fornecer suporte para as funcionalidades específicas dessa “versão” do TeX.

Os comandos primitivos de um motor TeX estão incorporados no software TeX executável: as primitivas não são macros construídas pelos utilizadores, são instruções fundamentais, indivisíveis/atómicas, usadas para controlar o comportamento de composição tipográfica de cada motor. Consequentemente, a maneira mais fiável de criar uma lista definitiva dos comandos primitivos suportados por qualquer motor TeX é examinar o código-fonte real a partir do qual os programas TeX executáveis são construídos (compilados) e extrair a lista de primitivas definida no código-fonte. Parece que deveria ser fácil, certo? No entanto, devido à história de desenvolvimento de 40 anos do TeX, explorar/examinar os ficheiros de código-fonte dos motores TeX (exceto LuaTeX) não é particularmente simples. A razão dessas complexidades está nas ferramentas, na linguagem de programação (Pascal) e na metodologia (programação literária) que Knuth usou para escrever o código-fonte original do TeX—a partir do qual todos os outros motores descendem, em última análise.

Notamos uma exceção para LuaTeX porque o código do seu motor principal foi reescrito em C para remover o uso de Pascal e outras complexidades legadas detalhadas abaixo (Web2C); consequentemente, embora o código-fonte do LuaTeX seja substancial, a forma como ele é “empacotado” e distribuído é muito mais compreensível em comparação com outros motores TeX. Como consequência, e com base no fluxo de trabalho/processos usados para construí-los a partir do código-fonte, é conveniente agrupar os motores TeX em duas categorias:

1. LuaTeX: processo de compilação personalizado (mais moderno)
2. Todos os outros motores: processo de compilação legado (Web2C)

## O contexto do código legado: por que a construção da maioria dos motores TeX é complexa

Como veremos abaixo, Knuth lançou o seu código-fonte original do TeX como um único ficheiro monolítico chamado `tex.web` que, a cada 7 anos, Knuth continua a atualizar para corrigir quaisquer bugs restantes—nunca são adicionadas novas funcionalidades, é puramente um exercício de correção de bugs.

A extensão do ficheiro-fonte do TeX (`.web`) é improvável de lhe ser familiar e pode perguntar-se que linguagem Knuth usou para escrever o TeX? A resposta é Pascal, mas a extensão precisa de um pouco mais de explicação. Knuth desenvolveu uma metodologia de programação que chamou `.web` extensão precisa de um pouco mais de explicação. Knuth desenvolveu uma metodologia de programação que chamou [programação literária](https://en.wikipedia.org/wiki/Literate_programming) na qual o código-fonte e a documentação de um programa são combinados e lançados como um único ficheiro composto (código + documentação) com a extensão `.web`: esse tipo de ficheiro é referido como um ficheiro WEB. Explicamos os ficheiros WEB com um pouco mais de detalhe abaixo.

### Criando novos motores TeX: as estipulações de Knuth

Embora Knuth há muito tempo tenha disponibilizado livremente o seu código-fonte do TeX (`tex.web`) a todos, ele, como é seu direito absoluto, fez uma estipulação fundamental de que o seu código-fonte (`tex.web`) não deve ser editado/modificado diretamente e redistribuído com o nome de programa “TeX”. No código-fonte ele escreve:

```
% Este programa tem direitos de autor (C) 1982 por D. E. Knuth; todos os direitos reservados.
% A cópia deste ficheiro só é autorizada se (1) você for D. E. Knuth, ou se
% (2) você não fizer absolutamente nenhuma alteração à sua cópia. (O sistema WEB fornece
% alterações através de um ficheiro auxiliar; o ficheiro mestre deve permanecer intacto.)
```

e também:

```
Se este programa for alterado, o sistema resultante não deve ser chamado
`\TeX'; o nome oficial `\TeX' por si só está reservado
para sistemas de software que sejam totalmente compatíveis entre si.
Um conjunto especial de testes chamado o ``\.{TRIP} test'' está disponível para
ajudar a determinar se uma implementação específica merece ser
conhecida como `\TeX' [cf.~relatório de Ciências da Computação de Stanford CS1027,
Novembro de 1984].
```

Em essência: não faça alterações editando e distribuindo versões modificadas do código-fonte mestre do TeX e continue a chamá-lo `tex.web`. Se realmente quiser fazer alterações, por exemplo, adicionar novas primitivas etc., então deve aplicar essas alterações fazendo “alterações através de um ficheiro auxiliar” e dar ao seu programa “derivado de TeX” um nome que o distinga de “TeX”, que, na forma composta ($$\mathrm\TeX$$), é uma marca registada da American Mathematical Society.

### A herança do legado

Embora tenha havido tentativas de reescrever completamente o TeX usando linguagens e metodologias de programação modernas—como as duas iniciativas baseadas em Java [Sistema Novo de Composição Tipográfica](https://en.wikipedia.org/wiki/New_Typesetting_System) e [εχTEX](http://www.extex.org/) e outras, como [uma em Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), nenhuma foi completamente bem-sucedida. A história dos projetos e iniciativas concebidos para desenvolver ainda mais o TeX é um tópico interessante e os leitores poderão querer [visitar a FAQ do TeX do Reino Unido](https://texfaq.org/FAQ-enginedev) para mais informações.

Essas iniciativas não LuaTeX que também tiveram sucesso, como e-TeX, pdfTeX, XeTeX e outros motores, foram construídas *diretamente sobre* o código original de Knuth: pegando no seu código-fonte e “aplicando alterações” para derivar um novo motor com capacidades adicionais—como adicionar novas primitivas, produzir saída PDF, suportar entrada de texto UTF-8 e assim por diante. Embora essa abordagem tenha levado a sucessos notáveis, também significa que esses motores derivados herdam o código legado e as técnicas de desenvolvimento que Knuth criou há 40 anos.

A principal conclusão aqui é que, exceto o LuaTeX, a maioria dos motores TeX derivados do código-fonte original de Knuth é criada pegando num único ficheiro monolítico (normalmente `tex.web`) e aplicando alterações que geram mais um único ficheiro monolítico contendo o código-fonte principal desse novo motor. Leitores avançados podem querer avançar para as [notas qualificativas sobre pdfTeX e XeTeX](#aside-xetex-and-pdftex).

### Alguma história/contexto adicional do TeX

O momento da génese do TeX foi [registado no diário de Knuth como 30 de março de 1977](/latex/overleaf-learn-latex-pt/artigos-aprofundados/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), há agora mais de 40 anos. Internamente, o TeX é um programa extraordinariamente complexo cujo código-fonte Knuth teve o cuidado de [documentar com detalhes excepcionais](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Para isso, Knuth desenvolveu um estilo de programação que chamou [programação literária](https://en.wikipedia.org/wiki/Literate_programming) no qual o código-fonte e a documentação de um programa são combinados e lançados como um ficheiro composto com a extensão `.web` (referido como um ficheiro WEB). Knuth escolheu Pascal como a linguagem de programação para escrever o seu software TeX e, sem surpresa, usou a linguagem de composição tipográfica TeX para escrever a documentação final. Consequentemente, o código-fonte mestre do TeX de Knuth é publicado como um único ficheiro monolítico chamado `tex.web`: uma mistura de código-fonte em Pascal e código de composição tipográfica TeX para a documentação.

Se um programa é escrito usando o estilo/metodologia de programação literária de Knuth (como são TeX, MetaFont, BibTeX e outros), é necessário pré-processar o ficheiro WEB para extrair a documentação ou o código-fonte. Para aceder à documentação do programa, processa-se o ficheiro WEB (por exemplo, `tex.web`) com um utilitário chamado [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) que produz a documentação como um `.tex` ficheiro que pode ser composto tipograficamente. Para extrair o código-fonte em Pascal usa-se outro utilitário chamado [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) que produz um ficheiro com a extensão `.p` que contém código-fonte em Pascal.

No momento da redação deste texto (início de 2019), a versão mais recente do TeX de Knuth é 3.14159265, datada de janeiro de 2014. Mais uma vez, note que o código-fonte do TeX de Knuth está contido em apenas um único ficheiro com cerca de 25 000 linhas de código TeX/Pascal!

### Do Pascal para C

Durante os mais de 40 anos que decorreram desde a génese do TeX, o Pascal caiu em desuso e hoje poucas, se é que alguma?, pessoas consideram compilar o TeX a partir do seu código-fonte original em Pascal. Para contornar o uso de Pascal por Knuth, foi concebido um fluxo de trabalho chamado [Web2C](http://tug.org/texinfohtml/web2c.html) no qual o código-fonte em Pascal do TeX é convertido mecanicamente (isto é, através de software) para o seu equivalente em código C, que é então usado para compilar o TeX e construir o programa executável. Funciona bem, mas a única desvantagem é que o código-fonte em C gerado mecanicamente não se destina à inspeção humana casual: é *extremamente* verboso e quase impenetrável, destinando-se a compiladores, não a pessoas—aqui está uma captura de ecrã mostrando um pequeno fragmento do código C gerado a partir do código-fonte em Pascal do TeX:

![](/files/df68df654ca96592b03b78c53fc53e5b8dff6cd0)

### Outra Knuth-ice: ficheiros de alterações WEB

Como observado acima, para se basear no código-fonte original de Knuth você “aplica alterações” ou, nas palavras de Knuth, faz “alterações através de um ficheiro auxiliar”: mas o que isso realmente significa? Entra o *mecanismo de ficheiro de alterações*.

### Ficheiros de alterações: o mecanismo para criar novos motores TeX

Os desenvolvedores que desejam estender o TeX de Knuth de alguma forma, ou seja, construir sobre o trabalho original de Knuth, normalmente desejam criar uma “nova versão” completa do TeX ou fornecer uma *extensão* que possa ser adicionada a qualquer motor TeX. Exemplos de extensões incluem [SyncTeX](https://github.com/jlaurens/synctex) e [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX, por exemplo, é uma extensão muito útil que agora está incluída em todos os motores TeX. A necessidade do EncTeX foi em grande parte ultrapassada pela evolução dos motores TeX conscientes de Unicode—mas note que o EncTeX está incorporado no pdfTeX.

Quer o desejo seja produzir uma nova “versão” do TeX (isto é, um derivado do TeX original de Knuth), quer criar uma extensão, os seus desenvolvedores começam com o código-fonte original de Knuth e aplicam as modificações necessárias para criar um novo motor TeX (ou uma extensão adicional). No entanto, como observado acima, qualquer pessoa que deseje modificar o comportamento do TeX precisa de o fazer usando “alterações através de um ficheiro auxiliar” porque essas alterações/modificações não devem ser aplicadas por *diretamente* editar o código-fonte original de Knuth: os desenvolvedores são obrigados a usar o chamado WEB *mecanismo de ficheiro de alterações*. O código para modificar o TeX de Knuth é escrito na “linguagem” WEB e guardado em um ou mais ficheiros de código (chamados *ficheiros de alterações*) que são subsequentemente *fundidos* com o código-fonte mestre original e intocado de Knuth. Esse processo de fusão cria um novo ficheiro WEB composto que agora contém o *núcleo* código-fonte do novo software baseado em TeX, modificado. *Ficheiros de alterações* frequentemente têm a extensão `.ch` mas, na prática, podem ter qualquer extensão desejada pelos desenvolvedores.

#### Como usar/aplicar ficheiros de alterações?

Atualmente, a maneira mais fácil de aplicar ficheiros de alterações e modificar um ficheiro WEB “mestre” é com um programa utilitário chamado [TIE](https://ctan.org/pkg/tie). Por exemplo, suponha que queria modificar o TeX de Knuth adicionando, digamos, um par de novas primitivas, ou quisesse alterar o comportamento de uma primitiva TeX (padrão) existente. Você escreveria o seu código (em Pascal!) usando o sistema WEB de programação literária e guardá-lo-ia num ficheiro chamado, por exemplo, `myprim.ch`. O próximo passo é fundir o seu código (em `myprim.ch`) com o ficheiro-fonte mestre de Knuth `tex.web` e produzir um novo ficheiro WEB composto, representando o que chamaremos `mytex.web`. Para fazer isso, basta executar o programa TIE assim:

```
tie -m mytex.web tex.web myprim.ch
```

Assumindo que a fusão seja bem-sucedida, isso resultará num novo ficheiro WEB, `mytex.web`deixando o ficheiro-fonte mestre de Knuth `tex.web` completamente inalterado, como exigido.

Vamos agora assumir que outra pessoa gosta das alterações que você fez e quer modificar o seu trabalho para adicionar as suas alterações por cima, ou além, do que você fez. Em vez de distribuir a sua versão modificada do TeX (`mytex.web`) você decide publicar/partilhar apenas o ficheiro de alterações, `myprim.ch`. Qualquer pessoa que queira desenvolver o seu trabalho pode agora criar e partilhar o seu ficheiro de alterações chamado, digamos, `moreprim.ch` que estende o seu código de alguma forma. Qualquer outra pessoa que queira tirar partido de ambos os ficheiros de alterações pode agora gerar um novo ficheiro WEB composto fundindo *ambos* ficheiros de alterações no original de Knuth para gerar mais um programa TeX chamado, digamos, `newmytex.web`:

```
tie -m newmytex.web tex.web myprim.ch moreprim.ch
```

### Sistemas TeX reais: múltiplos ficheiros de alterações

A descrição acima do TIE é, na verdade, muito próxima da forma como muitos motores TeX são construídos na prática: eles começam com o `tex.web` e adicionam uma sucessão de ficheiros de alterações para gerar o ficheiro-fonte WEB desse motor. Cada motor TeX requer o seu próprio conjunto específico de ficheiros de alterações, que têm de ser aplicados/processados (fundidos) numa ordem estrita: se errar a ordem, o processo de fusão falhará porque cada ficheiro de alterações numa sequência depende de alterações introduzidas por ficheiros de alterações que aparecem mais cedo na cadeia.

Aqui está uma execução de exemplo do TIE aplicando vários ficheiros de alterações ao `tex.web` de Knuth, a fim de gerar `ktex.web`—o ficheiro WEB composto com modificações no TeX de Knuth que o tornam pronto (adequado) para conversão para C através do processo Web2C. Note também o seguinte:

* `tex.ch` é um ficheiro de alterações muito grande que, entre muitas outras coisas, modifica o TeX para usar Kpathsea;
* a extensão SyncTeX é adicionada através de múltiplos ficheiros de alterações.

```
tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch
Isto é TIE, CWEB Version 2.4.
Copyright (c) 1989,1992 pela THD/ITI. Todos os direitos reservados.
(tex.web)
(tex.ch)
(enctex.ch)
(synctex-def.ch0)
(synctex-mem.ch0)
(synctex-mem.ch2)
(synctex-rec.ch0)
(synctex-rec.ch1)
(synctex-rec.ch2)
(tex-binpool.ch)
....500....1000....1500....2000....2500....3000....3500....4000....4500
....5000....5500....6000....6500....7000....7500....8000....8500....9000
....9500....10000....10500....11000....11500....12000....12500....13000
....13500....14000....14500....15000....15500....16000....16500....17000
....17500....18000....18500....19000....19500....20000....20500....21000
....21500....22000....22500....23000....23500....24000....24500....
(Não foram encontrados erros.)
```

#### Observação lateral: XeTeX e pdfTeX

Por uma questão de completude, devemos notar que o processo de compilação do pdfTeX e do XeTeX não começa, na verdade, com o `tex.web`; em vez disso, começam com ficheiros chamados `pdftex.web` e `xetex.web` respetivamente: presumivelmente porque as alterações são tão extensas que faz mais sentido partilhar/publicar ficheiros WEB que já contenham as modificações muito significativas feitas ao código original de Knuth.

### Um exemplo: e-upTeX

A comunidade japonesa de TeX desenvolveu uma série de motores TeX concebidos para lidar com as complexidades da composição tipográfica de texto japonês:

* **pTeX**: o motor TeX de Knuth estendido para suportar composição tipográfica japonesa;
* **e-pTeX**: uma combinação de e-TeX e pTeX (mais algumas primitivas introduzidas pelo pdfTeX);
* **upTeX**: uma versão consciente de Unicode do pTeX mais extensões para melhor tratamento de CJK (chinês, japonês e coreano);
* **e-upTeX**: uma combinação (fusão) de e-TeX e upTeX.

#### Gerando o ficheiro-fonte composto para e-upTeX

Para criar o ficheiro-fonte WEB composto para e-upTeX (com SyncTeX) você começa com o código-fonte original de Knuth `tex.web` mas precisa de aplicar **26** ficheiros de alterações individuais, na seguinte ordem, para obter um único ficheiro composto a partir do qual a lista de comandos primitivos pode ser extraída:

```
etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0,
ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech,
etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0,
synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1,
synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1,
synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch,
pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch,
tex-binpool.ch
```

#### Aplicando ficheiros de alterações: quais ficheiros e em que ordem?

Como foi observado, é criticamente importante aplicar/processar ficheiros de alterações numa ordem estrita—mas como descobrir quais ficheiros são necessários e a ordem em que devem ser processados? Felizmente, essa informação crucial está registada em ficheiros contidos na distribuição TeX Live e uma exploração do código-fonte do TeX Live revelou as regras que regem os requisitos de compilação de cada motor TeX. Seguindo essas regras, a Overleaf conseguiu reconstruir o ficheiro-fonte WEB composto de cada motor TeX e extrair uma lista de primitivas para posterior processamento de dados.

## E, por fim: Como extrair a lista de primitivas?

Uma vez construído o ficheiro WEB composto, a tarefa de extrair a lista de primitivas, usando expressões regulares, é direta porque todos os comandos primitivos são definidos (“registados”) usando uma única função Pascal chamada `primitive(...)`. Aqui estão alguns exemplos reais retirados do código-fonte de Knuth: `tex.web` código-fonte de Knuth:

```
primitive("lineskip",assign_glue,glue_base+line_skip_code)
primitive("baselineskip",assign_glue,glue_base+baseline_skip_code)
primitive("parskip",assign_glue,glue_base+par_skip_code)
primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code)
primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code)
primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code)
...
...
```

Como pode ver, a `primitive(...)` função é altamente adequada para processamento de texto com expressões regulares: o nome da primitiva a ser registada está entre aspas (`"..."`) juntamente com dados adicionais que classificam o comportamento de cada primitiva (não consideraremos isso em pormenor). Depois de extrair a lista de primitivas para cada motor, esses dados foram processados por alguns scripts Lua para gerar HTML contendo os resultados tabulados.

### Voltando ao LuaTeX

Notámos que o LuaTeX não usa exatamente os mesmos processos de compilação que os outros 8 motores TeX. Tendo explorado brevemente o processo Web2C, a conversão de Pascal para C e o mecanismo de ficheiros de alterações, podemos agora explicar onde o LuaTeX difere: os desenvolvedores do LuaTeX decidiram dispensar o processo trabalhoso de converter Pascal para C—como observado em [Manual de Referência do LuaTeX](http://www.pragma-ade.com/general/manuals/luatex):

> ...a estrutura de compilação é web2c e continuamos a usá-la, mas sem a etapa de Pascal para C.

O motor principal do LuaTeX foi reescrito em C, o que significa que o seu processo de compilação é um pouco mais padrão e certamente muito mais conveniente. Uma consequência útil é que as primitivas suportadas pelo LuaTeX estão bem separadas num ficheiro-fonte C distinto, o que facilitou consideravelmente a tarefa de acesso/listagem.

Falando estritamente, devemos também notar que alguns dos ficheiros de código-fonte do LuaTeX usam uma variante da metodologia de programação literária de Knuth, chamada [CWEB](https://en.wikipedia.org/wiki/CWEB), que é baseada em C e não em Pascal.

### Não são apenas ficheiros WEB: é necessário outro código-fonte

Depois de gerar o ficheiro-fonte WEB composto para qualquer motor TeX (exceto LuaTeX), o código-fonte em Pascal tem de ser extraído e convertido para código C, mas isso não é a solução total. Além do código C gerado a partir do ficheiro-fonte WEB (Pascal⮕C), a maioria dos motores TeX também depende (exige) de uma série de ficheiros-fonte auxiliares adicionais (bibliotecas) que são tipicamente escritos em C—tais como [Kpathsea](https://www.tug.org/kpathsea/). Os ficheiros-fonte auxiliares (bibliotecas) implementam funcionalidade que não precisa, ou não pode, ser escrita em WEB (Pascal). Tudo o que for escrito na “linguagem” WEB para TeX tem de usar a linguagem Pascal, que é subsequentemente extraída e convertida em C gerado por máquina: se não precisa de fazer isso, por que não simplesmente escrevê-lo em C ou C++ logo de início.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/mais-topicos/18-how-overleaf-created-the-tex-primitive-reference-data.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.