> 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/articoli-approfonditi/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md). # Una panoramica delle tecnologie che supportano l'uso di font emoji a colori in LaTeX ## Introduzione Questo articolo offre una panoramica di vari [argomenti di contesto](#which-topics-do-we-cover) correlati all’uso dei font OpenType a colori per comporre emoji a colori in LaTeX. Abbiamo cercato di fornire un’ampia gamma di materiali, adatta a un vasto spettro di interessi e competenze. Per mantenere l’articolo gestibile, la nostra trattazione di alcuni argomenti omette molti dettagli tecnici, ma speriamo che ci sia materiale sufficiente a orientare la tua esplorazione della composizione di emoji a colori in LaTeX. **Aggiornamento (luglio 2023)**: Questo articolo è stato pubblicato per la prima volta nell’agosto 2021 e rivisto nel luglio 2023 per aggiornare la sezione su [L’uso di font OpenType a colori basati su SVG con LuaHBTeX](#using-svg-based-opentype-color-fonts-with-luahbtex). ### Quali argomenti trattiamo? Questo articolo tratta i seguenti argomenti generali: * Unicode: lo standard che codifica gli emoji come caratteri e codifica il loro comportamento atteso nelle applicazioni di elaborazione del testo e di composizione tipografica. * Font OpenType a colori: font specializzati che forniscono rappresentazioni colorate dei caratteri emoji visualizzati nel tuo documento LaTeX. * Text shaping: introduzione a un componente fondamentale della composizione tipografica di lingue con script complessi ed emoji. * HarfBuzz: il componente di LuaHBTeX che consente la composizione tipografica multilingue avanzata e l’uso di font OpenType a colori per comporre emoji in LaTeX. * Diversi motori TeX: esplorazione del loro supporto per i font OpenType a colori e scelta del motore TeX da usare. * L’API HarfBuzz di LuaHBTeX: un’introduzione alla “magia” dietro [il text shaping](#the-concept-of-text-shaping) in LuaHBTeX. ### Tre modi per comporre emoji a colori Le emoji a colori possono essere composte con LaTeX usando tre metodi principali: 1. Usare strumenti grafici standard di LaTeX, come TikZ, MetaPost o Asymptote, per disegnare l’emoji. 2. Inserire emoji usando grafiche emoji già preparate e memorizzate in file esterni. 3. Trattare gli emoji come testo codificato in Unicode e usare [il text shaping](#the-concept-of-text-shaping) con [i font OpenType a colori](#opentype-color-fonts) per comporli. Le opzioni pratiche per includere emoji a colori nel tuo documento LaTeX dipendono dal motore TeX usato per compilare quel documento: cioè, se stai usando: * pdfLaTeX: motore pdfTeX + LaTeX; * XeLaTeX: motore XeTeX + LaTeX; * LuaLaTeX: motore LuaHBTeX (a partire da TeX Live 2020) + LaTeX. Tutti e tre questi motori TeX possono usare strumenti o pacchetti LaTeX per disegnare emoji oppure usare `\includegraphics{...}` per inserire emoji memorizzate in file grafici esterni. Disegnare o importare grafica sono tecniche ideali per comporre emoji quando serve una soluzione che non dipenda dal motore TeX usato per compilare il documento LaTeX. Tuttavia, se il tuo flusso di lavoro consente la flessibilità di scegliere un particolare motore TeX e preferisci usare font OpenType a colori ed elaborazione del testo basata su Unicode, la versione più recente di LuaTeX, chiamata LuaHBTeX, è ciò di cui hai bisogno. A partire da TeX Live 2020, LuaHBTeX viene usato per compilare documenti LaTeX basati sul formato LuaLaTeX. ## Contesto su Unicode e sui caratteri emoji ### Codifiche dei caratteri I computer memorizzano, trasmettono ed elaborano il testo usando una sequenza di valori numerici (interi) che rappresentano i *caratteri*costitutivi del testo. Un’elaborazione affidabile del testo richiede che chi produce e chi consuma il testo concordino su quali valori interi debbano essere usati per rappresentare i singoli caratteri all’interno del flusso di testo. In altre parole, qual è la *carattere* *codifica?* Una codifica è l’insieme di valori interi concordati assegnati per rappresentare un certo insieme di caratteri: ogni carattere è rappresentato da un valore intero all’interno della codifica in uso. ### Entra Unicode Storicamente, nell’era del testo a 8 bit, venivano usate molte codifiche di caratteri diverse, con il costante spettro di *mismatch di codifica*: chi produce e chi consuma il testo che assumono erroneamente codifiche diverse, con conseguenti errori nell’elaborazione del testo. Chiunque abbia lavorato con TeX/LaTeX per alcuni anni avrà probabilmente incontrato mismatch di codifica tra il testo di input e i font usati per comporre un documento. Se i font del documento sono configurati per usare una codifica diversa da quella del testo, è probabile che nel PDF composto risultino caratteri mancanti o errati. Questi problemi storici di codifica possono essere risolti usando uno standard internazionale che codifica tutti i caratteri del mondo: Unicode. Lo standard Unicode non è statico, ma viene aggiornato periodicamente per includere ulteriori caratteri e script (sistemi di scrittura) all’interno del suo schema di codifica. Esiste un [processo formale di revisione per proporre nuovi caratteri](http://www.unicode.org/pending/proposals.html) con uno specifico [schema per nuovi caratteri emoji](https://www.unicode.org/emoji/proposals.html). ### Quanti caratteri Unicode? Unicode codifica un massimo teorico di 1.114.112 caratteri. Ognuno dei 1.114.112 valori interi è chiamato un *code point*: il valore intero assegnato per identificare ciascun carattere. Tuttavia, per vari motivi tecnici, solo [1.112.064 code point](https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology) possono essere assegnati a caratteri effettivi: 2048 code point non sono assegnabili e sono vietati per l’uso all’interno di testo conforme a Unicode. Al momento della stesura (la prima versione di questo articolo), la versione 13 dello standard Unicode aveva assegnato in totale 143.859 code point a caratteri effettivi, inclusi [3304 caratteri ora codificati come emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (vedi pagina 2 di quel documento). La crescita del numero di caratteri codificati da Unicode è ben documentata nell’articolo [Quanti caratteri Unicode esistono?](https://www.babelstone.co.uk/Unicode/HowMany.html) e in una [voce di Wikipedia](https://en.wikipedia.org/wiki/Unicode#Versions). ### Piani Unicode L’intera raccolta di 1.114.112 code point Unicode è raggruppata in 17 cosiddetti Piani: dal Piano 0 al Piano 16, ciascuno contenente 65536 valori di code point, per un totale di $$17\times2^{16} = 1,114,112$$ caratteri. Il Piano 0, chiamato [Piano Multilingue di Base](https://en.wikipedia.org/wiki/Plane_\(Unicode\)#Basic_Multilingual_Plane), codifica i caratteri più usati comunemente. I Piani 1–16 sono chiamati [Piani Supplementari](http://unicode.org/glossary/#supplementary_planes). ### L’ascesa degli emoji Nuovi caratteri nascono dai cambiamenti nelle modalità della comunicazione umana, e la tecnologia dei telefoni cellulari ha dato origine a uno di questi insiemi di caratteri: gli emoji, che si sono evoluti in Giappone alla fine degli anni ’90. Non sorprende che la [FAQ di Unicode sugli emoji](https://unicode.org/faq/emoji_dingbats.html) osservi > “La parola emoji deriva dal giapponese [絵](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E7%B5%B5) (e ≅ immagine) + [文字](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E6%96%87) (moji ≅ carattere scritto).” I lettori interessati al contesto e allo sviluppo storico degli emoji potrebbero trovare interessante questa [introduzione a Unicode](https://unicode.org/reports/tr51/#Introduction) o l’articolo [I second that emoji: gli standard, le strutture e la produzione sociale degli emoji](https://firstmonday.org/ojs/index.php/fm/article/view/9381). Non è stato che nel 2010, con il rilascio di [la versione 6.0 dello Standard Unicode](https://www.unicode.org/versions/Unicode6.0.0/), che molti emoji sono stati formalmente riconosciuti come *caratteri* a pieno titolo. Unicode 13.0 ha codificato [3304 caratteri come emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (vedi pagina 2 di quel documento), mentre Unicode 13.1 elenca [elenca 3521 emoji](https://unicode.org/emoji/charts/emoji-counts.html). ### Gli emoji vivono su un piano più alto Unicode ha assegnato molti caratteri emoji a code point al di fuori del Piano Multilingue di Base (BMP), codificati [nel Piano 1](https://en.wikibooks.org/wiki/Unicode/Character_reference/1F000-1FFFF) con code point nell’intervallo 1F000–1FFFF, il che ha una conseguenza importante per chiunque voglia *copiare e incollare* caratteri emoji negli editor di Overleaf (Code Editor o Visual Editor). Gli editor di testo di Overleaf possono gestire solo caratteri all’interno del Piano Multilingue di Base, anche se speriamo che futuri aggiornamenti introdurranno il supporto per i caratteri non BMP. Nota che questa limitazione riguarda solo i caratteri non BMP all’interno del testo incollato nei file destinati a essere modificati tramite gli editor di Overleaf. Ci sono altri modi per accedere ai caratteri emoji: * Usando i comandi primitivi `\char"` o `\Uchar"` (vedi [questa sezione](#optional-detail-luatexluahbtex-char-vs-uchar) dell’articolo). * Usando file di testo di input contenenti caratteri emoji in formato UTF-8. * Usando comandi LaTeX (macro) che inseriscono caratteri emoji. #### Incollare emoji e altri caratteri non BMP in Overleaf Se incolli un carattere emoji, per esempio 😀, nell’editor Code di Overleaf, al momento verrà convertito nei caratteri ��. ![Errore dovuto al copia + incolla di caratteri non BMP negli editor di Overleaf](/files/2c1a975bb3ffe9e8c659bb7b18f6ad6dcb65764c) Il carattere � ha il code point Unicode FFFD e il suo nome ufficiale è REPLACEMENT CHARACTER ed è usato per “[sostituire un carattere sconosciuto, non riconosciuto o non rappresentabile](https://en.wikipedia.org/wiki/Specials_\(Unicode_block\))”. ### Uso dei code point Unicode (U+) in LuaLaTeX La documentazione Unicode rappresenta i valori dei code point usando la notazione `U+`—come `U+1F600`, dove `1F600` è il `` del code point Unicode per il carattere emoji 😀. Per usare questi valori di code point in LuaLaTeX, devi eliminare il `U+` e scrivere `\char"` o `\Uchar"`. Il `"` indica a un motore TeX che il numero fornito è specificato in esadecimale. Per esempio, per usare l’emoji 😀, scriveresti `\char"1F600` o `\Uchar"1F600`—usando un font capace di comporla tipograficamente. Un esempio minimo di LuaLaTeX che usa `\char` e `\Uchar` per comporre il carattere emoji 😀 potrebbe essere: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz]{NotoColorEmoji.ttf} %Usa \emojifont in un gruppo per mantenere locali i suoi effetti {\emojifont \Uchar"1F600 \char"1F600} \end{document} ``` [Apri questo esempio LuaLaTeX in Overleaf](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Test+using+LuaLaTeX\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%5BRenderer%3DHarfbuzz%5D%7BNotoColorEmoji.ttf%7D%0A%25Use+%5Cemojifont+in+a+group+to+keep+its+effects+local%0A%7B%5Cemojifont+%0A%5CUchar%221F600%0A%5Cchar%221F600%7D%0A%5Cend%7Bdocument%7D) **(dettaglio opzionale) LuaTeX/LuaHBTeX: \char vs \Uchar** Oltre al convenzionale `\char` comando per comporre tipograficamente un specifico ``, usando il font corrente, i motori LuaTeX, LuaHBTeX e XeTeX forniscono anche il comando `\Uchar` Dal punto di vista dell’utente, il risultato di `\char` e `\Uchar` sembra uguale, ma esiste una sottile differenza nel modo in cui questi comandi funzionano, come notiamo di seguito. **La differenza chiave: espansione** `\Uchar` è un cosiddetto [comando espandibile](/latex/it/articoli-approfonditi/22-how-does-expandafter-work-the-meaning-of-expansion.md#expansion-a-general-term-for-a-set-of-operations) mentre `\char` non lo è. Quando un `\char` o `\Uchar` comando viene “eseguito” — cioè, il comando non viene memorizzato come parte di una macro o di un altro elenco di token — all’interno del motore TeX avvengono le seguenti azioni: * **`\char`** ordina al motore TeX di inserire immediatamente un token di carattere, che rappresenta ``, in qualunque contenuto stia attualmente componendo tipograficamente. * Al contrario, **`\Uchar`** ha due fasi di elaborazione distinte: 1. La `\Uchar` il comando viene *espanso*e il `` viene convertito in un elenco temporaneo di token contenente un singolo [token di carattere](/latex/it/articoli-approfonditi/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md#tex-tokens-101-28and-notions-of-expansion29) che rappresenta il ``. 2. Quel singolo elenco di token di un carattere è ora *reso disponibile* al motore TeX come sorgente del suo prossimo input. In effetti, il motore TeX “sposta temporaneamente il proprio sguardo” per usare quell’elenco di un solo token come posizione del suo prossimo elemento di input (token). Per impostazione predefinita, il motore TeX torna semplicemente a leggere (input) quel token e a comporre il carattere corrispondente, riproducendo il comportamento di `\char` comando. **Tuttavia**, poiché quel `` non è stato composto immediatamente, ma temporaneamente *memorizzati* (salvato) come un singolo token, i comandi primitivi TeX o le macro LaTeX possono fare uso (assorbire) di quel token — non deve essere composto subito, ma può essere usato in ulteriori elaborazioni secondo necessità. In effetti, `\char` dice “componi tipograficamente questo `` ora,” mentre `\Uchar` ha una forma di “azione ritardata” creando un token di carattere memorizzato e rendendolo disponibile come elemento di input successivo (un token). Quel token può essere usato (assorbito) dai comandi e dalle macro TeX oppure riletto dal motore TeX e composto tipograficamente. ### Unicode (codifica) non racconta tutta la storia La possibilità di usare caratteri emoji all’interno di testo codificato in Unicode è solo una parte della storia di successo degli emoji. L’aumento nell’uso degli emoji è stato reso possibile anche dallo sviluppo della [tecnologia dei font OpenType](https://learn.microsoft.com/en-us/typography/opentype/)—font i cui dati dei glifi (disegni dei caratteri) possono contenere [dati colore](https://learn.microsoft.com/en-us/typography/opentype/spec/colr): i cosiddetti [i font OpenType a colori](#opentype-color-fonts). Oltre a font adatti, l’uso di emoji a colori richiede componenti software aggiuntivi i cui compiti includono: * pre-elaborare (“[shaping](#the-concept-of-text-shaping)”) il testo codificato in Unicode, *prepararlo* per la visualizzazione usando un particolare font; * *renderizzazione e visualizzazione* dei glifi colorati emoji di un font *glifi* sullo schermo di un dispositivo. #### Glifo vs. carattere: non sono la stessa cosa? I termini “glifo” e “carattere” sono spesso usati come se fossero intercambiabili — riferendosi allo stesso concetto di base — ma esiste una differenza sottile, anche se importante, nel loro significato. Unicode [definisce il termine “carattere”](http://www.unicode.org/glossary/#character) come: > “Il più piccolo componente del linguaggio scritto che ha valore semantico; si riferisce al significato astratto e/o alla forma, piuttosto che a una forma specifica… ” Al contrario, un “glifo” è una *specifica* *forma* (disegno) per la *rappresentazione visiva* di un particolare *carattere*. La questione carattere vs. glifo si osserva facilmente quando testo ricco di emoji viene visualizzato su vari sistemi/piattaforme software, ad esempio leggendo lo stesso testo sul tuo telefono cellulare basato su iOS o Android oppure su un computer desktop Windows. Qualunque dispositivo o piattaforma venga usato, il testo sottostante (sequenza di caratteri) conterrebbe gli stessi *emoji* *caratteri*codificati in Unicode. Sono le capacità specifiche del dispositivo coinvolte nella *pre-elaborazione* di quel testo che poi *renderizzazione* e *display* dei risultati, forse usando font specifici del dispositivo, a produrre glifi diversi (disegni dei caratteri) per rappresentare gli stessi caratteri emoji. La [Full Emoji List](https://unicode.org/emoji/charts/full-emoji-list.html) di Unicode fornisce immagini di esempio che rappresentano ciascun carattere emoji Unicode — mostrando vari glifi usati da diversi fornitori di tecnologia. Non solo i progettisti di font adottano i propri disegni particolari (glifi) per rappresentare i caratteri emoji, ma i singoli font variano anche nel numero di caratteri emoji che supportano (per i quali contengono glifi) e possono contenere oppure no funzionalità più avanzate di elaborazione testo-emoji incluse nelle specifiche Unicode per gli emoji. La nozione e il concetto di caratteri, la loro semantica e la loro codifica, costituiscono la base del mondo Unicode: esso si occupa di caratteri. Il design e la rappresentazione visiva dei singoli caratteri, come glifi, appartengono alle tecnologie dei font e all’arte della progettazione dei font. #### Emoji Unicode: molto più della codifica del testo Il ruolo centrale di Unicode è fornire uno standard globale di codifica che definisca quale valore intero, chiamato *code point,* debba essere usato per rappresentare ciascun carattere, inclusi gli emoji, all’interno di un flusso di testo codificato in Unicode. La specifica Unicode per gli emoji definisce anche *comportamenti di elaborazione* per certi *sequenze* dei caratteri emoji che compaiono all’interno di un flusso di testo codificato in Unicode. Sequenze definite di caratteri emoji possono essere “unite” tramite un processo chiamato [il text shaping](#the-concept-of-text-shaping) per produrre un singolo glifo emoji risultante (“composito”) — quel singolo glifo sarebbe usato dal sistema operativo del dispositivo per rappresentare la sequenza originale di caratteri presente nel testo. Il rapporto tecnico di Unicode su [Unicode Emoji](https://unicode.org/reports/tr51/) documenta il ricco insieme di funzionalità disponibili per il software che desidera fornire un’elaborazione conforme a Unicode dei caratteri emoji. Come esempio, Unicode definisce (codifica) caratteri chiamati [modificatori emoji](http://www.unicode.org/reports/tr51/#Emoji_Modifiers_Table) che possono essere usati per generare *varianti* dei caratteri emoji “di base”, come le variazioni nel [tono della pelle basate sulla scala Fitzpatrick](http://www.unicode.org/reports/tr51/#Diversity). Nota che l’insieme dei caratteri emoji di base e i modificatori applicabili sono definiti come parte dello [standard Unicode per gli emoji](http://www.unicode.org/reports/tr51). La pagina Unicode [Emoji Sequences](http://unicode.org/emoji/charts/emoji-sequences.html) fornisce un grafico delle sequenze attualmente previste dalla specifica Unicode. Posiziona il puntatore del mouse su qualsiasi immagine di glifo emoji per vedere un piccolo tooltip pop-up che ti indica la sequenza sottostante di caratteri emoji Unicode che produce quel glifo: ![EmojiSequenceChart.png](/files/2a5c13e75f3ed59dff2cbf2c701cfca46d093f75) Per esempio, il glifo emoji: ![HandMediumSkinTone.png](/files/1a065b83e013a3e8f3c8597a20a3bad67f0d8269) è elencato nella [sezione delle sequenze di modificatori](http://unicode.org/emoji/charts/emoji-sequences.html#modifier_sequences) ed è prodotto dalla sequenza di due caratteri U+1F44B U+1F3FD. Quei caratteri componenti sono: U+1F44B:![UnicodeWavingHandDefault.png](/files/c9da39f3413b888d43b7f354ab8396d30614ef06) (MANO CHE SALUTA) U+1F3FD:![FitzPatrick3.png](/files/c318381c23326344704f561bc0ad1003306bc443) (MODIFICATORE EMOJI FITZPATRICK TIPO-4) **Uso dei modificatori del tono della pelle in LuaHBTeX** L’esempio seguente usa LuaHBTeX per dimostrare l’uso dei modificatori emoji: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=HarfBuzz,SizeFeatures={Size=20}]{NotoColorEmoji.ttf} Mano che saluta isolata: {\emojifont\Uchar"1F44B}\par Modificatore isolato: {\emojifont\Uchar"1F3FD}\par Risultato combinato: {\emojifont\Uchar"1F44B\Uchar"1F3FD} \end{document} ``` [Apri questo esempio di modificatori emoji LuaLaTeX in Overleaf](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Emoji+modifiers+using+LuaLaTeX\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%5BRenderer%3DHarfBuzz%2CSizeFeatures%3D%7BSize%3D20%7D%5D%7BNotoColorEmoji.ttf%7D%0AIsolated+waving+hand%3A+%7B%5Cemojifont%5CUchar%221F44B%7D%5Cpar%0AIsolated+modifier%3A+%7B%5Cemojifont%5CUchar%221F3FD%7D%5Cpar+%0ACombined+result%3A+%7B%5Cemojifont%5CUchar%221F44B%5CUchar%221F3FD%7D%0A%5Cend%7Bdocument%7D) Questo esempio produce il seguente output: ![ModifiersInLuaHBTeX.png](/files/f53b0fcb7c919f2e3c7fb9b513033a80ca80a17a) #### UTF-8: il suo ruolo nella memorizzazione del testo Unicode Qualsiasi testo o codice che digiti o incolli nell’editor Code di Overleaf (o nell’editor Visual) verrà memorizzato in formato UTF-8, quindi esamineremo brevemente cosa significhi effettivamente UTF-8. UTF sta per Unicode Transformation Format, e il ruolo di UTF-8 nella memorizzazione o trasmissione di testo codificato in Unicode è indicato dall’espressione “Transformation *Format*.” I valori dei code point Unicode vanno da 0 a un massimo di 1.114.111, quindi è impossibile rappresentare tutti i valori dei caratteri Unicode usando un singolo byte a 8 bit, che può memorizzare solo fino a 256 valori diversi: da 0 a 255. Tuttavia, è possibile rappresentare qualsiasi intero code point Unicode usando una *sequenza consecutiva* di valori di dimensione byte — che è il principio alla base di UTF-8. UFT-8 fornisce una “ricetta” per *trasformare* (cioè per “codificare” o “convertire”) un valore intero di code point Unicode in una sequenza univoca di 1 a 4 interi consecutivi di dimensione byte: il numero di byte consecutivi richiesti dipende dal valore dell’intero code point. Di conseguenza, potresti leggere che UTF-8 memorizza i caratteri Unicode come *sequenze multibyte* poiché un singolo carattere Unicode (intero code point) è rappresentato in UTF-8 come una sequenza di 1 a 4 byte consecutivi. Naturalmente, il testo memorizzato in UTF-8 può essere convertito di nuovo nella sua sequenza originale di valori interi di code point Unicode — ed è ciò che devono fare XeTeX o LuaTeX/LuaHBTeX quando leggono un file di input LaTeX memorizzato in formato UTF-8. Questi motori TeX devono conoscere i valori Unicode (caratteri) del code point di input prima di poter comporre tipograficamente il testo. Nota che pdfTeX non ha una capacità integrata di decodifica UTF-8, quindi deve fare affidamento sulle macro TeX per elaborare (decodificare) il testo di input formattato in UTF-8. **Alcuni esempi di UTF-8** * Il carattere arabo ش (“sheen”) ha il code point Unicode 0634 in esadecimale (base 16) o 1588 in decimale (base 10). In UTF-8 ش è rappresentato da 2 valori (esadecimali) D8 e B4, quindi il carattere ش verrebbe memorizzato come i due byte consecutivi D8B4 all’interno di testo codificato in UTF-8. * Il carattere emoji 😀 ha il code point Unicode 1F600 in esadecimale (base 16) o 128512 in decimale (base 10). In UTF-8 😀 è rappresentato da 4 valori (esadecimali) F0, 9F, 98 e 80, quindi il carattere 😀 verrebbe memorizzato come i 4 byte consecutivi F09F9880 all’interno di un file di testo UTF-8. #### Caratteri speciali usati nell’elaborazione del testo emoji basata su Unicode Non ogni carattere codificato in Unicode è destinato alla presentazione visiva tramite i glifi di un font: alcuni caratteri codificati sono designati come *caratteri non stampabili* il cui scopo è aiutare funzioni specializzate di elaborazione del testo (nel software che le supporta). Diverse applicazioni software forniscono livelli variabili di supporto per i caratteri non stampabili codificati in Unicode, quindi il risultato dipenderà dall’ambiente software — applicazioni e font — in uso. **Due caratteri non stampabili da conoscere** * **Zero width joiner (ZWJ)**, code point 200D (esadecimale), come suggerisce il nome, è progettato per attivare il “comportamento di unione” dei caratteri di input — ma solo se quei caratteri di input *possiedono* un comportamento di unione definito. * **Zero width non-joiner (ZWNJ)**, code point 200C (esadecimale), è progettato per *impedire* il “comportamento di unione” che i caratteri di input potrebbero altrimenti mostrare. Per esempio, puoi usare lo ZWNJ per impedire il comportamento di unione di caratteri arabi consecutivi che normalmente verrebbero elaborati (shaped) nelle loro forme di unione. Unicode ha pubblicato un elenco di [Recommended Emoji ZWJ Sequences](https://unicode.org/emoji/charts/emoji-zwj-sequences.html) che usano un U+200D ZERO WIDTH JOINER (ZWJ) per combinare sequenze di caratteri emoji in un singolo glifo emoji composito — se è disponibile nel/i font usato/i. **Esempio di utilizzo dello zero width non-joiner** Il seguente frammento minimo di codice usa il font OpenType Scheherazade, incluso in TeX Live, per definire un font LaTeX chiamato `\arabicfont` che possiamo usare per comporre tipograficamente dell’arabo. La riga ```latex {\arabicfont Non-joining:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} ``` usa un carattere zero width non-joiner, tramite `\Uchar"200C`, per impedire il normale comportamento di unione delle due lettere arabe ل (lam) e ا (alef). Nota l’uso di `\textdir TRT` per impostare la direzione del testo da destra a sinistra: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\arabicfont[Script=Arabic,Renderer=Harfbuzz,SizeFeatures={Size=40}]{Scheherazade} {\arabicfont Joining:\textdir TRT\Uchar"0644\Uchar"0627}\par {\arabicfont Non-joining:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} \end{document} ``` [Apri questo esempio LuaLaTeX in Overleaf](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Zero+width+non-joiner+using+LuaLaTeX\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Carabicfont%5BScript%3DArabic%2CRenderer%3DHarfbuzz%2CSizeFeatures%3D%7BSize%3D40%7D%5D%7BScheherazade%7D%0A%7B%5Carabicfont+Joining%3A%5Ctextdir+TRT%5CUchar%220644%5CUchar%220627%7D%5Cpar%0A%7B%5Carabicfont+Non-joining%3A%5Ctextdir+TRT%5CUchar%220644%5CUchar%22200C%5CUchar%220627%7D%0A%5Cend%7Bdocument%7D) Questo esempio produce il seguente output: ![NonJoiner.png](/files/2c0f33f11be8e11447a65aad962b20780d050e0e) ## Il concetto di “text shaping” Cominciamo con un esempio visivo usando una traduzione in urdu della parola “educational”. Il testo della traduzione in urdu potrebbe essere digitato su una tastiera o su un dispositivo touchscreen e sarebbe creato come una semplice sequenza lineare di caratteri arabi Unicode. Tuttavia, quando quel testo viene composto tipograficamente, o visualizzato sullo schermo di un dispositivo nel [stile Nastaliq](https://en.wikipedia.org/wiki/Nastaliq), il risultato è una complessa disposizione bidimensionale di glifi. Usando il nostro esempio in urdu, la seguente grafica confronta l’input lineare di Unicode arabo *caratteri* con l’output composto in stile Nastaliq, comprendente una disposizione bidimensionale di *glifi* presenti nel font (libero) [Awami Nastaliq](https://software.sil.org/awami/download/): ![](/files/a0638a81761a0696f9099130261a420a0ebda104) Il processo di “tradurre” i caratteri di input in un insieme di glifi di output correttamente posizionati si chiama *il text shaping*, ed è una componente vitale dell’elaborazione del testo prima della sua visualizzazione o composizione tipografica. Il nostro esempio ha usato testo nella lingua urdu (script arabo) perché il risultato dello shaping è chiaramente evidente, a differenza delle lingue che usano lo script latino, come l’inglese, dove lo shaping è molto meno pronunciato — per esempio nella produzione di semplici legature. Il text shaping è essenziale quando si usano script (sistemi di scrittura) come [Arabo](https://en.wikipedia.org/wiki/Arabic), [Ebraico](https://en.wikipedia.org/wiki/Hebrew_language), [Devanagari](https://en.wikipedia.org/wiki/Devanagari) o [Malayalam](https://en.wikipedia.org/wiki/Malayalam), solo quattro esempi dei cosiddetti *script complessi*. Per garantire una corretta presentazione del testo in quegli script, e nelle lingue che li usano, il processo di shaping deve affrontare con attenzione eventuali regole e sfumature di shaping presenti nella particolare combinazione di script e lingua. Per esempio, alcune lingue richiedono che più caratteri di input generino un particolare glifo di output, oppure potrebbero esserci requisiti complessi per il posizionamento accurato dei segni diacritici e riordinamenti tra glifi, per garantire che i singoli glifi siano posizionati correttamente (gli uni rispetto agli altri). In generale, lo shaping di un pezzo di testo richiede diverse informazioni: * Il sistema di scrittura o *sistema di scrittura* in cui il testo è scritto. * Il sistema di scrittura specifico *lingua* in uso. Singoli sistemi di scrittura possono essere usati per più lingue, e ogni combinazione sistema di scrittura-lingua presenta proprie sottigliezze/sfumature di composizione. * Il sistema di scrittura *direzione* del testo—ad esempio da destra a sinistra o da sinistra a destra. * Un *carattere* che fornisce i glifi necessari per rappresentare il testo composti e, facoltativamente, contiene ulteriori “regole di composizione” che guidano il processo di composizione del testo. Le esigenze della composizione del testo, in particolare per i sistemi di scrittura complessi e le lingue a essi associate, possono essere estremamente dettagliate e sfumate, indicando la necessità di software specializzato in grado di applicare “regole” di composizione del testo potenzialmente molto complesse. Non sorprende che un tale software esista ed è chiamato un *motore di composizione del testo*; quello di cui parleremo si chiama [HarfBuzz](https://en.wikipedia.org/wiki/HarfBuzz), la cui documentazione merita di essere letta—ad esempio [Perché ho bisogno di un motore di composizione?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html). **Ulteriori letture sulla composizione del testo** Queste brevi introduzioni sono altamente raccomandate: * [Che cos’è la composizione del testo?](https://harfbuzz.github.io/what-is-harfbuzz.html#what-is-text-shaping) * [Perché ho bisogno di un motore di composizione?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html) **Nota tecnica: tecnologie di composizione multiple (modelli)** Il motore di composizione del testo HarfBuzz supporta diverse “tecnologie di composizione” che differiscono nel modo in cui implementano il processo di composizione—ogni implementazione è definita un *compositore*, incluse anche nella documentazione di `luaotfload` . L’obiettivo principale di questo articolo è la composizione OpenType, ma una tecnologia alternativa e utilizzabile gratuitamente è [Graphite](https://scripts.sil.org/cms/scripts/page.php?site_id=projects\&item_id=graphite_aboutOT), sviluppata da [SIL International](https://www.sil.org/). Un altro modello di composizione supportato da HarfBuzz è [Apple Advanced Typography (AAT)](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html)—i font che supportano AAT sono in genere utilizzati sulle piattaforme tecnologiche Apple. **Esempio di utilizzo del compositore Graphite** L’esempio seguente compone un po’ di testo urdu usando un font chiamato [Awami Nastaliq](https://software.sil.org/awami/download/), che supporta la composizione Graphite ed è disponibile su Overleaf. Awami Nastaliq è creato da [SIL International](https://www.sil.org/), l’organizzazione responsabile dello sviluppo della tecnologia Graphite. L’esempio seguente dimostra la capacità avanzata di composizione dei font basati su Graphite—si noti come la `luaotfload` dichiarazione del font selezioni la composizione Graphite usando `shaper=graphite2`. ```latex \documentclass{article} \usepackage{luaotfload} \begin{document} \font\urdutest={file:AwamiNastaliq-Regular.ttf:mode=harf;shaper=graphite2} at 100bp % Tecnologia \pardir TRT\textdir TRT \urdutest ٹیکنالوجی \vskip 75bp % Didattico \pardir TRT\textdir TRT \urdutest تعلیمی \end{document} ``` [Apri questo esempio in Overleaf.](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Typesetting+Urdu+using+the+Graphite+shaper\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bluaotfload%7D%0A%5Cbegin%7Bdocument%7D%0A%0A%5Cfont%5Curdutest%3D%7Bfile%3AAwamiNastaliq-Regular.ttf%3Amode%3Dharf%3Bshaper%3Dgraphite2%7D+at+100bp%0A%25+Technology%0A%5Cpardir+TRT%5Ctextdir+TRT+%5Curdutest+%D9%B9%DB%8C%DA%A9%D9%86%D8%A7%D9%84%D9%88%D8%AC%DB%8C%0A%0A%5Cvskip+75bp%0A%0A%25+Educational%0A%5Cpardir+TRT%5Ctextdir+TRT+%5Curdutest+%D8%AA%D8%B9%D9%84%DB%8C%D9%85%DB%8C%0A%5Cend%7Bdocument%7D) Questo esempio produce il seguente output: ![](/files/685bcee00ef7f1483ff1bbb9c944779e60d7500b) #### Emoji e composizione del testo La composizione del testo è stata introdotta usando esempi tratti da una lingua con sistemi di scrittura complessi, l’urdu. Tuttavia, potrebbe sorprendere sapere che la resa corretta dei glifi emoji richiede che la composizione del testo venga applicata a testo Unicode contenente sequenze di caratteri emoji—[come osservato dallo sviluppatore principale di HarfBuzz](https://github.com/harfbuzz/harfbuzz/issues/2428#issuecomment-639108677): > ...comporre gli emoji con HarfBuzz rientra pienamente nell’ambito ed è in realtà necessario per ottenere emoji di famiglia, tonalità della pelle, ecc. Esamineremo alcuni esempi di questo. ### Divisione delle responsabilità: motore di composizione del testo + font OpenType In pratica, la composizione del testo è un’“operazione congiunta”, o una divisione del lavoro, tra la logica e le regole integrate nel motore di composizione del testo e le ulteriori regole e dati di composizione integrati nel/i font in uso—da questo momento in poi trattiamo la composizione basata su OpenType *solo*. Per eseguire la composizione, al motore di composizione del testo vengono in genere forniti del testo Unicode, un sistema di scrittura e una lingua specificati, eventualmente una direzione di scrittura e, soprattutto, un font OpenType da usare durante il processo di composizione—il font fornirà l’output: un insieme di glifi e dati di posizionamento. Se richiesto, il motore di composizione può applicare regole aggiuntive ([funzionalità OpenType](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features)) contenute nel font OpenType in uso—quali regole applicare sono di solito selezionabili dall’utente dall’elenco delle funzionalità supportate dal font. Il risultato del processo di composizione è un *elenco di glifi* contenuti nel font OpenType, insieme a *tra glifi* dati di posizionamento. Quei dati di posizionamento riguardano *il posizionamento relativo dei glifi composti*; non si riferiscono a un posizionamento assoluto all’interno della pagina composta o di altri supporti/contenuti come una pagina web, un tweet, ecc. Il software di rendering (motore di composizione tipografica, browser web, ecc.) utilizza le informazioni di posizionamento tra i glifi per garantire che i glifi siano posizionati correttamente l’uno rispetto all’altro dopo essere stati assemblati e incorporati nell’output finale. #### Che cos’è un elenco di glifi? Internamente, a ogni glifo all’interno di un font OpenType viene assegnato un identificatore numerico, un valore intero chiamato indice del glifo—chiamato anche identificatore del glifo o GID. Dopo aver completato il suo compito di composizione, il motore di composizione del testo restituirà i risultati come un *elenco di identificatori di glifo* più *dati di posizionamento* per quei glifi. Ai singoli glifi all’interno dei font OpenType vengono assegnati indici (identificatori) dal creatore del font, rendendo questo valore altamente specifico del font e arbitrario—potrebbe anche variare tra le versioni di uno specifico font. Non si dovrebbe mai presumere che lo stesso valore GID si applichi a glifi “simili” in font diversi; quasi certamente non sarà così. Se si dispone di un elenco di identificatori di glifo fornito da un motore di composizione, li si può usare solo per accedere ai glifi nel font da cui sono stati ottenuti. #### Che cosa sono i font OpenType? Il web è *pieno* di spiegazioni e dettagli sui font OpenType, quindi ci limiteremo a una breve descrizione. La [specifica OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/) è un documento complesso progettato per gli sviluppatori, ma, in sostanza, definisce un formato di file, o contenitore, per i dati dei font. Un font OpenType contiene dati che descrivono le forme dei glifi, insieme a informazioni sul/i sistema/i di scrittura e sulla/e lingua/e supportati/e, metadati sul font e varie “tabelle” che definiscono [le funzionalità tipografiche](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features) supportate dal font. Di solito, a un motore di composizione del testo può essere istruito di applicare selettivamente (usare) le funzionalità di un font durante il processo di composizione, applicando effetti tipografici specifici (“regole”) che selezionano l’insieme appropriato di glifi contenuti nel font. Il font scelto dovrà supportare, e fornire i glifi per, tutte le funzionalità che il motore di composizione del testo è chiamato ad applicare. #### Glifi “codificati” e “non codificati” I font OpenType includono una tabella di dati chiamata [cmap](https://docs.microsoft.com/en-us/typography/opentype/spec/cmap) (Character to Glyph Index Mapping) che mappa l’insieme dei caratteri Unicode, supportati dal font, al corrispondente indice del glifo in quel font. Il video seguente offre un breve sguardo alla tabella cmap contenuta in un font chiamato `lmmono10-regiular.otf` (incluso in TeX Live). {% embed url="" %} Tuttavia, i font in genere contengono molti glifi che non rappresentano un carattere Unicode specifico e non sono inclusi come parte di quella tabella cmap. Di conseguenza, l’insieme dei glifi presenti in un font OpenType può essere diviso in due insiemi principali: * glifi codificati che rappresentano caratteri Unicode; * glifi non codificati che non rappresentano caratteri Unicode. Ai glifi codificati si può accedere includendo il carattere Unicode appropriato nel testo—ma che dire dei glifi non codificati, come vengono usati/accessibili? Quei glifi sono tipicamente usati per fornire l’output delle operazioni di composizione del testo, compresa l’applicazione di funzionalità del font per produrre effetti visivi/tipografici specifici. ### i font OpenType a colori I caratteri emoji dovrebbero visualizzarsi/renderizzarsi a colori completi—gli emoji in bianco e nero non offrono proprio la “piena esperienza emoji”. Tuttavia, al momento della codifica iniziale degli emoji da parte di Unicode, la [specifica del font OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/) non prevedeva alcuna disposizione adatta per incorporare *colorful*dati di glifo all’interno dei font OpenType. Questa “lacuna” in OpenType spinse i principali fornitori di tecnologia/piattaforme a cercare soluzioni, e la successiva “corsa” portò a [varie proposte per estendere OpenType](https://www.fontlab.com/news/color-font-format-proposals/) per supportare i font color OpenType—non solo per visualizzare caratteri emoji a colori (glifi) ma per rendere qualsiasi glifo a colori. #### Quattro varianti di font color OpenType [Adobe, Microsoft, Google e Apple presentarono ciascuna proposte](https://www.fontlab.com/news/color-font-format-proposals/) per estendere OpenType per supportare font OpenType a colori completi e, alla fine, furono adottate quattro proposte e incluse nella specifica formale OpenType. Per comodità, possiamo raggruppare in modo approssimativo queste quattro varianti in base vettoriale e raster-based—ma, come mostrato in questo [repository GitHub](https://github.com/simoncozens/test-fonts), la specifica OpenType è sufficientemente flessibile da supportare file di font color OpenType che combinano quelle quattro tecnologie di base. * **Font OpenType basati su vettori:** * **Microsoft**: le forme dei glifi sono descritte usando una forma di vettori colorati stratificati ([COLR](https://docs.microsoft.com/en-us/typography/opentype/spec/colr) e [CPAL](https://docs.microsoft.com/en-us/typography/opentype/spec/cpal) tabelle). * [**Adobe e Mozilla**](https://www.w3.org/2013/10/SVG_in_OpenType/) ([tabella SVG](https://docs.microsoft.com/en-us/typography/opentype/spec/svg)): le forme dei glifi sono disegnate usando SVG, che supporta glifi costruiti da vettori *e immagini raster*. Vedi anche [la guida utente di Adobe sui font SVG](https://helpx.adobe.com/fonts/user-guide.html/fonts/using/ot-svg-color-fonts.ug.html). * **Font OpenType basati su raster:** * **Google**: i glifi sono rappresentati da immagini PNG a colori incorporate nel font ([CBDT](https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt) e [CBLC](https://docs.microsoft.com/en-us/typography/opentype/spec/cblc) tabelle). * **Apple**: anche i glifi sono rappresentati da immagini a colori incorporate nel font. Oltre a PNG, il meccanismo di Apple ([tabella sbix](https://docs.microsoft.com/en-us/typography/opentype/spec/colr)) supporta anche JPEG e TIFF. Di conseguenza, i sistemi operativi e i software applicativi che supportano i font color OpenType devono fare i conti con l’attuale panorama tecnologico misto. Inoltre, si dovrebbe essere consapevoli che i singoli font color OpenType—e *le versioni* dello stesso font—avranno: * coperture diverse dell’insieme completo di [caratteri emoji Unicode](https://unicode.org/emoji/charts/emoji-list.html)—cioè, quanti caratteri emoji il font fornisce come glifi; * usare design di glifo diversi per rappresentare singoli caratteri emoji; * variare nelle funzionalità che forniscono per supportare usi più avanzati degli standard Unicode, come [modificatori emoji](https://unicode.org/reports/tr51/#Emoji_Modifiers_Table)e altre capacità di elaborazione del testo emoji descritte in [Standard tecnico Unicode n. 51: Unicode Emoji](https://unicode.org/reports/tr51/). #### Il fermento attorno a HarfBuzz Abbiamo accennato alla necessità di un *motore di composizione del testo*: software che prende del testo Unicode in input, scritto usando una specifica combinazione di sistema di scrittura e lingua, e, usando un font designato, compone quel testo in una sequenza di glifi, insieme a dati di posizionamento, che possono essere usati per comporre tipograficamente il testo di input originale. [HarfBuzz](https://harfbuzz.github.io/) è uno di questi motori di composizione del testo: è [una libreria di codice open source](https://github.com/harfbuzz/harfbuzz) ed è il prodotto di oltre un decennio di ricerca e sviluppo—e viene ancora sviluppato e distribuito attivamente come parte di molti prodotti software. HarfBuzz stesso non esegue la “composizione tipografica” ma fornisce “servizi di composizione del testo” al software che sceglie di integrarlo, tra cui XeTeX, LuaHBTeX, [Adobe PhotoShop e Adobe InDesign](https://en.wikipedia.org/wiki/HarfBuzz). Integrando HarfBuzz, i motori TeX possono sfruttare le sue avanzate capacità di composizione del testo per fornire una composizione tipografica multilingue molto sofisticata, in particolare per sistemi di scrittura complessi come arabo, ebraico, devanagari e molti altri. Si noti anche che HarfBuzz viene utilizzato per elaborare e comporre caratteri testo emoji Unicode, cosa che esploreremo in modo più dettagliato. Il seguente grafico riassume il ruolo svolto da HarfBuzz quando è integrato con software, come XeTeX o LuaHBTeX, durante la composizione di testo in un sistema di scrittura complesso, come l’arabo: ![Panoramica della composizione del testo arabo con HarfBuzz](/files/1ff653609f82f32dc39ee545aadfaf37391ec5f0) **Esplorare HarfBuzz** Chiunque sia interessato a saperne di più su HarfBuzz e sui servizi di composizione OpenType che fornisce a XeTeX e LuaHBTeX può [scaricare una distribuzione binaria di HarfBuzz](https://github.com/harfbuzz/harfbuzz/releases) che contiene la libreria HarfBuzz (per programmatori) e utilità da riga di comando `hb-view` e `hb-shape`. **Esempio: come usare hb-view** Crea un nuovo file nel tuo editor di testo preferito con supporto UTF-8 e copia/incolla i seguenti sei caratteri emoji 👋👋🏻👋🏼👋🏽👋🏾👋🏿 in quel file di testo, quindi salva in formato UTF-8 in un file chiamato, ad esempio, `emoji.txt`. Nota che il tuo editor di testo potrebbe visualizzare versioni in bianco e nero di ripiego degli emoji perché non è in grado (o non è programmato) di renderizzare glifi a colori. Una volta salvati questi 6 emoji, il file `emoji.txt` dovrebbe contenere dati UTF-8 per la seguente sequenza di caratteri emoji Unicode—abbiamo separato i modificatori emoji con virgole solo per *facilitare la lettura*: * `1F44B` per produrre 👋 * `1F44B`, `1F3FB` per produrre 👋🏻 * `1F44B`, `1F3FC` per produrre 👋🏼 * `1F44B`, `1F3FD` per produrre 👋🏽 * `1F44B`, `1F3FE` per produrre 👋🏾 * `1F44B`, `1F3FF` per produrre 👋🏿 Dovrebbe esserci un totale di **11** caratteri Unicode, ciascuno dei quali genera 4 byte di dati UTF-8, quindi il `emoji.txt` file dovrebbe essere lungo 44 byte, escludendo eventuali marcatori di fine riga usati alla fine della riga contenente gli emoji. La `hb-view` l’utility può usare il file `emoji.txt`, insieme a un idoneo font color OpenType a tua scelta, come `NotoColorEmoji.ttf`, per generare un file SVG dell’output composti di HarfBuzz. L’esempio seguente da riga di comando, che deve essere **digitato su una sola riga** nel tuo terminale, genererà il file SVG `emoji.svg`: ```latex hb-view --font-size=20 --output-file="emoji.svg" --output-format=svg --text-file=emoji.txt --font-file=NotoColorEmoji.ttf ``` Se l’esecuzione ha successo, il file `emoji.svg`, generato da `hb-view`, può essere aperto da Inkscape e dovrebbe apparire più o meno così: ![Hbvieemoji.png](/files/321ee2fab7e1f9e8adb69dfd405ba486ef937354) `hb-view` può essere usato per esplorare la composizione di HarfBuzz per qualsiasi file di testo Unicode e font OpenType adatti—non è certamente limitato all’uso con emoji! Digita ```latex hb-view --help-all ``` per vedere la ricchezza delle opzioni da riga di comando di questa utile e potente utilità. Buona composizione! ## Composizione del testo e motori TeX Qui esamineremo le capacità di composizione del testo di XeTeX e della famiglia di motori TeX LuaTeX. ### XeTeX XeTeX è stato sviluppato nei primi anni 2000 e ha aperto la strada a diverse innovazioni nella composizione tipografica basata su TeX, in particolare *il supporto* integrato per: * la lettura di testo Unicode in formato UTF-8; * l’uso di font OpenType; * la composizione del testo per la composizione tipografica multilingue; * la composizione matematica basata su OpenType. La capacità di XeTeX di comporre facilmente e comodamente lingue con sistemi di scrittura complessi è dovuta alle sue capacità integrate di composizione del testo—originariamente basate sul, ora deprecato, [ICU LayoutEngine](http://userguide.icu-project.org/layoutengine). Grazie al lavoro di Khaled Hosny, XeTeX è passato all’uso di HarfBuzz per la composizione del testo, come notato in un annuncio del [marzo 2013](https://tug.org/pipermail/xetex/2013-March/024118.html). Per chiunque desideri comporre testo multilingue, XeTeX viene solitamente citato come il motore TeX di scelta—ma ora c’è un’altra opzione, LuaHBTeX, che esploreremo. ### LuaTeX e LuaHBTeX Lo sviluppo di LuaTeX è iniziato intorno al 2005, ma ha seguito una filosofia di progettazione molto diversa da XeTeX, che incorporava nuove funzionalità *direttamente in* il software XeTeX. A differenza di XeTeX, gli sviluppatori di LuaTeX optarono per “...fornire un insieme minimo di strumenti e nessuna soluzione.” (vedi [Manuale di riferimento di LuaTeX](https://www.pragma-ade.com/general/manuals/luatex.pdf)). Piuttosto che fornire una serie di funzionalità aggiuntive *integrate in* nei motori basati su LuaTeX, i meccanismi interni dei motori LuaTeX vengono resi accessibili così che sviluppatori e utenti esperti possano sfruttare il linguaggio di scripting Lua integrato per costruire le proprie soluzioni. Ad esempio, a differenza di XeTeX, il motore LuaTeX non può *direttamente* usare font OpenType; invece, i font OpenType devono essere caricati e “preparati all’uso” tramite funzioni di caricamento dei font scritte in codice Lua. Queste funzioni di caricamento dei font sono chiamate *callback* funzioni callback: codice Lua che LuaTeX chiamerà (“eseguirà”) quando viene fatta una richiesta per caricare un font. Inoltre, il motore LuaTeX non fornisce alcuna *il supporto* capacità di composizione del testo—anche queste devono essere fornite da codice esterno che il motore LuaTeX può chiamare per offrirgli servizi di composizione del testo. Anche qui, questo contrasta con il motore XeTeX, che incorporava capacità di composizione del testo nel software principale. #### luaotfload: essenziale per usare i font OpenType in LuaTeX/LuaHBTeX Il meccanismo di callback di LuaTeX per il caricamento dei font offre un notevole grado di flessibilità, sebbene al “costo” di ulteriore programmazione. Fortunatamente per gli utenti di LuaLaTeX, la comunità TeX ha sviluppato un pacchetto chiamato `luaotfload`, che fa parte della [rilascio annuale di TeX Live](https://www.tug.org/texlive/) ed è, naturalmente, disponibile per gli utenti di Overleaf. `luaotfload` è [disponibile su CTAN](https://ctan.org/pkg/luaotfload?lang=en) e ha un [repository di sviluppo su GitHub](https://github.com/latex3/luaotfload) dove puoi seguire gli ultimi sviluppi e [nuove versioni](https://github.com/latex3/luaotfload/releases). `luaotfload` può essere caricato direttamente nel preambolo di un documento LaTeX tramite ```latex \usepackage{luaotfload} ``` Nota che `luaotfload` è il nome di un pacchetto LaTeX *pacchetto*, il che significa che ha il nome file `luaotfload.sty`. Se volessi usare `luaotfload` con plain TeX, puoi farlo aggiungendo la riga ```latex \input luaotfload.sty ``` al tuo documento plain TeX. Normalmente, gli utenti di LuaLaTeX—cioè coloro che compongono LaTeX usando LuaTeX/LuaHBTeX—non hanno bisogno di interagire direttamente con `luaotfload` perché il comando [`fontspec` pacchetto](https://ctan.org/pkg/fontspec) caricherà il `luaotfload` pacchetto per te, occupandosi di molti dettagli di basso livello tramite comandi a livello utente forniti da `fontspec` pacchetto. ### LuaHBTeX: nuove opzioni per la composizione del testo `luaotfload` è una libreria Lua matura e potente che fornisce la gestione dei font OpenType da parte di LuaTeX—insieme alla fornitura di servizi di composizione del testo per una gamma di lingue e sistemi di scrittura. In origine, le funzioni di composizione del testo di `luaotfload` erano implementate in puro codice Lua, ma il rilascio di TeX Live 2020 ha portato un’altra opzione mainstream per la composizione del testo—un nuovo motore basato su LuaTeX chiamato LuaHBTeX. La “HB” in LuaHBTeX sta per HarfBuzz—in sostanza, LuaHBTeX è il motore LuaTeX originale *più* un motore di composizione del testo HarfBuzz integrato. In linea con la filosofia di progettazione di LuaTeX, la disponibilità di HarfBuzz non *automaticamente* garantisce che il testo venga composto da LuaHBTeX: HarfBuzz è un altro strumento che può essere usato per costruire soluzioni di composizione del testo. L’integrazione di HarfBuzz in LuaHBTeX è [programmabile tramite codice Lua](#introduction-to-the-luahbtex-harfbuzz-api), il che ha consentito `luaotfload`agli sviluppatori di luaotfload ad aggiungere soluzioni di composizione del testo basate su HarfBuzz. Di conseguenza, [a partire dalla versione 3.1, rilasciata il 5 novembre 2019](https://github.com/latex3/luaotfload/releases/tag/v3.1), `luaotfload` di essere potenziato per sfruttare HarfBuzz—rendendo le capacità di composizione del testo di HarfBuzz facilmente accessibili all’utente generico. I lettori interessati ai dettagli tecnici dell’integrazione di HarfBuzz con LuaTeX possono leggere questo [articolo di Khaled Hosny](https://www.tug.org/TUGboat/tb40-1/tb124hosny-harfbuzz.pdf). ### luaotfload: due opzioni per la composizione del testo (quando usare HarfBuzz?) Gli utenti di LuaLaTeX hanno ora due opzioni per la composizione del testo: * `luaotfload`l’implementazione originale (basata su nodi) della composizione del testo, scritta interamente in Lua; * `luaotfload`la composizione basata su HarfBuzz di luaotfload—accessibile tramite codice Lua che chiama le funzioni di composizione del testo di HarfBuzz. `luaotfload` fornisce accesso a questi due sistemi di composizione tramite il parametro “`mode`” — sebbene la maggior parte degli utenti utilizzerà l’equivalente `fontspec` “`Renderer`” invece di usare direttamente funzioni di livello inferiore di `luaotfload`. Ciascuna delle `luaotfload`soluzioni di composizione del testo di luaotfload hanno i loro punti di forza e le loro (attuali) debolezze, ma quale dovresti usare e quando? Ecco alcuni punti da considerare: * `luaotfload`l’elaborazione nativa basata su nodi di luaotfload può richiedere molta memoria, in particolare per grandi font OpenType CJK. L’uso di HarfBuzz per la composizione del testo CJK può portare miglioramenti nella velocità e riduzioni nell’uso della memoria. * Usa HarfBuzz per i sistemi di scrittura complessi perché “...migliora notevolmente il rendering dei sistemi di scrittura indici e arabi ed è altamente raccomandato per tali sistemi di scrittura.” (vedi `luaotfload` manuale). * L’integrazione di HarfBuzz in `luaotfload` è ancora relativamente nuova ed è in ulteriore sviluppo. Al momento della scrittura (luglio 2021), è consigliabile usare la composizione integrata di luaotfload (impostando `mode=node`) per i font principali del tuo documento, in particolare se il documento usa il sistema di scrittura latino. Vedi questa [issue GitHub](https://github.com/latex3/luaotfload/issues/175#issue-801120377), che riassume i problemi e le discussioni. Se vuoi sperimentare, puoi usare `luaotfload` per caricare un file font e creare due font LaTeX: uno che usa la composizione basata su HarfBuzz e l’altro che usa la composizione basata su Lua. Overleaf ha creato un [progetto di esempio](#sample-project-arabic-shaping), che lo dimostra. * Non usare HarfBuzz per gestire i font matematici. Come discusso dagli sviluppatori su tex.stackexchange, HarfBuzz è [non è progettato per gestire font per la composizione tipografica matematica](https://tex.stackexchange.com/questions/544881/does-luahbtex-with-harfbuzz-renderer-completely-supports-math-formating) quindi non usarlo per quello scopo. **Progetto di esempio: composizione dell’arabo** Ecco un progetto Overleaf che usa diversi font arabi di alta qualità per confrontare `luaotfload`i servizi di composizione del testo basati su nodi di luaotfload (`mode=node`con quelli di HarfBuzz (`mode=harf`): * Questo progetto include l’output mostrato nella seguente immagine: ![Composizione dell’arabo](/files/3f961fae20f95d4066f994270a34b83d7e4f6dd7) ### Scegliere il “Renderer” in fontspec Come notato nella sua [documentazione](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), `fontspec` “...consente agli utenti sia di XeTeX sia di LuaTeX di caricare font OpenType in un documento LaTeX”. Se usi i motori LuaTeX o LuaHBTeX, `fontspec` caricherà il `luaotfload` libreria per te e, inoltre, fornisce una serie di comandi comodi a livello utente che alleviano la necessità di interagire con `luaotfload`la funzionalità di basso livello di luaotfload. Quindi, come scegli tra la composizione di HarfBuzz o la composizione integrata fornita da `luaotfload`? La risposta è contenuta nell’eccellente [`fontspec` documentazione](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), in particolare nella Parte VI: funzioni font solo per LuaTeX. `fontspec` fornisce un’impostazione chiamata `Renderer` che può essere impostata quando il font viene definito tramite `fontspec`. `Renderer` controlla l’elaborazione di basso livello del font. Le due opzioni di interesse sono * `Renderer = Node`: la “modalità” predefinita per la composizione tipografica dei font OpenType—usa `luaotfload`le funzioni di composizione del testo di luaotfload implementate interamente in Lua. * `Renderer = Harfbuzz`: questa “modalità” definisce/carica il font da usare con il motore di composizione del testo HarfBuzz. `luaotfload` usa l’API di LuaHBTeX per chiamare funzioni in HarfBuzz. Per ulteriori informazioni vedi il [`fontspec` documentazione](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf). ## motori TeX, HarfBuzz e emoji a colori Sebbene XeTeX e LuaHBTeX integrino entrambi HarfBuzz, forniscono diversi livelli di supporto per alcune delle funzionalità più avanzate di HarfBuzz—in particolare il caricamento e l’uso di font color OpenType. ### XeTeX e font color OpenType Come osservato, esistono due categorie di font color OpenType basate sul formato dei dati usato per memorizzare i glifi del font: basati su vettori e basati su raster. #### XeTeX e font color OpenType basati su raster XeTeX non può caricare font OpenType a colori basati su raster—come quelli di Google’s [Noto Color Emoji](https://www.google.com/get/noto/help/emoji/) incluso in TeX Live 2020. Per esempio, se provi a caricare Noto Color Emoji (NotoColorEmoji.ttf) XeLaTeX fallirà con un errore potenzialmente fuorviante che afferma che Noto Color Emoji “non può essere trovato”. Il seguente codice LaTeX, impaginato con XeLaTeX, *non funziona*: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{NotoColorEmoji.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} \smiley \end{document} ``` [Apri questo codice XeLaTeX in Overleaf (non ***non*** funziona).](https://www.overleaf.com/docs?engine=xelatex\&snip_name=XeTeX+failure\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%7BNotoColorEmoji.ttf%7D%0A%5Cnewcommand%7B%5Csmiley%7D%7B%7B%5Cemojifont%5Cchar%221F600%7D%7D%0A%5Csmiley%0A%5Cend%7Bdocument%7D) Fallisce con l'errore: ``` ! Package fontspec Error: The font "NotoColorEmoji" cannot be found. ``` Analogamente, un semplice esempio Plain TeX elaborato da XeTeX fallisce anch'esso ```latex \font\emojifont="[NotoColorEmoji.ttf]" at 12pt \emojifont \char"1F600 \bye ``` [Apri questo esempio Plain TeX (XeTeX) in Overleaf (non ***non*** funziona).](https://www.overleaf.com/docs?engine=latex_dvipdf\&snip_name\[]=main.tex\&snip\[]=%25%5Ctitle%7Bdummy+title%7D%0A%5Cfont%5Cemojifont%3D%22%5BNotoColorEmoji.ttf%5D%22+at+12pt%0A%5Cemojifont+%5Cchar%221F600%0A%5Cbye\&snip_name\[]=readme\&snip\[]=This+project+uses+a+latexmkrc+file+to+run+xetex+not+xelatex\&snip_name\[]=latexmkrc\&snip\[]=%24latex+%3D+%27xetex%25O+%25S%27%3B+%23+to+use+the+xetex+engine\&main_document=main.tex) L'esempio Plain TeX segnala un messaggio di errore simile, ma diverso: ``` ! Font \emojifont=[NotoColorEmoji.ttf] at 12.0pt not loadable: Metric (TFM) fil e oppure font installato non trovato. l.1 \font\emojifont="[NotoColorEmoji.ttf]" at 12pt Non sono riuscito a leggere i dati della dimensione per questo font, quindi ignorerò la specifica del font. [Gli esperti possono correggere i file TFM usando TFtoPL/PLtoTF.] Potresti provare a inserire una specifica di font diversa; per esempio, digita `I\font='. ``` **Esempio Plain LuaHBTeX** Per confronto, ecco un esempio minimo Plain TeX compilato con LuaHBTeX ```latex \input luaotfload.sty \font\emojifont=NotoColorEmoji.ttf:mode=harf at 12pt \emojifont \Uchar"1F600 \bye ``` [Apri questo esempio Plain TeX (LuaHBTeX) in Overleaf (viene compilato con successo).](https://www.overleaf.com/docs?engine=latex_dvipdf\&snip_name\[]=main.tex\&snip\[]=%25%5Ctitle%7BPlain+TeX+with+LuaHBTeX%7D%0A%5Cinput+luaotfload.sty%0A%5Cfont%5Cemojifont%3DNotoColorEmoji.ttf%3Amode%3Dharf+at+12pt%0A%5Cemojifont+%5CUchar%221F600%0A%5Cbye\&snip_name\[]=readme\&snip\[]=This+project+uses+a+latexmkrc+file+to+run+luahbtex+not+lualatex\&snip_name\[]=latexmkrc\&snip\[]=%24latex+%3D+%27luahbtex+%25O+%25S%27%3B+%23+to+use+the+luahbtex+engine\&main_document=main.tex) #### La vera causa del fallimento di XeTeX I messaggi di errore forniti da XeTeX nascondono in parte la vera causa del problema: i font OpenType a colori, in particolare le varianti basate su raster, sono *contiene* supportati da XeTeX. In realtà, XeTeX (Kpathsea) può *trovare* il font Noto Color Emoji, ma XeTeX non può completamente *caricare* quel font e non è in grado di inizializzare le tabelle interne dei dati del font necessarie per usare quel font per l'impaginazione. Internamente, XeTeX *inizia* il processo di caricamento del font e lo testa per la “scalabilità” (usando la “definizione” di “scalabilità” di FreeType), ma quel test fallisce e XeTeX emette un messaggio di errore standard, a dir poco fuorviante, del motore TeX. **Nota tecnica** L'elaborazione di NotoColorEmoji.ttf da parte di XeTeX è stata analizzata compilando una versione di debug dell'eseguibile XeTeX. L'IDE Eclipse è stato usato per impostare un breakpoint sulla funzione di XeTeX `creatFontFromFile(filename, index, pointsize)`, quindi si è proceduto passo passo nel codice per osservare l'elaborazione successiva. #### XeTeX e i font OpenType a colori basati su vettori XeTeX può *caricare* font OpenType a colori basati su vettori, ma non produrrà emoji colorati nel PDF risultante—se XeTeX ne produce uno, addirittura. A differenza di LuaTeX, LuaHBTeX e pdfTeX, XeTeX non *direttamente* produce documenti impaginati in formato PDF. Invece, XeTeX produce un file intermedio `.xdv` (e**x**steso **dv**i) un formato di file che viene convertito in PDF da un'utilità chiamata `xdvipdfmx`. Al momento della stesura, `xdvipdfmx` non è in grado di incorporare nel PDF i dati appropriati dei glifi emoji a colori, quindi, nella migliore delle ipotesi, nel PDF vedrai emoji monocromatici—il risultato “di fallback”—oppure forse non vedrai nulla, a seconda del font usato. Ecco un esempio XeLaTeX che usa il font OpenType a colori [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr), disponibile in TeX Live. TwemojiMozilla.ttf usa il formato vettoriale COLR/CPAL di Microsoft per memorizzare i glifi a colori ed è incluso in TeX Live 2020. In questo esempio, XeTeX è in grado di caricare il font, generare un `.xdv` e il file PDF, ma il glifo emoji non è presente nel PDF impaginato: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} Ecco una faccina sorridente: \smiley \end{document} ``` [Apri questo codice XeLaTeX in Overleaf (NON funziona).](https://www.overleaf.com/docs?engine=xelatex\&snip_name=XeTeX+failure\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%7BTwemojiMozilla.ttf%7D%0A%5Cnewcommand%7B%5Csmiley%7D%7B%7B%5Cemojifont%5Cchar%221F600%7D%7D%0AHere+is+a+smiley%3A+%5Csmiley%0A%5Cend%7Bdocument%7D) Al contrario, il codice sopra funziona con LuaLaTeX se definisci `\emojifont` usando il `fontspec` impostazione `[Renderer=HarfBuzz]`: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf}[Renderer=HarfBuzz] \newcommand{\smiley}{{\emojifont\char"1F600}} Ecco una faccina sorridente: \smiley \end{document} ``` [Apri questo codice LuaLaTeX in Overleaf (funziona).](https://www.overleaf.com/docs?engine=lualatex\&snip_name=LuaLaTeX+emoji+example\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%7BTwemojiMozilla.ttf%7D%5BRenderer%3DHarfBuzz%5D%0A%5Cnewcommand%7B%5Csmiley%7D%7B%7B%5Cemojifont%5Cchar%221F600%7D%7D%0AHere+is+a+smiley%3A+%5Csmiley%0A%5Cend%7Bdocument%7D) ### LuaHBTeX e i font OpenType a colori Attraverso il suo motore di shaping HarfBuzz integrato e la `luaoftload` libreria, LuaHBTeX offre supporto per tutte e quattro le varietà di font OpenType a colori. Gli utenti di LuaLaTeX possono sfruttare appieno l'elaborazione basata su Unicode di testi contenenti caratteri emoji oppure abbellire semplicemente i propri documenti con testo molto colorato usando font OpenType a colori. Come osservato in precedenza, le quattro varianti di font OpenType a colori possono essere classificate in due gruppi: * quelli che contengono glifi in formati di immagine raster, come PNG; * altri che usano formati vettoriali SVG o il meccanismo COLR/CPAL di Microsoft. I formati di glifi basati su vettori hanno il vantaggio della scalabilità: producono grafica dei glifi nitida a qualsiasi dimensione in punti. **Uso dei font a colori Microsoft COLR/CPAL con LuaHBTeX** Se vuoi usare un formato vettoriale per i tuoi font emoji OpenType a colori, dai un'occhiata al font [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr?lang=en), che si basa sul formato COLR/CPAL di Microsoft. TwemojiMozilla.ttf è incluso in TeX Live, ma puoi ottenere l'ultima versione dal suo [repository GitHub](https://github.com/mozilla/twemoji-colr/releases) e caricarla nel tuo progetto Overleaf. Ecco un piccolo, `fontspec`basato su Lua, esempio che usa `Renderer=Harfbuzz`, che impagina un grande papero emoji (vettoriale): ```latex \documentclass{article} \usepackage{fontspec} \title{Duck demo} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{TwemojiMozilla.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Apri questo esempio LuaLaTeX per impaginare un papero vettoriale.](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Typesetting+an+emoji+duck\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Ctitle%7BDuck+demo%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%5BRenderer%3DHarfbuzz%2CSizeFeatures%3D%7BSize%3D400%7D%5D%7BTwemojiMozilla.ttf%7D%0A%5Cemojifont%5CUchar%221F986%0A%5Cend%7Bdocument%7D) Ecco il papero (vettoriale) prodotto dall'esempio sopra: ![](/files/726301f9bd0de4f5f8c1f816c357c522700b7738) #### L’uso di font OpenType a colori basati su SVG con LuaHBTeX Al momento dell'aggiornamento di questo articolo (luglio 2023), c'è poca documentazione formale sull'uso dei font OpenType a colori in stile SVG con LuaLaTeX. Alcuni [commenti fatti in discussioni online](https://github.com/latex3/luaotfload/issues/96) suggeriscono di usare `fontspec`di `RawFeature`, come mostrato nel pseudo-codice qui sotto. Sostituisci `*nome del tuo file di font SVG qui*` con il nome di un file di font basato su SVG accessibile al tuo codice LaTeX: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emoji[RawFeature={+svg},SizeFeatures={Size=20}]{your SVG font file name here} \emoji La tua emoji qui... \end{document} ``` Se ometti `fontspec` e carichi `luaotfload` direttamente, potrebbe essere necessario dichiarare e specificare un font nel modo seguente—i nostri esperimenti indicano che devi omettere la `mode=harf` opzione affinché funzioni: ```latex \font\emoji=[your SVG font file name here]:+svg; ``` **Alcune note di cautela** I lettori interessati a usare font OpenType a colori in stile SVG dovrebbero notare: * I font OpenType in stile SVG che contengono un gran numero di glifi possono essere [costosi dal punto di vista computazionale per LuaLaTeX](#processing-svg-glyph-data) da elaborare, con il potenziale risultato di [timeout di Overleaf](/latex/it/base-di-conoscenza/038-fixing-and-preventing-compile-timeouts.md). * Il supporto di LuaLaTeX per questi font potrebbe essere [considerato sperimentale](https://github.com/latex3/luaotfload/issues/96#issuecomment-530317399): i risultati possono variare a seconda della versione di TeX Live usata dal tuo progetto; di conseguenza, è consigliabile sperimentare e procedere con cautela. **Elaborazione dei dati SVG dei glifi** SVG consente ai designer di produrre design complessi e colorati che rappresentano i glifi di un font—soggetto ad alcune restrizioni SVG [documentate nella specifica OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/svg). Tuttavia, i motori TeX, incluso LuaHBTeX, non possono importare direttamente (usare) file o dati SVG—come i dati SVG usati per descrivere le forme dei glifi nei font OpenType a colori in stile SVG. I dati SVG di un glifo devono essere convertiti in formato PDF perché LuaHBTeX può usarli per impaginare il glifo e produrre il documento PDF finale. Questa conversione da SVG a PDF è gestita da codice Lua all'interno di `luaoftload`: i dati SVG di ogni glifo vengono estratti dal file font, salvati in un file temporaneo `.svg` e convertiti in PDF usando Inkscape tramite la sua riga di comando. L'estrazione dei dati SVG e la loro conversione in PDF comportano un certo sovraccarico di elaborazione, con conseguenti tempi di compilazione del documento potenzialmente lunghi—soprattutto per documenti che usano grandi font SVG contenenti migliaia di glifi emoji. #### Font OpenType a colori basati su raster **Uso del formato di font OpenType a colori CBDT/CBLC di Google con LuaHBTeX** [Noto Color Emoji](https://fonts.google.com/noto/specimen/Noto+Color+Emoji) è un font OpenType a colori incluso in TeX Live, rendendolo facile da usare in un progetto Overleaf. Poiché Noto Color Emoji usa grafica in formato PNG per rappresentare i glifi emoji, possiamo usarlo per impaginare un grande emoji a forma di papera (raster)—come dimostra l'esempio seguente. Si noti di nuovo che la `fontspec` dichiarazione del font (`\emojifont`) usa `Renderer=Harfbuzz`. ```latex \documentclass{article} \usepackage{fontspec} \title{Duck demo} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{NotoColorEmoji.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Apri questo esempio LuaLaTeX per impaginare una papera raster.](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Typesetting+a+large+raster+duck\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bfontspec%7D%0A%5Ctitle%7BDuck+demo%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewfontfamily%5Cemojifont%5BRenderer%3DHarfbuzz%2CSizeFeatures%3D%7BSize%3D400%7D%5D%7BNotoColorEmoji.ttf%7D%0A%5Cemojifont%5CUchar%221F986%0A%5Cend%7Bdocument%7D) Ecco la papera raster prodotta dall'esempio sopra: ![Un emoji a forma di papera raster impaginato con LaTeX](/files/d52cced929082357a14583a03bc89ca985bb285b) Se provi a usare `NotoColorEmoji.ttf` ma ometti `[Renderer=Harfbuzz]` dal `fontspec` dichiarazione, LuaHBTeX fallirà ed emetterà un messaggio di errore quando proverà a scrivere il file PDF: ```latex ! errore: (file /usr/local/texlive/2020/texmf-dist/fonts/truetype/google/noto-em oji/NotoColorEmoji.ttf) (ttf): tabella loca non trovata ``` Il motivo di questo errore nella [tabella loca](https://docs.microsoft.com/en-us/typography/opentype/spec/loca) è [spiegato su GitHub](https://github.com/latex3/luaotfload/issues/98#issuecomment-531610153). **Uso del formato di font OpenType a colori sbix di Apple con LuaHBTeX** Test offline dimostrano che LuaHBTeX supporta la `sbix` variante di font OpenType a colori ma, al momento della stesura di questo articolo, non siamo riusciti a individuare un font emoji a colori `sbix`in variante sbix da usare per dimostrare l'impaginazione di una papera. Per favore [contattarci](https://www.overleaf.com/contact) se ne conosci uno, e aggiorneremo rapidamente questo articolo per usarlo. ## Introduzione all'API HarfBuzz di LuaHBTeX ![Db.gif](/files/43b2601588b67acbc04e42451c92832188af3e00) ![Db.gif](/files/43b2601588b67acbc04e42451c92832188af3e00) Lo shaping del testo, in particolare per le lingue con script complessi, e persino per gli emoji, è un compito intrinsecamente difficile, quindi, non sorprende, HarfBuzz è una libreria sofisticata con cui può essere complicato lavorare—a meno che tu non abbia già familiarità con le operazioni di text-shaping. In questa sezione finale, esaminiamo l'integrazione di HarfBuzz in LuaHBTeX e come accedervi tramite codice Lua all'interno di `\directlua`. Il nostro esempio usa un codice abbastanza semplice per dimostrare l'API HarfBuzz di LuaHBTeX. È in qualche modo artificioso, non di livello produttivo né molto pratico perché il suo unico scopo è introdurre alcune idee fondamentali. Abbiamo suddiviso il codice Lua in due `\directlua` blocchi: il primo carica la `luaharfbuzz` libreria e crea alcune variabili globali che useremo nel nostro secondo `\directlua` blocco, in cui definiamo una macro chiamata `\codestoemoji`. Sembra opportuno replicare l'uso di Knuth dei doppi segni di pericolo-caduta (immagine per gentile concessione di [questo sito](http://www.truetex.com/db.htm)) perché il contenuto è in qualche modo di basso livello e “sbircia sotto il cofano”—anche se speriamo possa interessare al lettore più intrepido. L'integrazione di HarfBuzz in LuaHBTeX deriva dal [progetto luaharfbuzz su GitHub](https://github.com/ufyTeX/luaharfbuzz/wiki#projects-using-luaharfbuzz) dove puoi trovare un [introduzione al progetto](https://github.com/ufyTeX/luaharfbuzz/wiki) insieme a un [elenco della API luaharfbuzz](http://ufytex.github.io/luaharfbuzz/). ### Primi passi: carica la libreria luaharfbuzz e trova un font Per usare l'API HarfBuzz di LuaHBTeX dobbiamo prima caricare la libreria (modulo) chiamata `luaharfbuzz`, incorporata in LuaHBTeX, e salvare la tabella restituita in una variabile (globale) che chiameremo `hblib`: ```latex hblib=require("luaharfbuzz") ``` Poi, dobbiamo localizzare un font OpenType a colori adatto per emoji: useremo Noto Color Emoji—nota che stiamo essendo molto pigri e non stiamo facendo alcun controllo degli errori nel caso in cui non lo troviamo! Per trovarlo, useremo la `kpse` libreria (Kpathsea), che fa anch'essa parte di LuaTeX/LuaHBTeX: ```latex pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") ``` Ora che abbiamo accesso alla libreria HarfBuzz, tramite la nostra variabile `hblib`, e al percorso di un font adatto (`pathtofontfile`), possiamo iniziare a usare `hblib`. Per iniziare, creeremo un font HarfBuzz e una face HarfBuzz da usare nel secondo `\directlua` blocco di codice in cui definiamo la nostra macro. ```latex %Crea una face HarfBuzz e un font HarfBuzz da Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) ``` #### Font HarfBuzz e face HarfBuzz: che cosa sono? Un [Oggetto face HarfBuzz](https://harfbuzz.github.io/fonts-and-faces.html) rappresenta un carattere tipografico caricato da un file font, ma senza che siano impostati parametri specifici (come la dimensione). Un [oggetto font HarfBuzz](https://harfbuzz.github.io/fonts-and-faces.html) rappresenta una *istanza specifica* di una face HarfBuzz; di conseguenza, diversi oggetti font HarfBuzz possono essere derivati da una singola face HarfBuzz: ogni font HarfBuzz può avere le proprie proprietà, come la dimensione, impostate a valori diversi. Una face HarfBuzz è un livello di astrazione più alto rispetto a un font HarfBuzz. ### Uso dei glifi del font per creare file PNG La parte finale del nostro primo `\directlua` blocco è una funzione chiamata `writePNGglyph(hbfontobject, glyphID)` che usiamo per dimostrare che alcuni font OpenType a colori, come Noto Color Emoji, usano grafica PNG per rappresentare i glifi emoji che contengono. Questa funzione usa l'API HarfBuzz di LuaHBTeX per estrarre dati PNG dai glifi e scrivere quei dati in un `.png` file denominato `Graphics.png`. Il nome di quel `.png` file viene restituito per essere usato da `\includegraphics` per incorporare immagini PNG dei glifi nel nostro PDF impaginato. Con il `writePNGglyph(hbfontobject, glyphID)` inserito, il nostro primo `\directlua` blocco di codice appare così: ```latex \directlua{ % Carica la libreria luaharfbuzz da LuaHBTeX hblib=require("luaharfbuzz") % Individua il font Noto Color Emoji sul server di Overleaf pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Crea una face HarfBuzz e un font HarfBuzz da Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Questa funzione accetta un font e un ID glifo: % estrae i dati PNG dei glifi e li scrive % in un file .png function writePNGglyph(hbfontobject, glyphID) % Ottieni i dati PNG del glifo local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Costruisci un nome di file per il nostro file .png local fname="Glyph"..glyphID..".png" % Scrivi il file .png e restituisci il nome del file local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Restituisci il nome del file da usare per \includegraphics return fname end } ``` ### Secondo blocco \directlua: crea la macro \codestoemoji L'obiettivo è definire una macro `\codestoemoji` che possiamo chiamare con un pezzo di testo contenente codici di caratteri emoji che vogliamo che HarfBuzz interpreti. In particolare, useremo `\Uchar` per rappresentare ciascun carattere emoji; per esempio: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` Dentro la definizione di `\codestoemoji` accade molto, e lo spiegheremo qui sotto, ma la definizione appare così: ```latex \newcommand{\codestoemoji}[1]{% \directlua{ local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) hbbuffer:set_direction(hblib.Direction.new("ltr")) local res = hblib.shape_full(hbfont, hbbuffer, {},{}) if (res) then local hbglyphs=hbbuffer:get_glyphs() % La tabella dei glifi, hbglyphs, è indicizzata a partire da 1 local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Riduci la dimensione delle nostre immagini PNG importate local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} ``` #### Comprendere la definizione della macro \codestoemoji La `\codestoemoji` la macro è per lo più codice Lua contenuto all'interno di `\directlua`, quindi, se vuoi saperne di più su *come* `\directlua` come funziona, consulta l'articolo di Overleaf [Comprendere `\directlua`](/latex/it/articoli-approfonditi/09-an-introduction-to-luatex-part-2-understanding-directlua.md). Spiega come LuaTeX e LuaHBTeX elaborano `\directlua` quando i comandi TeX/LaTeX sono inclusi nel codice Lua e, in particolare, la necessità di usare `\noexpand` e `\unexpanded`. **Gestione del parametro della macro: "#1"** La macro inizia con queste tre righe: ```latex local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) ``` che svolgono i seguenti compiti: * `local str="#1"`: questo crea una stringa Lua dall'input passato dalla macro; * `local hbbuffer = hblib.Buffer.new()`: questo usa l'API HarfBuzz per creare un buffer che contenga il testo che vogliamo che HarfBuzz interpreti; * `hbbuffer:add_utf8(str)`: questo aggiunge al buffer HarfBuzz una stringa in formato UTF-8, creata dall'input della nostra macro. La prima riga di codice ```latex local str="#1" ``` sembra piuttosto semplice, ma il suo funzionamento comporta una certa complessità, che vale la pena esplorare in un po' più di dettaglio. Se consideriamo la terza riga di codice ```latex hbbuffer:add_utf8(str) ``` vediamo che usa la nostra `str` variabile per fornire al buffer HarfBuzz una stringa Unicode formattata in UTF-8. Perché ciò funzioni, la variabile `str` deve a sua volta contenere testo Unicode formattato come UTF-8; quindi sorge la domanda: *come* LuaHBTeX ha “convertito” l'argomento della macro `"#1"`, contenente `\Uchar` comandi, nella variabile di stringa Lua `str` contenente testo UTF-8 per HarfBuzz? Se guardiamo al nostro uso previsto della `\codestoemoji` macro: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` l'input, come `\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065...`, non assomiglia affatto a una sequenza di caratteri emoji codificati in UTF-8. Inoltre, HarfBuzz non sa nulla dei comandi TeX. In qualche modo, l'input grezzo di TeX comprendente `\Uchar` comandi viene trasformato in caratteri Unicode codificati in UTF-8 che HarfBuzz può usare, ma *come*? La risposta si trova nel comportamento del `\Uchar` comando: provare a chiamare `\codestoemoji` usando `\char` anziché `\Uchar` fallirà, ma *perché*? **\Uchar: espansione in \directlua** Quando la `\codestoemoji` macro viene chiamata, il `\directlua` comando, memorizzato all'interno della definizione della macro, deve preparare il codice Lua da inviare all'interprete Lua incorporato di LuaHBTeX. Parte di quel processo di preparazione del codice è l'espansione di tutti i comandi TeX/LaTeX presenti nel codice Lua originale nella definizione della macro, insieme all'espansione di eventuali argomenti della macro forniti dall'utente. Questo processo di espansione produce una lista di token che viene successivamente convertita di nuovo in testo, generando il codice Lua da passare all'interprete Lua. Per comodità, riproduciamo un diagramma dall'articolo di Overleaf [Comprendere `\directlua`](/latex/it/articoli-approfonditi/09-an-introduction-to-luatex-part-2-understanding-directlua.md): ![Il funzionamento di \directlua](/files/b45241500369014ef6dbe584b5a1ab4ba11d4aca) La macro `\codestoemoji` è pensata per essere chiamata usando `\Uchar` comandi e, [come osservato in precedenza nell'articolo](#the-key-difference-expansion), `\Uchar` è un comando espandibile la cui espansione genera un token di carattere. Durante le attività di elaborazione di `\directlua`, LuaHBTeX espande ciascun `\Uchar` comando dove lo *rimuove* ogni `\Uchar` dall’input e *lo sostituisce* sostituisce con il corrispondente valore di espansione: un token di carattere che rappresenta il ``. Nella fase finale dell'elaborazione, la lista iniziale di token generata da `\directlua` viene convertita *di nuovo in testo* per diventare il codice Lua destinato all'interprete Lua (vedi diagramma sopra). Tutti i token di carattere prodotti dall'espansione di `\Uchar` sono anch'essi *convertiti di nuovo in testo*: quella conversione di token di carattere in testo genera le rappresentazioni UTF-8 dei valori originali di `` valori. Nel nostro esempio, nel momento in cui il codice Lua viene generato ed è pronto per l'interprete Lua, l'input della macro per "#1" è stato convertito in una sequenza di testo UTF-8: la `str` variabile è ora una stringa di testo UTF-8 che può essere aggiunta in sicurezza al buffer HarfBuzz. **Perché \char non funziona?** La risposta semplice è perché `\char` è *contiene* un comando espandibile. A differenza di `\Uchar` i comandi, `\char` comandi *non vengono rimossi* dall'input durante `\directlua`l'elaborazione iniziale per generare un elenco di token, “passano attraverso” per essere incorporati nell'elenco di token che viene costruito da `\directlua`. Per esempio, se l'argomento di `\codestoemoji` contenesse `\char"1F3F4` LuaHBTeX lo convertirebbe in una sequenza di token e li memorizzerebbe come parte dell'elenco totale di token in fase di generazione. Nella fase successiva dell'elaborazione, convertendo i token di nuovo in testo, il codice Lua risultante conterrebbe la *stringa letterale* `\char"1F3F4` all'interno del testo usato per definire la nostra variabile `str`. Quando il contenuto di `str` viene aggiunto al buffer HarfBuzz, non conterrà una sequenza codificata UTF-8 che rappresenti il carattere emoji "1F3F4, ma conterrà la stringa letterale `\char"1F3F4`, che HarfBuzz tenterà di comporre e che, per i nostri scopi, non produrrebbe un glifo emoji. Per inciso, la stringa `\char"1F3F4` genererebbe anche errori di sintassi Lua, a meno che non fosse creata come una “stringa a parentesi lunghe”—vedi [Cosa sono le sequenze di escape Lua](/latex/it/articoli-approfonditi/09-an-introduction-to-luatex-part-2-understanding-directlua.md#what-are-e2809clua-escape-sequencese2809d3f) per maggiori informazioni su questo problema. Se proviamo a usare `\codestoemoji` con un `\char` il comando, così: ```latex \codestoemoji{\char"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` LuaHBTeX fallirà e segnalerà un errore di sintassi più o meno così: ```latex [\directlua]:1: invalid escape sequence near '"\c'. \codestoemoji ...ing \includegraphics }.}]]) end } l.75 ...r"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} L'interprete Lua ha incontrato un problema, quindi il resto di questo blocco Lua verrà ignorato. ``` #### Chiamare la funzione di composizione di HarfBuzz **Impostare i parametri del buffer** A volte HarfBuzz richiede informazioni aggiuntive sul testo che deve comporre. Puoi fornire tali informazioni configurando il tuo `` usando *metodi del buffer*, come ad esempio: * `:set_direction(*HarfBuzz direction*)`; * `:set_language(*HarfBuzz language*)`; * `:set_script(*HarfBuzz script*)`. Ad esempio, dobbiamo informare HarfBuzz che la direzione del nostro testo emoji sarà da sinistra a destra. Per farlo, usiamo il `set_direction()` metodo sul nostro `` (chiamato `hbbuffer`) scrivendo: ```latex hbbuffer:set_direction(hblib.Direction.new("ltr")) ``` dove `hblib.Direction.new("ltr")` crea un “oggetto direzione” adatto a essere passato al motore HarfBuzz tramite Lua. **Eseguire la composizione** Dopo che il buffer è stato inizializzato in modo appropriato, possiamo chiedere a HarfBuzz di eseguire la composizione vera e propria tramite la funzione `shape_full()`. Nel nostro esempio scriviamo: ```latex local res = hblib.shape_full(hbfont, hbbuffer, {},{}) ``` Il 3° e 4° parametro della `shape_full()` funzione devono essere tabelle Lua—abbiamo usato tabelle vuote “`{}`” per entrambi i parametri. La forma generale di `shape_full()` è: ```latex shape_full(font Harfbuzz, buffer Harfbuzz, {funzionalità del font}, {"shaper"} ``` * **`{"shaper"}`**: Di solito non deve essere impostato, ma le opzioni sono `{"ot"}` o `{"graphite2"}`. Maggiori informazioni sul concetto di “shaper” si possono trovare nella [documentazione di HarfBuzz](https://harfbuzz.github.io/shaping-and-shape-plans.html)—nota che questa documentazione riguarda l'API C di basso livello, non il `luaharfbuzz` binding (implementazione) basato su Lua. * **`{funzionalità del font}`**: Questa è una tabella che elenca le [funzionalità OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist)—supportate dal font—che vuoi che HarfBuzz applichi durante la composizione. Ogni funzionalità del font che vuoi usare deve essere creata usando una `luaharfbuzz` funzione della libreria ```latex library_instance.Feature.new(feature_string) ``` dove * `library_instance` è la tua `luaharfbuzz` variabile istanza della libreria (`hblib` nel nostro esempio); * `feature_string` usa una [sintassi per definire le funzionalità](https://github.com/ufytex/luaharfbuzz/wiki/Feature-Strings). Esempi di ciò sono `+smcp` per attivare le maiuscolette oppure `-kern` per disattivare il kerning. Ad esempio: ```latex local dosmcp = hblib.Feature.new("+smcp") local nokern = hblib.Feature.new("-kern") % Usa le funzionalità del tuo font in questo modo local res = hblib.shape_full(hbfont, hbbuffer, {dosmcp,nokern},{}) ``` #### Accedere al risultato: ottenere i glifi E infine, se l'operazione di composizione ha successo, i glifi composti vengono restituiti nella variabile buffer `hbbuffer` che abbiamo creato in precedenza nel codice. Accediamo ai glifi tramite il metodo del buffer `get_glyphs()` e usiamo un ciclo per ottenere ogni glifo individuale. Nota che la tabella Lua che contiene i glifi, `hbglyphs` nel nostro esempio, è indicizzata a partire da 1, non da 0. Di ogni glifo, *identificatore del glifo* (chiamato in modo confuso `codepoint`), e il font HarfBuzz (`hbfont`), viene passato alla `writePNGglyph()` funzione che crea un file PNG usando la rappresentazione raster del glifo fornita dal font. `writePNGglyph()` scrive un file PNG e restituisce il nome del file PNG, che viene usato per importare il file PNG (scalato) nel nostro documento LaTeX tramite `\includegraphics[scale=0.75]{}`. Nota come possiamo usare `\includegraphics` direttamente all'interno del codice Lua. ```latex if (res) then local hbglyphs=hbbuffer:get_glyphs() % La tabella dei glifi, hbglyphs, è indicizzata a partire da 1 local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Riduci la dimensione delle nostre immagini PNG importate local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end ``` ### Il codice completo che puoi aprire in Overleaf ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \directlua{ % Carica la libreria luaharfbuzz da LuaHBTeX hblib=require("luaharfbuzz") % Individua il font Noto Color Emoji sul server di Overleaf pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Crea una face HarfBuzz e un font HarfBuzz da Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Questa funzione accetta un font e un ID glifo: % estrae i dati PNG dei glifi e scrive % in un file .png function writePNGglyph(hbfontobject, glyphID) % Ottieni i dati PNG del glifo local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Costruisci un nome di file per il nostro file .png local fname="Glyph"..glyphID..".png" % Scrivi il file .png e restituisci il nome del file local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Restituisci il nome del file da usare per \includegraphics return fname end } \newcommand{\codestoemoji}[1]{% \directlua{ local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) hbbuffer:set_direction(hblib.Direction.new("ltr")) local res = hblib.shape_full(hbfont, hbbuffer, {},{}) if (res) then local hbglyphs=hbbuffer:get_glyphs() % La tabella dei glifi, hbglyphs, è indicizzata a partire da 1. local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Riduci la dimensione delle nostre immagini PNG importate local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} A duck: \codestoemoji{\Uchar"1F986} A flag: \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} \end{document} ``` [Apri questo esempio API luaharfbuzz in Overleaf.](/latex/it/articoli-approfonditi/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md) Questo esempio produce il seguente output: ![Harfbuzzexample.png](/files/ed1f01c4423e88bb7f48557e42e63a342b01e9dd) ## Sezione bonus: Divertirsi con la matematica emoji Per concludere con una nota leggera, un membro del team di Overleaf ha usato [`emoji` pacchetto LaTeX](https://ctan.org/pkg/emoji?lang=en) per creare un esempio divertente: ```latex \documentclass{article} \usepackage{emoji} \usepackage{unicode-math,fontspec} \setmainfont{STIX} \setmathfont{STIX Two Math} \begin{document} \newcommand{\emomath}[1]{\text{\emoji{#1}}} \[ e^{\emomath{droplet} \ln\emomath{smile}}=\emomath{sweat-smile} \] \[ e^{\emomath{eye}\emomath{pie}}=-1 \] \end{document} ``` [Apri questo divertente esempio in Overleaf](https://www.overleaf.com/docs?engine=lualatex\&snip_name=Fun+with+emoji+math\&snip=%5Cdocumentclass%7Barticle%7D%0A%5Cusepackage%7Bemoji%7D%0A%5Cusepackage%7Bunicode-math%2Cfontspec%7D%0A%5Csetmainfont%7BSTIX%7D%0A%5Csetmathfont%7BSTIX+Two+Math%7D%0A%5Cbegin%7Bdocument%7D%0A%5Cnewcommand%7B%5Cemomath%7D%5B1%5D%7B%5Ctext%7B%5Cemoji%7B%231%7D%7D%7D%0A%5C%5B%0Ae%5E%7B%5Cemomath%7Bdroplet%7D+%5Cln%5Cemomath%7Bsmile%7D%7D%3D%5Cemomath%7Bsweat-smile%7D%0A%5C%5D%0A%5C%5B%0Ae%5E%7B%5Cemomath%7Beye%7D%5Cemomath%7Bpie%7D%7D%3D-1%0A%5C%5D%0A%5Cend%7Bdocument%7D) Questo esempio produce il seguente output: ![Emojimath2.png](/files/91fe2bda05b345abc3a7af6ac2a57e942a1bfeb5) --- # 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/articoli-approfonditi/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.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.