> 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/it/altri-argomenti/18-how-overleaf-created-the-tex-primitive-reference-data.md). # Come Overleaf ha creato i dati di riferimento dei primitivi TeX Questo articolo descrive i metodi e le tecniche usati per produrre le due tabelle di riferimento incrociato dei comandi primitivi di TeX: * [Primitive di TeX elencate per motore TeX](/latex/it/altri-argomenti/46-tex-primitives-listed-by-tex-engine.md) e; * [Primitive di TeX elencate per motore TeX CJK](/latex/it/altri-argomenti/45-tex-primitives-listed-by-cjk-tex-engine.md). Queste informazioni sono fornite ai lettori interessati ai dettagli più fini, ma non sono un prerequisito per usare la tabella di riferimento incrociato in sé. Per rispondere alle esigenze di lettori diversi forniamo una versione di riepilogo molto breve insieme a una spiegazione più lunga per chi desidera approfondire le questioni in maggiore profondità. ## Versione breve di riepilogo/panoramica Per costruire la tabella di riferimento incrociato, Overleaf ha elaborato il codice sorgente di 9 motori TeX per estrarre l'elenco delle primitive supportate da ciascuno: quel processo ha prodotto 9 file di testo (1 file per motore TeX). Quei 9 insiemi di primitive sono stati combinati per creare un “elenco maestro”, che di fatto era l'unione dei singoli insiemi di primitive: ottenendo un totale di circa 1000 primitive uniche distribuite tra i vari motori. Per ogni motore, il proprio elenco di primitive è stato confrontato con il file maestro (l'insieme di tutti i comandi) per determinare quali di quei \~1000 comandi supportasse: tali confronti sono riportati nelle due tabelle seguenti: * [Dati di riferimento incrociato delle primitive di TeX](/latex/it/altri-argomenti/46-tex-primitives-listed-by-tex-engine.md) * [Dati di riferimento incrociato delle primitive di TeX (per motori CJK)](/latex/it/altri-argomenti/45-tex-primitives-listed-by-cjk-tex-engine.md) ## “Costruire software” 101: che significa? Nel resto di questo articolo facciamo riferimento alla nozione di “costruire motori TeX”, che può essere un concetto sconosciuto se non sei un programmatore, o se non programmi in linguaggi compilati come C o C++. Per i nostri scopi, costruire software—cioè motori TeX—è il processo di creare un programma TeX eseguibile a partire dalle sue parti costitutive—i file di codice sorgente scritti nel linguaggio di programmazione usato per sviluppare il programma. ## Versione completa: vuoi i dettagli? Continua a leggere... Ogni motore di composizione tipografica basato su TeX supporta un “dialetto” del linguaggio TeX: un insieme particolare di comandi primitivi che controllano le funzionalità di composizione di ciascun motore e forniscono i blocchi di costruzione per creare/definire macro: sequenze di comandi definite dall'utente. Ogni macro, sia scritta per LaTeX, plain TeX o qualsiasi altro pacchetto di macro, è in ultima analisi costruita a partire da comandi primitivi—anche se potresti dover scavare molto in profondità, attraverso livelli di macro aggiuntive, prima di raggiungere lo “strato fondamentale” delle primitive di TeX. L'insieme dei 9 motori TeX analizzati per produrre i dati di riferimento dei comandi primitivi ha, naturalmente, molti comandi in comune, ma ciascun motore TeX ha anche i propri comandi primitivi, aggiunti dai suoi sviluppatori, per fornire supporto alle funzionalità specifiche di quella “versione” di TeX. I comandi primitivi di un motore TeX sono incorporati nel software TeX eseguibile: le primitive non sono macro costruite dagli utenti, sono istruzioni fondamentali, indivisibili/atomiche, usate per controllare il comportamento di composizione di ciascun motore. Di conseguenza, il modo più affidabile per creare un elenco definitivo dei comandi primitivi supportati da qualunque motore TeX è esaminare l'effettivo codice sorgente da cui i programmi TeX eseguibili vengono costruiti (compilati) ed estrarre l'elenco delle primitive definite nel codice sorgente. Sembra facile, vero? Tuttavia, a causa della storia di sviluppo di 40 anni di TeX, esplorare/esaminare i file di codice sorgente dei motori TeX (tranne LuaTeX) non è particolarmente semplice. Il motivo di tali complessità risiede negli strumenti, nel linguaggio di programmazione (Pascal) e nella metodologia (programmazione literate) che Knuth usò per scrivere il codice sorgente originale di TeX—da cui tutti gli altri motori discendono, in ultima analisi. Notiamo un'eccezione per LuaTeX perché il codice del suo motore centrale è stato riscritto in C per rimuovere l'uso di Pascal e di altre complessità legacy descritte più avanti (Web2C); di conseguenza, anche se il codice sorgente di LuaTeX è consistente, il modo in cui è “impacchettato” e distribuito è molto più comprensibile rispetto ad altri motori TeX. Di conseguenza, e in base al flusso di lavoro/processi usati per costruirli dal codice sorgente, è conveniente raggruppare i motori TeX in due categorie: 1. LuaTeX: processo di compilazione personalizzato (più moderno) 2. Tutti gli altri motori: processo di compilazione legacy (Web2C) ## Il contesto del codice legacy: perché costruire (la maggior parte dei) motori TeX è complesso Come vedremo più avanti, Knuth rilasciò il suo codice sorgente originale di TeX come un unico file monolitico chiamato `tex.web` che, ogni 7 anni, Knuth continua ad aggiornare per correggere eventuali bug residui—non vengono mai aggiunte nuove funzionalità, è puramente un esercizio di correzione di bug. L'estensione del file del codice sorgente di TeX (`.web`) probabilmente non ti è familiare e potresti chiederti quale linguaggio usasse Knuth per scrivere TeX? La risposta è Pascal ma l' `.web` estensione richiede qualche spiegazione in più. Knuth sviluppò una metodologia di programmazione che chiamò [programmazione literate](https://en.wikipedia.org/wiki/Literate_programming) in cui il codice sorgente e la documentazione di un programma sono combinati e rilasciati come un unico file composito (codice più documentazione) con estensione `.web`: quel tipo di file è chiamato file WEB. Spieghiamo i file WEB un po' più in dettaglio qui sotto. ### Creare nuovi motori TeX: le prescrizioni di Knuth Sebbene Knuth abbia da tempo reso liberamente disponibile a tutti il suo codice sorgente di TeX (`tex.web`), egli stabilì, come è suo pieno diritto, una clausola fondamentale: il suo codice sorgente (`tex.web`) non deve essere modificato direttamente/editato e redistribuito con il nome del programma “TeX”. Nel codice sorgente scrive: ``` % Questo programma è coperto da copyright (C) 1982 di D. E. Knuth; tutti i diritti sono riservati. % La copia di questo file è autorizzata solo se (1) sei D. E. Knuth, oppure se % (2) non apporti assolutamente alcuna modifica alla tua copia. (Il sistema WEB fornisce % le alterazioni tramite un file ausiliario; il file principale deve rimanere intatto.) ``` e anche: ``` Se questo programma viene modificato, il sistema risultante non dovrebbe essere chiamato `\TeX'; il nome ufficiale `\TeX' da solo è riservato ai sistemi software che sono completamente compatibili tra loro. Una speciale suite di test chiamata ``\.{TRIP} test'' è disponibile per aiutare a determinare se una particolare implementazione meriti di essere chiamata `\TeX' [cfr.~rapporto di Stanford Computer Science CS1027, novembre 1984]. ``` In sostanza: non apportare modifiche editando e distribuendo versioni modificate del codice sorgente principale di TeX e continuare a chiamarlo `tex.web`. Se vuoi davvero apportare modifiche, ad esempio aggiungere nuove primitive ecc., allora devi applicare tali modifiche facendo “alterazioni tramite un file ausiliario” e dare al tuo programma “derivato da TeX” un nome che lo distingua da “TeX”, che, in forma tipografica ($$\mathrm\TeX$$), è un marchio dell'American Mathematical Society. ### L'eredità del legacy Sebbene ci siano stati tentativi di riscrivere completamente TeX usando linguaggi e metodologie di programmazione moderni—come le due iniziative basate su Java [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) e [εχTEX](http://www.extex.org/) e altre come [una in Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), nessuna ha avuto pieno successo. La storia di progetti e iniziative concepiti per sviluppare ulteriormente TeX è un tema interessante e i lettori potrebbero voler [visitare la UK TeX FAQ](https://texfaq.org/FAQ-enginedev) per ulteriori informazioni. Quelle iniziative non basate su LuaTeX che hanno avuto successo, come e-TeX, pdfTeX, XeTeX e altri motori, si sono basate *direttamente su* il codice originale di Knuth: prendendo il suo codice sorgente e “applicando modifiche” per derivare un nuovo motore con capacità aggiuntive—come aggiungere nuove primitive, produrre output PDF, supportare l'input di testo UTF-8 e così via. Sebbene questa strada abbia portato a successi notevoli, significa anche che quei motori derivati ereditano il codice legacy e le tecniche di sviluppo che Knuth creò 40 anni fa. Il punto chiave qui è che, a parte LuaTeX, la maggior parte dei motori TeX derivati dal codice sorgente originale di Knuth viene creata prendendo un singolo file monolitico (di solito `tex.web`) e applicando modifiche che generano un altro singolo file monolitico contenente il codice sorgente centrale di quel nuovo motore. I lettori avanzati potrebbero voler saltare in avanti alle [note su pdfTeX e XeTeX](#aside-xetex-and-pdftex). ### Alcuni ulteriori retroscena/storia di TeX Il momento della nascita di TeX fu [registrato nel diario di Knuth come 30 marzo 1977](/latex/it/articoli-approfonditi/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), ormai più di 40 anni fa. Internamente, TeX è un programma straordinariamente complesso il cui codice sorgente Knuth si prese molta cura di [documentare in dettaglio eccezionale](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Per farlo Knuth sviluppò uno stile di programmazione che chiamò [programmazione literate](https://en.wikipedia.org/wiki/Literate_programming) in cui il codice sorgente e la documentazione di un programma sono combinati e rilasciati come un file composito con estensione `.web` (chiamato file WEB). Knuth scelse Pascal come linguaggio di programmazione per scrivere il suo software TeX e, non sorprendentemente, usò il linguaggio tipografico TeX per scrivere la documentazione finale. Di conseguenza, il codice sorgente principale di TeX di Knuth è pubblicato come un unico file monolitico chiamato `tex.web`: una miscela di codice sorgente Pascal e codice di composizione TeX per la documentazione. Se un programma è scritto usando lo stile/metodologia di programmazione literate di Knuth (come TeX, MetaFont, BibTeX e altri) è necessario pre-elaborare il file WEB per estrarre la documentazione o il codice sorgente. Per accedere alla documentazione del programma si elabora il file WEB (ad esempio, `tex.web`) con un'utility chiamata [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) che produce la documentazione come `.tex` un file che puoi impaginare. Per estrarre il codice sorgente in Pascal si usa un'altra utility chiamata [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) che produce un file con estensione `.p` che contiene codice sorgente Pascal. Al momento della scrittura (inizio 2019) l'ultima versione di TeX di Knuth è la 3.14159265, datata gennaio 2014. Anche qui, nota che il codice sorgente di TeX di Knuth è contenuto in un solo file contenente circa 25.000 righe di codice TeX/Pascal! ### Da Pascal a C Nel corso dei 40+ anni trascorsi dalla nascita di TeX, Pascal è passato di moda e oggi poche, se non nessuna?, persone pensano ormai di costruire TeX a partire dal suo codice sorgente Pascal originale. Per aggirare l'uso di Pascal da parte di Knuth, è stato progettato un flusso di lavoro chiamato [Web2C](http://tug.org/texinfohtml/web2c.html) in cui il codice sorgente Pascal di TeX viene convertito meccanicamente (cioè tramite software) nel suo equivalente in codice C, che viene poi usato per compilare TeX e costruire il programma eseguibile. Funziona bene, ma l'unico svantaggio è che il codice sorgente C generato meccanicamente non è destinato a un'ispezione umana occasionale: è *estremamente* verboso e quasi impenetrabile, essendo destinato ai compilatori, non alle persone—ecco uno screenshot che mostra un piccolo frammento del codice C generato dal sorgente Pascal di TeX: ![](/files/0a5ace5e03645761f433c7df78306c03010b6c96) ### Un altro knuthismo: i file di modifica WEB Come notato sopra, per costruire a partire dal codice sorgente originale di Knuth “si applicano modifiche” o, nelle parole di Knuth, si fanno “alterazioni tramite un file ausiliario”: ma che significa davvero? Entra in gioco il *meccanismo dei file di modifica*. ### File di modifica: il meccanismo per creare nuovi motori TeX Gli sviluppatori che vogliono estendere in qualche modo il TeX di Knuth, cioè costruire sul lavoro originale di Knuth, di solito desiderano creare un'intera nuova “versione” di TeX oppure fornire un *estensione* che possa essere aggiunta a qualsiasi motore TeX. Esempi di estensioni includono [SyncTeX](https://github.com/jlaurens/synctex) e [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX, ad esempio, è un'estensione molto utile che oggi è inclusa in tutti i motori TeX. La necessità di EncTeX è stata in gran parte superata dall'evoluzione dei motori TeX consapevoli di Unicode—ma nota che EncTeX è incorporato in pdfTeX. Che il desiderio sia produrre una nuova “versione” di TeX (cioè un derivato del TeX originale di Knuth) oppure creare un'estensione, i suoi sviluppatori partono dal codice sorgente originale di Knuth e applicano le modifiche necessarie per creare un nuovo motore TeX (o un'estensione aggiuntiva). Tuttavia, come detto sopra, chiunque voglia modificare il comportamento di TeX deve farlo usando “alterazioni tramite un file ausiliario” perché tali modifiche non devono essere applicate *direttamente* editando il codice sorgente originale di Knuth: gli sviluppatori sono tenuti a usare il cosiddetto WEB *meccanismo dei file di modifica*. Il codice per modificare il TeX di Knuth è scritto nel “linguaggio” WEB e salvato in uno o più file di codice (chiamati *file di modifica*) che vengono poi *uniti* al codice sorgente principale originale, intatto, di Knuth. Quel processo di unione crea un nuovo file WEB composito che ora contiene il *codice* sorgente del nuovo/software TeX modificato basato su TeX. *I file di modifica* spesso hanno estensione `.ch` ma in pratica possono avere qualsiasi estensione desiderata dagli sviluppatori. #### Come si usano/applicano i file di modifica? Oggi, il modo più semplice per applicare i file di modifica e modificare un file WEB “maestro” è con un programma di utilità chiamato [TIE](https://ctan.org/pkg/tie). Ad esempio, supponiamo che tu voglia modificare il TeX di Knuth aggiungendo, ad esempio, un paio di nuove primitive oppure vuoi cambiare il comportamento di una primitiva TeX esistente (standard). Scriveresti il tuo codice (in Pascal!) usando il sistema WEB di programmazione literate e lo salveresti in un file chiamato, per esempio, `myprim.ch`. Il passo successivo è unire il tuo codice (in `myprim.ch`) con il file sorgente principale di Knuth `tex.web` e produrre un nuovo file WEB composito che rappresenti quello che chiameremo `mytex.web`. Per farlo basta eseguire il programma TIE in questo modo: ``` tie -m mytex.web tex.web myprim.ch ``` Supponendo che l'unione abbia successo, questo produrrà un nuovo file WEB, `mytex.web`lasciando il file sorgente principale di Knuth `tex.web` completamente invariato, come richiesto. Supponiamo ora che qualcun altro apprezzi le modifiche che hai fatto e voglia modificare il tuo lavoro per aggiungere le proprie modifiche sopra, o in aggiunta, a ciò che hai fatto tu. Piuttosto che distribuire la tua versione modificata di TeX (`mytex.web`) decidi di pubblicare/condividere solo il file di modifica, `myprim.ch`. Chiunque voglia costruire sul tuo lavoro può ora creare e condividere il proprio file di modifica chiamato, per esempio, `moreprim.ch` che estende in qualche modo il tuo codice. Chiunque altro voglia beneficiare di entrambi i file di modifica può ora generare un nuovo file WEB composito unendo *entrambi* i file di modifica nel codice sorgente originale di Knuth per generare un altro programma TeX chiamato, per esempio, `newmytex.web`: ``` tie -m newmytex.web tex.web myprim.ch moreprim.ch ``` ### Sistemi TeX reali: più file di modifica La descrizione sopra di TIE è in realtà molto vicina al modo in cui molti motori TeX sono costruiti in pratica: si parte dal `tex.web` di Knuth e si aggiunge una successione di file di modifica per generare il file sorgente WEB di quel motore. Ogni motore TeX richiede il proprio insieme particolare di file di modifica, che devono essere applicati/elaborati (uniti) in un ordine rigoroso: sbagliare l'ordine e il processo di unione fallirà perché ciascun file di modifica in una sequenza si basa sulle modifiche introdotte dai file di modifica che compaiono prima nella catena. Ecco un esempio di esecuzione di TIE che applica più file di modifica al `tex.web` di Knuth per generare `ktex.web`—il file WEB composito con modifiche al TeX di Knuth che lo rendono pronto (adatto) per la conversione in C tramite il processo Web2C. Nota anche quanto segue: * `tex.ch` è un file di modifica molto grande che, tra le altre cose, modifica TeX per usare Kpathsea; * l'estensione SyncTeX viene aggiunta tramite più file di modifica. ``` 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 Questo è TIE, versione CWEB 2.4. Copyright (c) 1989,1992 di THD/ITI. Tutti i diritti riservati. (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.... (Non sono stati trovati errori.) ``` #### A margine: XeTeX e pdfTeX Per completezza, dovremmo notare che il processo di compilazione per pdfTeX e XeTeX in realtà non inizia con il `tex.web`di Knuth; invece inizia con file chiamati `pdftex.web` e `xetex.web` rispettivamente: presumibilmente perché le modifiche sono così estese che ha più senso condividere/pubblicare file WEB che contengono già le modifiche molto significative apportate al codice originale di Knuth. ### Un esempio: e-upTeX La comunità giapponese di TeX ha sviluppato una serie di motori TeX progettati per affrontare le complessità della composizione del testo giapponese: * **pTeX**: motore TeX di Knuth esteso per supportare la composizione giapponese; * **e-pTeX**: una combinazione di e-TeX e pTeX (più alcune primitive introdotte da pdfTeX); * **upTeX**: una versione di pTeX consapevole di Unicode più estensioni per una migliore gestione dei CJK (cinese, giapponese e coreano); * **e-upTeX**: una combinazione (unione) di e-TeX e upTeX. #### Generazione del file sorgente composito per e-upTeX Per creare il file sorgente WEB composito per e-upTeX (con SyncTeX) inizi con il `tex.web` di Knuth ma devi applicare **26** i singoli file di modifica, nel seguente ordine, per ottenere un unico file composito da cui si può estrarre l'elenco dei comandi primitivi: ``` 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 ``` #### Applicare i file di modifica: quali file e in quale ordine? Come notato, è fondamentale applicare/elaborare i file di modifica in un ordine rigoroso—ma come si scopre quali file servono e l'ordine in cui elaborarli? Fortunatamente, quell'informazione cruciale è registrata nei file contenuti nella distribuzione TeX Live e un'esplorazione del codice sorgente di TeX Live ha rivelato le regole che governano i requisiti di compilazione per ciascun motore TeX. Seguendo quelle regole Overleaf è stata in grado di ricostruire il file sorgente WEB composito per ciascun motore TeX ed estrarre un elenco di primitive per l'elaborazione successiva dei dati. ## E infine: come estrarre l'elenco delle primitive? Una volta costruito il file WEB composito, il compito di estrarre l'elenco delle primitive, usando espressioni regolari, è semplice perché tutti i comandi primitivi sono definiti (“registrati”) usando una singola funzione Pascal chiamata `primitive(...)`. Ecco alcuni esempi reali presi dal codice sorgente di Knuth: `tex.web` codice sorgente: ``` 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) ... ... ``` Come puoi vedere, la `primitive(...)` funzione è molto adatta all'elaborazione del testo con espressioni regolari: il nome della primitiva che viene registrata è tra virgolette (`"..."`) insieme a dati aggiuntivi che classificano il comportamento di ciascuna primitiva (non lo considereremo in dettaglio). Dopo aver estratto l'elenco delle primitive per ciascun motore, quei dati sono stati elaborati da alcuni script Lua per generare HTML contenente i risultati in tabella. ### Tornando a LuaTeX Abbiamo notato che LuaTeX non usa esattamente lo stesso processo di compilazione degli altri 8 motori TeX. Dopo aver esplorato brevemente il processo Web2C, la conversione da Pascal a C e il meccanismo dei file di modifica, possiamo ora spiegare dove LuaTeX differisce: gli sviluppatori di LuaTeX decisero di rinunciare al farraginoso processo di conversione da Pascal a C—come notato in [Il manuale di riferimento di LuaTeX](http://www.pragma-ade.com/general/manuals/luatex): > ...il framework di compilazione è web2c e continuiamo a usarlo, ma senza il passaggio da Pascal a C. Il motore centrale di LuaTeX è stato riscritto in C, il che significa che il suo processo di compilazione è in qualche modo più standard e decisamente molto più comodo. Una conseguenza utile è che le primitive supportate da LuaTeX sono ben separabili in un file sorgente C distinto, il che ha notevolmente facilitato il compito di accedervi/elencarle. In senso stretto, dovremmo anche notare che alcuni file sorgente di LuaTeX usano una variante della metodologia di programmazione literate di Knuth, chiamata [CWEB](https://en.wikipedia.org/wiki/CWEB), basata su C e non su Pascal. ### Non solo file WEB: è richiesto altro codice sorgente Dopo aver generato il file sorgente WEB composito per qualsiasi motore TeX (eccetto LuaTeX), il codice sorgente Pascal deve essere estratto e convertito in codice C, ma questa non è la soluzione completa. Oltre al codice C generato dal sorgente WEB (Pascal⮕C), la maggior parte dei motori TeX si affida anche a una serie di file sorgente ausiliari aggiuntivi (librerie) che sono tipicamente scritti in C—come [Kpathsea](https://www.tug.org/kpathsea/). I file sorgente ausiliari (librerie) implementano funzionalità che non è necessario, o non è possibile, scrivere in WEB (Pascal). Qualsiasi cosa scritta nel “linguaggio” WEB per TeX deve usare il linguaggio Pascal, che viene successivamente estratto e convertito in C generato dalla macchina: se non hai bisogno di fare tutto questo, perché non scriverlo semplicemente in C o C++ fin dall'inizio. --- # 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/it/altri-argomenti/18-how-overleaf-created-the-tex-primitive-reference-data.md?ask=&goal= ``` `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.