> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/artigos-aprofundados/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md). # Uma visão geral das tecnologias que suportam a utilização de fontes emoji coloridas em LaTeX ## Introdução Este artigo apresenta uma visão geral de vários [tópicos de contexto](#which-topics-do-we-cover) relacionados com a utilização de tipos de letra OpenType coloridos para compor emoji a cores em LaTeX. Tentámos fornecer uma ampla gama de materiais, abrangendo um amplo espetro de interesses e níveis de conhecimento. Para manter o artigo manejável, a nossa cobertura de certos tópicos omite muitos detalhes técnicos, mas esperamos que haja material suficiente para orientar a sua exploração da composição de emoji a cores em LaTeX. **Atualização (julho de 2023)**: Este artigo foi publicado pela primeira vez em agosto de 2021 e revisto em julho de 2023 para atualizar a secção sobre [Utilização de tipos de letra OpenType coloridos baseados em SVG com LuaHBTeX](#using-svg-based-opentype-color-fonts-with-luahbtex). ### Que tópicos abrangemos? Este artigo aborda os seguintes tópicos gerais: * Unicode: a norma que codifica emoji como caracteres e codifica o seu comportamento esperado em aplicações de processamento de texto e composição tipográfica. * Tipos de letra OpenType coloridos: tipos de letra especializados que fornecem representações coloridas de caracteres emoji exibidos no seu documento LaTeX. * Formatação de texto: introdução a um componente essencial da composição de línguas de escrita complexa e de emoji. * HarfBuzz: o componente do LuaHBTeX que permite a composição avançada multilingue e a utilização de tipos de letra OpenType coloridos para compor emoji em LaTeX. * Diferentes motores TeX: explorar o seu suporte para tipos de letra OpenType coloridos e selecionar qual motor TeX utilizar. * A API HarfBuzz do LuaHBTeX: uma introdução à “magia” por detrás de [a formatação de texto](#the-concept-of-text-shaping) no LuaHBTeX. ### Três formas de compor emoji a cores Os emoji a cores podem ser compostos com LaTeX utilizando três métodos principais: 1. Utilizando ferramentas gráficas padrão do LaTeX, como TikZ, MetaPost ou Asymptote, para desenhar o emoji. 2. Inserindo emoji usando gráficos de emoji previamente preparados e armazenados em ficheiros externos. 3. Tratando os emoji como texto codificado em Unicode e utilizando [a formatação de texto](#the-concept-of-text-shaping) com [tipos de letra OpenType coloridos](#opentype-color-fonts) para os compor. As opções práticas para incluir emoji a cores no seu documento LaTeX dependem do motor TeX utilizado para compilar esse documento: isto é, se está a utilizar: * pdfLaTeX: motor pdfTeX + LaTeX; * XeLaTeX: motor XeTeX + LaTeX; * LuaLaTeX: motor LuaHBTeX (a partir do TeX Live 2020) + LaTeX. Todos estes três motores TeX podem utilizar ferramentas ou pacotes LaTeX para desenhar emoji ou utilizar `\includegraphics{...}` para inserir emoji armazenados em ficheiros gráficos externos. Desenhar ou importar gráficos são técnicas ideais para compor emoji quando precisa de uma solução que não dependa do motor TeX utilizado para compilar o documento LaTeX. No entanto, se o seu fluxo de trabalho lhe der flexibilidade para escolher um motor TeX específico, e preferir utilizar tipos de letra OpenType coloridos e processamento de texto baseado em Unicode, a versão mais recente do LuaTeX, chamada LuaHBTeX, é o que precisa. A partir do TeX Live 2020, o LuaHBTeX é utilizado para compilar documentos LaTeX baseados no formato LuaLaTeX. ## Contexto sobre Unicode e caracteres emoji ### Codificações de caracteres Os computadores armazenam, transmitem e processam texto usando uma sequência de valores numéricos (inteiros) que representam os *caracteres*. O processamento fiável de texto exige que os produtores e consumidores de texto concordem sobre quais valores inteiros devem ser usados para representar caracteres individuais no fluxo de texto. Por outras palavras, qual é a *carácter* *codificação?* Uma codificação é o conjunto de valores inteiros acordados atribuídos para representar um certo conjunto de caracteres: cada caractere é representado por um valor inteiro na codificação que está a ser usada. ### Entra o Unicode Historicamente, na era do texto de 8 bits, eram utilizadas muitas codificações de caracteres diferentes, levantando sempre o espectro de *incompatibilidades de codificação*: produtores e consumidores de texto assumindo por engano codificações diferentes, resultando em erros de processamento de texto. Quem trabalhou com TeX/LaTeX durante alguns anos provavelmente terá encontrado incompatibilidades de codificação entre o texto de entrada e os tipos de letra usados para compor um documento. Se os tipos de letra do documento estiverem configurados para usar uma codificação diferente da do texto, isso provavelmente resulta em caracteres em falta ou errados no PDF composto. Estes problemas históricos de codificação podem ser resolvidos com a ajuda de uma norma internacional que codifica todos os caracteres do mundo: o Unicode. A norma Unicode não é estática, mas é atualizada periodicamente para incluir caracteres e sistemas de escrita adicionais no seu esquema de codificação. Existe um [processo formal de revisão para propor novos caracteres](http://www.unicode.org/pending/proposals.html) com um [esquema específico para novos caracteres emoji](https://www.unicode.org/emoji/proposals.html). ### Quantos caracteres Unicode? Unicode codifica um máximo teórico de 1,114,112 caracteres. Cada um dos 1,114,112 valores inteiros é chamado um *ponto de código*: o valor inteiro atribuído para identificar cada caractere. No entanto, por várias razões técnicas, apenas [1,112,064 pontos de código](https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology) podem ser atribuídos a caracteres reais: 2048 pontos de código não podem ser atribuídos e é proibido o seu uso dentro de texto em conformidade com Unicode. No momento em que escrevemos (a primeira versão deste artigo), a Versão 13 da norma Unicode tinha alocado um total de 143,859 pontos de código a caracteres reais, incluindo [3304 caracteres agora codificados como emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (ver a página 2 desse documento). O crescimento no número de caracteres codificados por Unicode está bem documentado no artigo [Quantos caracteres Unicode existem?](https://www.babelstone.co.uk/Unicode/HowMany.html) e numa [entrada da Wikipédia](https://en.wikipedia.org/wiki/Unicode#Versions). ### Planos Unicode Todo o conjunto de 1,114,112 pontos de código Unicode é agrupado em 17 chamados Planos: Plano 0 a Plano 16, cada um contendo 65536 valores de ponto de código, produzindo um total de $$17\times2^{16} = 1,114,112$$ caracteres. O Plano 0, chamado o [Plano Multilingue Básico](https://en.wikipedia.org/wiki/Plane_\(Unicode\)#Basic_Multilingual_Plane), codifica os caracteres mais frequentemente usados. Os Planos 1–16 são chamados [Planos Suplementares](http://unicode.org/glossary/#supplementary_planes). ### A ascensão dos emoji Novos caracteres surgem através da mudança dos modos de comunicação humana, e a tecnologia dos telemóveis deu origem a um desses conjuntos de caracteres: os emoji, que evoluíram no Japão durante o final da década de 1990. Não surpreende que a [FAQ do Unicode sobre Emoji](https://unicode.org/faq/emoji_dingbats.html) observa > “A palavra emoji vem do japonês [絵](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E7%B5%B5) (e ≅ imagem) + [文字](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E6%96%87) (moji ≅ caractere escrito).” Os leitores interessados no contexto e no desenvolvimento histórico dos emoji poderão encontrar interesse nesta [introdução ao Unicode](https://unicode.org/reports/tr51/#Introduction) ou o artigo [I second that emoji: Os padrões, estruturas e produção social dos emoji](https://firstmonday.org/ojs/index.php/fm/article/view/9381). Não foi até 2010, com o lançamento de [a versão 6.0 da Norma Unicode](https://www.unicode.org/versions/Unicode6.0.0/), que muitos emoji foram formalmente reconhecidos como *caracteres* em si mesmos. O Unicode 13.0 codificou [3304 caracteres como emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (ver a página 2 desse documento), com o Unicode 13.1 a listar [lista 3521 emoji](https://unicode.org/emoji/charts/emoji-counts.html). ### Os emoji vivem num plano superior Unicode atribuiu muitos caracteres emoji a pontos de código fora do Plano Multilingue Básico (BMP), codificados [no Plano 1](https://en.wikibooks.org/wiki/Unicode/Character_reference/1F000-1FFFF) com pontos de código no intervalo 1F000–1FFFF — o que tem uma consequência importante para quem quiser *copiar e colar* caracteres emoji nos editores do Overleaf (Editor de Código ou Editor Visual). Os editores de texto do Overleaf só conseguem lidar com caracteres dentro do Plano Multilingue Básico, embora esperamos que futuras atualizações introduzam suporte para caracteres fora do BMP. Note que esta limitação afeta apenas caracteres fora do BMP dentro de texto colado em ficheiros destinados a ser editados através dos editores do Overleaf. Existem outras formas de aceder a caracteres emoji: * Utilizando os comandos primitivos `\char"` ou `\Uchar"` (ver [esta secção](#optional-detail-luatexluahbtex-char-vs-uchar) do artigo). * Utilizando ficheiros de texto de entrada que contenham caracteres emoji em formato UTF-8. * Utilizando comandos LaTeX (macros) que inserem caracteres emoji. #### Colar emoji e outros caracteres fora do BMP no Overleaf Se colar um caractere emoji, por exemplo, 😀, no Editor de Código do Overleaf, neste momento será convertido nos caracteres ��. ![Erro devido a copiar + colar caracteres fora do BMP nos editores do Overleaf](/files/3b533e79361a407104377e79994e4494a314a449) O caractere � tem o ponto de código Unicode FFFD e o seu nome oficial é REPLACEMENT CHARACTER e é usado para “[substituir um caractere desconhecido, não reconhecido ou não representável](https://en.wikipedia.org/wiki/Specials_\(Unicode_block\))”. ### Utilização de pontos de código Unicode (U+) no LuaLaTeX A documentação do Unicode representa os valores dos pontos de código usando a notação `U+`— como `U+1F600`, onde `1F600` é o `` do ponto de código Unicode do caractere emoji 😀. Para usar estes valores de ponto de código no LuaLaTeX, apaga-se o `U+` e escreve-se `\char"` ou `\Uchar"`. O `"` caractere indica a um motor TeX que o número fornecido está especificado em hexadecimal. Por exemplo, para usar o emoji 😀, escreveria `\char"1F600` ou `\Uchar"1F600`— usando um tipo de letra capaz de o compor. Um exemplo mínimo de LuaLaTeX que utiliza `\char` e `\Uchar` para compor o caractere emoji 😀 pode ser: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz]{NotoColorEmoji.ttf} %Utilize \emojifont num grupo para manter os seus efeitos locais {\emojifont \Uchar"1F600 \char"1F600} \end{document} ``` [Abra este exemplo LuaLaTeX no 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) **(detalhe opcional) LuaTeX/LuaHBTeX: \char vs \Uchar** Para além do convencional `\char` comando para compor um ``, usando o tipo de letra atual, os motores LuaTeX, LuaHBTeX e XeTeX também disponibilizam o `\Uchar` comando. Do ponto de vista do utilizador, o resultado de `\char` e `\Uchar` parecem iguais, mas existe uma diferença subtil na forma como estes comandos funcionam, como observamos abaixo. **A diferença fundamental: expansão** `\Uchar` é um chamado [comando expansível](/latex/overleaf-learn-latex-pt/artigos-aprofundados/22-how-does-expandafter-work-the-meaning-of-expansion.md#expansion-a-general-term-for-a-set-of-operations) enquanto `\char` não é expansível. Quando um `\char` ou `\Uchar` comando está a ser “executado” — isto é, o comando não está a ser armazenado como parte de uma macro ou de outra lista de tokens — ocorrem as seguintes ações no interior do motor TeX: * **`\char`** instrui o motor TeX a inserir imediatamente um token de caractere, representando ``, em qualquer peça de conteúdo que esteja atualmente a compor. * Em contraste, **`\Uchar`** tem dois passos de processamento distintos: 1. O `\Uchar` comando é *expandido*, e o `` é convertido numa lista temporária de tokens contendo um único [token de carácter](/latex/overleaf-learn-latex-pt/artigos-aprofundados/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md#tex-tokens-101-28and-notions-of-expansion29) que representa o ``. 2. Essa lista de tokens de um único caractere está agora *disponibilizada* ao motor TeX como fonte da sua próxima entrada. Na prática, o motor TeX “desvia temporariamente o olhar” para usar essa lista de um único token como o local do seu próximo item de entrada (token). Por defeito, o motor TeX simplesmente volta a ler (introduzir) esse token e compõe o caractere correspondente, reproduzindo o comportamento do `\char` comando. **No entanto**, porque esse `` não foi composto imediatamente, mas temporariamente *armazenados* (guardado) como um único token, os comandos TeX primitivos ou macros LaTeX podem fazer uso (absorver) desse token — não tem de ser composto de imediato, mas pode ser usado em processamento adicional conforme necessário. Na prática, `\char` diz “componha isto `` agora”, enquanto `\Uchar` tem uma forma de “ação retardada” ao criar um token de caractere armazenado e disponibilizá-lo como o próximo item de entrada (um token). Esse token pode ser utilizado (absorvido) por comandos e macros TeX ou relido pelo motor TeX e composto. ### Unicode (codificação) não conta a história toda A capacidade de usar caracteres emoji em texto codificado em Unicode é apenas parte da história do sucesso dos emoji. O aumento do uso de emoji também foi possibilitado pelos desenvolvimentos na [tecnologia de tipos de letra OpenType](https://learn.microsoft.com/en-us/typography/opentype/)— tipos de letra cujos dados de glifos (desenhos de caracteres) podem conter [dados de cor](https://learn.microsoft.com/en-us/typography/opentype/spec/colr): as chamadas [tipos de letra OpenType coloridos](#opentype-color-fonts). Para além de tipos de letra adequados, a utilização de emoji a cores requer componentes de software adicionais, cujas tarefas incluem: * pré-processamento (“[formatação](#the-concept-of-text-shaping)”) de texto codificado em Unicode, *prepará-lo* para exibição usando um tipo de letra específico; * *renderização e exibição* dos emoji coloridos de um tipo de letra *glifos* no ecrã de um dispositivo. #### Glifo vs. caractere: não são a mesma coisa? Os termos “glifo” e “caractere” são muitas vezes usados como se fossem intercambiáveis — referindo-se ao mesmo conceito básico —, mas existe uma diferença subtil, embora importante, no seu significado. Unicode [define o termo “caractere”](http://www.unicode.org/glossary/#character) como: > “O menor componente da linguagem escrita que tem valor semântico; refere-se ao significado abstrato e/ou forma, em vez de uma forma específica… ” Em contraste, um “glifo” é um *específico* *forma* (desenho) para a *representação visual* de um particular *carácter*. A questão caractere vs. glifo observa-se facilmente quando texto carregado de emoji é visualizado em vários sistemas/plataformas de software, como ao ler o mesmo texto no seu telemóvel com iOS ou Android, ou num computador de secretária com Windows. Seja qual for o dispositivo ou plataforma usada, o texto subjacente (sequência de caracteres) conteria os mesmos caracteres codificados em Unicode. *emoji* *caracteres*. São as capacidades específicas do dispositivo envolvidas no *pré-processamento* desse texto que depois *renderização* e *exibição* dos resultados, talvez usando tipos de letra específicos do dispositivo, o que produz glifos diferentes (desenhos de caracteres) para representar os mesmos caracteres emoji. Do [Unicode Full Emoji List](https://unicode.org/emoji/charts/full-emoji-list.html) fornece imagens de exemplo que representam cada caractere emoji Unicode — demonstrando vários glifos usados por diferentes fornecedores de tecnologia. Não só os designers de tipos de letra adotam os seus próprios desenhos particulares (glifos) para representar caracteres emoji, como os tipos de letra individuais também variam no número de caracteres emoji que suportam (para os quais contêm glifos) e podem ou não conter funcionalidades mais avançadas de processamento de texto emoji incluídas nas especificações emoji do Unicode. A noção e o conceito de caracteres, a sua semântica e codificação, constituem a base do mundo do Unicode: este trata de caracteres. O desenho e a representação visual de caracteres individuais, como glifos, pertencem às tecnologias de tipos de letra e ao ofício do design tipográfico. #### Emoji Unicode: muito mais do que codificação de texto O papel central do Unicode é fornecer uma norma global de codificação que define qual valor inteiro, chamado *ponto de código,* deve ser usado para representar cada caractere, incluindo emoji, no interior de um fluxo de texto codificado em Unicode. A especificação do Unicode para emoji também define *comportamentos de processamento* para certos *sequências* de caracteres emoji que aparecem num fluxo de texto codificado em Unicode. Sequências definidas de caracteres emoji podem ser “fundidas” através de um processo chamado [a formatação de texto](#the-concept-of-text-shaping) para produzir um único glifo emoji resultante (“compósito”) — esse único glifo seria usado pelo sistema operativo do dispositivo para representar a sequência original de caracteres presente no texto. O Relatório Técnico do Unicode sobre [Emoji Unicode](https://unicode.org/reports/tr51/) documenta o rico conjunto de funcionalidades disponível para software que pretenda fornecer processamento de caracteres emoji em conformidade com Unicode. Por exemplo, o Unicode define (codifica) caracteres chamados [modificadores de emoji](http://www.unicode.org/reports/tr51/#Emoji_Modifiers_Table) que podem ser usados para gerar *variações* de caracteres emoji “base”, como variações em [tom de pele com base na escala de Fitzpatrick](http://www.unicode.org/reports/tr51/#Diversity). Note que o conjunto de caracteres emoji base e os modificadores aplicáveis são definidos como parte da norma global [Unicode emoji](http://www.unicode.org/reports/tr51). A página Unicode [Emoji Sequences](http://unicode.org/emoji/charts/emoji-sequences.html) fornece um quadro das sequências atualmente previstas pela especificação Unicode. Coloque o ponteiro do rato sobre qualquer uma das imagens de glifos emoji para ver uma pequena dica flutuante que indica a sequência subjacente de caracteres emoji Unicode que produz esse glifo: ![EmojiSequenceChart.png](/files/77d9e66e32e156ff5a02d6eea8843eb51e55395a) Por exemplo, o glifo emoji: ![HandMediumSkinTone.png](/files/75b08f8f89e6a7a07813876d411a561f1e0d2135) está listado na [secção de sequências de modificadores](http://unicode.org/emoji/charts/emoji-sequences.html#modifier_sequences) e é produzido pela sequência de dois caracteres U+1F44B U+1F3FD. Esses caracteres componentes são: U+1F44B:![UnicodeWavingHandDefault.png](/files/5ad323ef071b31db9548244debb05c1667630e06) (MÃO A ACENAR) U+1F3FD:![FitzPatrick3.png](/files/bcbb1fe4e148b3fbb2023f327a3e8205ccf18cee) (MODIFICADOR DE EMOJI FITZPATRICK TIPO-4) **Utilização de modificadores de tom de pele no LuaHBTeX** O exemplo seguinte usa LuaHBTeX para demonstrar a utilização de modificadores de emoji: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=HarfBuzz,SizeFeatures={Size=20}]{NotoColorEmoji.ttf} Mão a acenar isolada: {\emojifont\Uchar"1F44B}\par Modificador isolado: {\emojifont\Uchar"1F3FD}\par Resultado combinado: {\emojifont\Uchar"1F44B\Uchar"1F3FD} \end{document} ``` [Abra este exemplo de modificadores de emoji LuaLaTeX no 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) Este exemplo produz a seguinte saída: ![ModifiersInLuaHBTeX.png](/files/71b0d7a52de3a13060e52e1b3ec2524bec8260d4) #### UTF-8: o seu papel no armazenamento de texto Unicode Qualquer texto ou código que escreva ou cole no Editor de Código do Overleaf (ou Editor Visual) será armazenado no formato UTF-8, por isso vamos rever brevemente o que UTF-8 realmente significa. UTF significa Unicode Transformation Format, e o papel do UTF-8 no armazenamento ou transmissão de texto codificado em Unicode é indicado pela expressão “Transformation *Format*.” Os valores dos pontos de código do Unicode variam de 0 a um máximo de 1,114,111, pelo que é impossível representar todos os valores de caracteres Unicode usando um único byte de 8 bits, que só pode armazenar até 256 valores diferentes: 0 a 255. No entanto, é possível representar qualquer inteiro de ponto de código Unicode usando uma *sequência consecutiva* de valores do tamanho de um byte — que é o princípio por trás do UTF-8. UTF-8 fornece uma “receita” para *transformar* (isto é, “codificar” ou “converter”) um valor inteiro de ponto de código Unicode numa sequência única de 1 a 4 inteiros consecutivos do tamanho de um byte: o número de bytes consecutivos necessários depende do valor do inteiro do ponto de código. Consequentemente, pode ler-se que o UTF-8 armazena caracteres Unicode como *sequências multibyte* porque um único caractere Unicode (inteiro de ponto de código) é representado em UTF-8 como uma sequência de 1 a 4 bytes consecutivos. Naturalmente, o texto armazenado em UTF-8 pode ser convertido de volta para a sua sequência original de valores inteiros de pontos de código Unicode — é isso que o XeTeX ou o LuaTeX/LuaHBTeX têm de fazer ao ler um ficheiro de entrada LaTeX armazenado em formato UTF-8. Esses motores TeX precisam de conhecer os valores de ponto de código Unicode de entrada (caractere) antes de poderem compor o texto. Note que o pdfTeX não tem capacidade integrada de descodificação UTF-8, por isso tem de recorrer a macros TeX para processar (descodificar) texto de entrada formatado em UTF-8. **Alguns exemplos de UTF-8** * O caractere árabe ش (“sheen”) tem o ponto de código Unicode 0634 em hexadecimal (base 16) ou 1588 em decimal (base 10). Em UTF-8, ش é representado por 2 valores (hexadecimais) D8 e B4, pelo que o caractere ش seria armazenado como os dois bytes consecutivos D8B4 no interior de texto codificado em UTF-8. * O caractere emoji 😀 tem o ponto de código Unicode 1F600 em hexadecimal (base 16) ou 128512 em decimal (base 10). Em UTF-8, 😀 é representado por 4 valores (hexadecimais) F0, 9F, 98 e 80, pelo que o caractere 😀 seria armazenado como os 4 bytes consecutivos F09F9880 num ficheiro de texto UTF-8. #### Caracteres especiais usados no processamento de texto emoji baseado em Unicode Nem todo o caractere codificado em Unicode se destina a apresentação visual através dos glifos num tipo de letra: alguns caracteres codificados são designados como *caracteres não imprimíveis* cujo objetivo é ajudar funções especializadas de processamento de texto (em software de apoio). Diferentes aplicações de software fornecem níveis variados de suporte para os caracteres não imprimíveis codificados no Unicode, pelo que o resultado dependerá do ambiente de software — aplicações e tipos de letra — que estiver a ser usado. **Dois caracteres não imprimíveis a conhecer** * **Juntor de largura zero (ZWJ)**, ponto de código 200D (hexadecimal), é, como o próprio nome sugere, concebido para desencadear o “comportamento de ligação” dos caracteres de entrada — mas apenas se esses caracteres de entrada *possuírem* um comportamento de ligação definido. * **Não juntor de largura zero (ZWNJ)**, ponto de código 200C (hexadecimal), é concebido para *impedir* o “comportamento de ligação” que os caracteres de entrada poderiam, de outra forma, exibir. Por exemplo, pode usar o ZWNJ para impedir o comportamento de ligação de caracteres árabes consecutivos que normalmente seriam processados (formatados) nas suas formas de ligação. O Unicode publicou uma lista de [Sequências ZWJ Recomendadas de Emoji](https://unicode.org/emoji/charts/emoji-zwj-sequences.html) que usam um U+200D ZERO WIDTH JOINER (ZWJ) para combinar sequências de caracteres emoji num único glifo emoji compósito — se estiver disponível no(s) tipo(s) de letra em uso. **Exemplo de utilização de não juntor de largura zero** O seguinte fragmento mínimo de código usa o tipo de letra OpenType Scheherazade, incluído no TeX Live, para definir um tipo de letra LaTeX chamado `\arabicfont` que podemos usar para compor algum árabe. A linha ```latex {\arabicfont Sem ligação:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} ``` usa um caractere não juntor de largura zero, através de `\Uchar"200C`, para impedir o comportamento normal de ligação das duas letras árabes ل (lam) e ا (alef). Note a utilização de `\textdir TRT` para definir a direção do texto da direita para a esquerda: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\arabicfont[Script=Arabic,Renderer=Harfbuzz,SizeFeatures={Size=40}]{Scheherazade} {\arabicfont Ligação:\textdir TRT\Uchar"0644\Uchar"0627}\par {\arabicfont Sem ligação:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} \end{document} ``` [Abra este exemplo LuaLaTeX no 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) Este exemplo produz a seguinte saída: ![NonJoiner.png](/files/89f881a849b5abab3604653c8301dc7495085486) ## O conceito de “formatação de texto” Comecemos com um exemplo visual usando uma tradução em urdu da palavra “educational”. O texto da tradução em urdu pode ser digitado num teclado, ou num dispositivo com ecrã tátil, e seria criado como uma simples sequência linear de caracteres árabes Unicode. No entanto, quando esse texto é composto, ou exibido no ecrã de um dispositivo no [estilo Nastaliq](https://en.wikipedia.org/wiki/Nastaliq), o resultado é uma disposição bidimensional complexa de glifos. Usando o nosso exemplo em urdu, a imagem seguinte compara a entrada linear de árabe Unicode *caracteres* com a saída composta em estilo Nastaliq, que compreende uma disposição bidimensional de *glifos* presentes no tipo de letra (gratuito) [Awami Nastaliq](https://software.sil.org/awami/download/): ![](/files/63c7050cd5029d8795157c601bff04a75ac27c3f) O processo de “traduzir” caracteres de entrada para um conjunto de glifos de saída corretamente posicionados chama-se *a formatação de texto*formatação, e é um componente vital do processamento de texto antes da sua exibição ou composição. O nosso exemplo usou texto em urdu (escrita árabe) porque o resultado da formatação é claramente evidente, em contraste com línguas que usam a escrita latina, como o inglês, em que a formatação é muito menos pronunciada — como na produção de simples ligaduras. A formatação de texto é essencial ao usar sistemas de escrita (escritas) como [Árabe](https://en.wikipedia.org/wiki/Arabic), [Hebraico](https://en.wikipedia.org/wiki/Hebrew_language), [Devanágari](https://en.wikipedia.org/wiki/Devanagari) ou [Malaiala](https://en.wikipedia.org/wiki/Malayalam), apenas quatro exemplos das chamadas *escritas complexas*. Para garantir a apresentação correta do texto nessas escritas, e das línguas que as usam, o processo de formatação precisa de tratar cuidadosamente quaisquer regras e nuances de formatação presentes na combinação específica de escrita e língua. Por exemplo, algumas línguas exigem vários caracteres de entrada para gerar um determinado glifo de saída, ou podem existir requisitos complexos para o posicionamento cuidadoso de marcas diacríticas, e rearranjos entre glifos para garantir que os glifos individuais estão posicionados corretamente (relativamente uns aos outros). Em geral, formatar um trecho de texto requer várias informações: * O sistema de escrita ou *escrita* em que o texto é escrito. * A específica *idioma* em uso. Escritas individuais podem ser usadas para vários idiomas, com cada combinação escrita-idioma tendo as suas próprias subtilezas/nuances de composição. * A escrita *direção* do texto—como da direita para a esquerda ou da esquerda para a direita. * Um *tipo de letra* que fornece os glifos necessários para representar o texto composto e, opcionalmente, contém “regras de composição” adicionais que orientam o processo de composição de texto. Os requisitos da composição de texto, particularmente para escritas complexas e os idiomas associados, podem ser extremamente detalhados e subtis, indicando a necessidade de software especializado que possa aplicar “regras” de composição de texto potencialmente muito complexas. Não surpreendentemente, esse software existe e é referido como um *motor de composição de texto*; o que iremos discutir chama-se [HarfBuzz](https://en.wikipedia.org/wiki/HarfBuzz), cuja documentação vale a pena ler—por exemplo [Porque preciso de um motor de composição?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html). **Leitura adicional sobre composição de texto** Estas breves introduções são altamente recomendadas: * [O que é composição de texto?](https://harfbuzz.github.io/what-is-harfbuzz.html#what-is-text-shaping) * [Porque preciso de um motor de composição?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html) **Nota técnica: várias tecnologias de composição (modelos)** O motor de composição de texto HarfBuzz suporta várias “tecnologias de composição” que diferem na forma como implementam o processo de composição—cada implementação é referida como um *compositor*, incluindo na documentação do `luaotfload` . O foco principal deste artigo é a composição OpenType, mas uma tecnologia alternativa, de utilização gratuita, é a [Graphite](https://scripts.sil.org/cms/scripts/page.php?site_id=projects\&item_id=graphite_aboutOT), desenvolvida pela [SIL International](https://www.sil.org/). Outro modelo de composição suportado pelo HarfBuzz é a [Apple Advanced Typography (AAT)](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html)—fontes que suportam AAT são geralmente usadas em plataformas tecnológicas da Apple. **Exemplo usando o compositor Graphite** O exemplo seguinte compõe algum texto em urdu usando uma fonte chamada [Awami Nastaliq](https://software.sil.org/awami/download/), que suporta composição Graphite e está disponível no Overleaf. Awami Nastaliq foi criada por [SIL International](https://www.sil.org/), a organização responsável pelo desenvolvimento da tecnologia Graphite. O exemplo seguinte demonstra a capacidade avançada de composição de fontes baseadas em Graphite—repare em como a `luaotfload` declaração da fonte seleciona a composição 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 % Educacional \pardir TRT\textdir TRT \urdutest تعلیمی \end{document} ``` [Abra este exemplo no 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) Este exemplo produz a seguinte saída: ![](/files/a7d434eb64cd3b8271d967d334ac7a0901b43477) #### Emoji e composição de texto A composição de texto foi introduzida usando exemplos de uma língua de escrita complexa, o urdu. No entanto, pode ser surpreendente aprender que representar corretamente o(s) glifo(s) emoji requer que a composição de texto seja aplicada a texto Unicode contendo sequências de caracteres emoji—[como observado pelo principal programador do HarfBuzz](https://github.com/harfbuzz/harfbuzz/issues/2428#issuecomment-639108677): > ...compor emoji com HarfBuzz está completamente no âmbito e é, na verdade, necessário para obter emoji de família, cor da pele, etc. Veremos exemplos disto. ### Divisão de responsabilidades: motor de composição de texto + fontes OpenType Na prática, a composição de texto é uma “operação conjunta”, ou divisão de trabalho, entre a lógica e as regras incorporadas no motor de composição de texto e regras e dados de composição adicionais incorporados na(s) fonte(s) em uso—a partir de agora cobrimos a composição baseada em OpenType *apenas*. Para efetuar a composição, o motor de composição de texto é normalmente fornecido com algum texto Unicode, uma escrita e idioma especificados, possivelmente uma direção de escrita e, mais importante, uma fonte OpenType a usar durante o processo de composição—a fonte fornecerá a saída: um conjunto de glifos e dados de posicionamento. Se solicitado, o motor de composição pode aplicar regras adicionais ([características OpenType](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features)) contidas na fonte OpenType em uso—quais regras aplicar são normalmente selecionáveis pelo utilizador a partir da lista de características suportadas pela fonte. O resultado do processo de composição é uma *lista de glifos* contida na fonte OpenType, juntamente com dados de *entre glifos* de posicionamento. Esses dados de posicionamento referem-se ao *posicionamento relativo dos glifos compostos*; não se referem ao posicionamento absoluto dentro da página composta ou de outro meio/conteúdo, como uma página web, Tweet, etc. O software de renderização (motor de composição tipográfica, navegador web, etc.) usa a informação de posicionamento entre glifos para garantir que os glifos são corretamente posicionados relativamente uns aos outros depois de serem montados e incorporados na saída final. #### O que é uma lista de glifos? Internamente, a cada glifo dentro de uma fonte OpenType é atribuído um identificador numérico, um valor inteiro chamado índice de glifo—também chamado identificador de glifo ou GID. Após concluir a sua tarefa de composição, o motor de composição de texto devolverá os seus resultados como uma *lista de identificadores de glifo* mais *dados de posicionamento* para esses glifos. Glifos individuais dentro de fontes OpenType são atribuídos a índices (identificadores) pelo criador da fonte, tornando-o um valor altamente específico da fonte e arbitrário—também pode variar entre versões de uma fonte em particular. Nunca deve assumir que o mesmo valor GID se aplicará a glifos “semelhantes” em fontes diferentes; quase de certeza não se aplicará. Se tiver uma lista de identificadores de glifo fornecida por um motor de composição, só os pode usar para aceder aos glifos na fonte da qual foram obtidos. #### O que são fontes OpenType? A web está *repleta* de explicações e detalhes sobre fontes OpenType, por isso vamos limitar-nos a uma breve descrição. A [especificação OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/) é um documento complexo concebido para programadores, mas, em essência, define um formato de ficheiro, ou contentor, para dados de fontes. Uma fonte OpenType contém dados que descrevem as formas dos glifos, juntamente com informação sobre a(s) escrita(s) e idioma(s) suportados, metadados sobre a fonte e várias “tabelas” que definem [características tipográficas](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features) suportadas pela fonte. Um motor de composição de texto pode normalmente ser instruído a aplicar seletivamente (usar) as características de uma fonte durante o processo de composição, aplicando efeitos tipográficos específicos (“regras”) que selecionam o conjunto apropriado de glifos contidos na fonte. A fonte escolhida precisará de suportar, e fornecer os glifos para, quaisquer características que o motor de composição de texto seja solicitado a aplicar. #### Glifos codificados e não codificados As fontes OpenType incluem uma tabela de dados chamada [cmap](https://docs.microsoft.com/en-us/typography/opentype/spec/cmap) (Character to Glyph Index Mapping) que mapeia o conjunto de caracteres Unicode, suportados pela fonte, para o índice de glifo correspondente nessa fonte. O vídeo seguinte oferece um breve vislumbre da tabela cmap contida numa fonte chamada `lmmono10-regiular.otf` (incluída no TeX Live). {% embed url="" %} No entanto, as fontes normalmente contêm muitos glifos que não representam um caráter Unicode específico e não estão incluídos como parte dessa tabela cmap. Consequentemente, o conjunto de glifos presentes dentro de uma fonte OpenType pode ser dividido em dois conjuntos principais: * glifos codificados que representam caracteres Unicode; * glifos não codificados que não representam caracteres Unicode. Os glifos codificados podem ser acedidos incluindo o caráter Unicode apropriado no texto—mas e os glifos não codificados, como são usados/acedidos? Esses glifos são normalmente usados para fornecer a saída das operações de composição de texto, incluindo a aplicação de características de fonte para produzir efeitos visuais/tipográficos específicos. ### tipos de letra OpenType coloridos Espera-se que os caracteres emoji sejam exibidos/renderizados em cor total—emoji a preto e branco não proporcionam propriamente a “experiência emoji completa”. No entanto, na altura da codificação inicial dos emoji pelo Unicode, a [especificação de fontes OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/) não tinha qualquer disposição adequada para incorporar *colorful*dados de glifos dentro de fontes OpenType. Esta “lacuna” no OpenType levou os principais fornecedores de tecnologia/plataformas a procurar soluções, e a subsequente “corrida” resultou em [várias propostas para estender o OpenType](https://www.fontlab.com/news/color-font-format-proposals/) para suportar fontes de cor OpenType—not apenas para exibir caracteres emoji coloridos (glifos), mas para renderizar qualquer glifo em cor. #### Quatro variantes de fontes de cor OpenType [Adobe, Microsoft, Google e Apple apresentaram propostas](https://www.fontlab.com/news/color-font-format-proposals/) para estender o OpenType a fim de suportar fontes OpenType a cores e, no final, quatro propostas foram adotadas e incluídas na especificação formal OpenType. Por conveniência, podemos agrupar grosseiramente essas quatro variantes em baseadas em vetores e baseadas em raster—mas, como mostrado neste [repositório GitHub](https://github.com/simoncozens/test-fonts), a especificação OpenType é suficientemente flexível para suportar ficheiros de fontes de cor OpenType que combinam essas quatro tecnologias de base. * **Fontes OpenType baseadas em vetores:** * **Microsoft**: as formas dos glifos são descritas usando uma forma de vetores de cor em camadas ([COLR](https://docs.microsoft.com/en-us/typography/opentype/spec/colr) e [CPAL](https://docs.microsoft.com/en-us/typography/opentype/spec/cpal) tabelas). * [**Adobe e Mozilla**](https://www.w3.org/2013/10/SVG_in_OpenType/) ([tabela SVG](https://docs.microsoft.com/en-us/typography/opentype/spec/svg)): as formas dos glifos são desenhadas usando SVG, que suporta glifos construídos a partir de vetores *e imagens raster*. Veja também [guia do utilizador da Adobe sobre fontes SVG](https://helpx.adobe.com/fonts/user-guide.html/fonts/using/ot-svg-color-fonts.ug.html). * **Fontes OpenType baseadas em raster:** * **Google**: os glifos são representados por imagens PNG a cores incorporadas na fonte ([CBDT](https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt) e [CBLC](https://docs.microsoft.com/en-us/typography/opentype/spec/cblc) tabelas). * **Apple**: os glifos também são representados por imagens a cores incorporadas na fonte. Além de PNG, o mecanismo da Apple ([tabela sbix](https://docs.microsoft.com/en-us/typography/opentype/spec/colr)) também suporta JPEG e TIFF. Como consequência, os sistemas operativos e o software de aplicação que suportam fontes de cor OpenType precisam de lidar com o panorama tecnológico misto atual. Além disso, deve estar ciente de que fontes individuais de cor OpenType—e *versões* da mesma fonte—irão: * ter cobertura diferente do conjunto completo de [caracteres emoji Unicode](https://unicode.org/emoji/charts/emoji-list.html)—ou seja, para quantos caracteres emoji a fonte fornece glifos; * usar desenhos de glifos diferentes para representar caracteres emoji individuais; * variar nas características que fornecem para suportar usos mais avançados dos padrões Unicode, como [modificadores de emoji](https://unicode.org/reports/tr51/#Emoji_Modifiers_Table), e outras capacidades de processamento de texto de emoji descritas em [Unicode Technical Standard #51: Unicode Emoji](https://unicode.org/reports/tr51/). #### O burburinho em torno do HarfBuzz Já aludimos à necessidade de um *motor de composição de texto*motor de composição de texto: software que pega em algum texto Unicode de entrada, escrito usando uma combinação específica de escrita e idioma, e, usando uma fonte designada, compõe esse texto numa sequência de glifos, juntamente com dados de posicionamento, que podem ser usados para compor tipograficamente o texto de entrada original. [HarfBuzz](https://harfbuzz.github.io/) é um desses motores de composição de texto: é [uma biblioteca de código aberto](https://github.com/harfbuzz/harfbuzz) e o resultado de mais de uma década de investigação e desenvolvimento—e ainda está a ser ativamente desenvolvido e implementado como parte de muitos produtos de software. O HarfBuzz em si não executa “composição tipográfica”, mas fornece “serviços de composição de texto” ao software que optar por o integrar, incluindo XeTeX, LuaHBTeX, [Adobe Photoshop e Adobe InDesign](https://en.wikipedia.org/wiki/HarfBuzz). Ao incorporar o HarfBuzz, os motores TeX podem tirar partido das suas capacidades avançadas de composição de texto para fornecer composição tipográfica multilingue muito sofisticada, particularmente para escritas complexas como árabe, hebraico, devanágari e muitas outras. Note também que o HarfBuzz é usado para processar e compor caracteres Unicode emoji, o que exploraremos com mais detalhe. O gráfico seguinte resume o papel desempenhado pelo HarfBuzz quando integrado com software, como XeTeX ou LuaHBTeX, durante a composição de texto numa escrita complexa, como o árabe: ![Uma visão geral da composição de texto árabe com HarfBuzz](/files/5104ae99ac76e6db5564d95bad6d3d99e480562b) **Explorar o HarfBuzz** Qualquer pessoa interessada em saber mais sobre o HarfBuzz e os serviços de composição OpenType que ele fornece ao XeTeX e ao LuaHBTeX pode [descarregar uma distribuição binária do HarfBuzz](https://github.com/harfbuzz/harfbuzz/releases) que contém a biblioteca HarfBuzz (para programadores) e utilitários de linha de comando `hb-view` e `hb-shape`. **Exemplo: como usar hb-view** Crie um novo ficheiro no seu editor de texto favorito com suporte UTF-8 e copie/cole os seguintes seis caracteres emoji 👋👋🏻👋🏼👋🏽👋🏾👋🏿 para esse ficheiro de texto; depois, guarde-o em formato UTF-8 num ficheiro chamado, por exemplo, `emoji.txt`. Note que o seu editor de texto pode mostrar versões a preto e branco dos emoji porque não consegue (ou não está programado para) renderizar glifos a cores. Assim que esses 6 emoji forem guardados, o ficheiro `emoji.txt` deverá conter dados UTF-8 para a seguinte sequência de caracteres emoji Unicode—separamos os modificadores de emoji com vírgulas apenas para *facilitar a leitura*: * `1F44B` para produzir 👋 * `1F44B`, `1F3FB` para produzir 👋🏻 * `1F44B`, `1F3FC` para produzir 👋🏼 * `1F44B`, `1F3FD` para produzir 👋🏽 * `1F44B`, `1F3FE` para produzir 👋🏾 * `1F44B`, `1F3FF` para produzir 👋🏿 Deve haver um total de **11** caracteres Unicode, cada um gerando 4 bytes de dados UTF-8, pelo que o `emoji.txt` ficheiro deverá ter 44 bytes de comprimento, excluindo quaisquer marcadores de fim de linha usados no final da linha que contém o emoji. O `hb-view` utilitário pode usar o ficheiro `emoji.txt`, juntamente com uma fonte de cor OpenType adequada à sua escolha, como `NotoColorEmoji.ttf`, para gerar um ficheiro SVG da saída composta pelo HarfBuzz. O exemplo de linha de comando seguinte, que deve ser **escrito numa única linha** no seu terminal, irá gerar o ficheiro SVG `emoji.svg`: ```latex hb-view --font-size=20 --output-file="emoji.svg" --output-format=svg --text-file=emoji.txt --font-file=NotoColorEmoji.ttf ``` Em caso de execução bem-sucedida, o ficheiro `emoji.svg`, gerado por `hb-view`, pode ser aberto pelo Inkscape e deverá ter um aspeto semelhante a isto: ![Hbvieemoji.png](/files/19de6bb3e95a11d2c77bc487f15c00a0e335002b) `hb-view` pode ser usado para explorar a composição HarfBuzz para qualquer ficheiro de texto Unicode e fonte OpenType adequados—certamente não se limita ao uso com emoji! Escreva ```latex hb-view --help-all ``` para ver a riqueza de opções de linha de comando para este utilitário poderoso e prático. Boa composição! ## Composição de texto e motores TeX Aqui, vamos rever as capacidades de composição de texto do XeTeX e da família de motores TeX LuaTeX. ### XeTeX O XeTeX foi desenvolvido no início dos anos 2000 e foi pioneiro em várias inovações na composição tipográfica baseada em TeX, nomeadamente *suporte* incorporado para: * leitura de texto Unicode em formato UTF-8; * utilização de fontes OpenType; * composição de texto para composição tipográfica multilingue; * composição tipográfica matemática baseada em OpenType. A capacidade do XeTeX de compor de forma fácil e conveniente idiomas com escrita complexa deve-se às suas capacidades incorporadas de composição de texto—originalmente baseadas no, agora obsoleto, [ICU LayoutEngine](http://userguide.icu-project.org/layoutengine). Graças ao trabalho de Khaled Hosny, o XeTeX passou a usar o HarfBuzz para composição de texto, como referido num anúncio de [março de 2013](https://tug.org/pipermail/xetex/2013-March/024118.html). Para quem quiser compor texto multilingue, o XeTeX é normalmente citado como o motor TeX de eleição—mas agora existe outra opção, LuaHBTeX, que iremos explorar. ### LuaTeX e LuaHBTeX O desenvolvimento do LuaTeX começou por volta de 2005, mas seguiu uma filosofia de design bastante diferente da do XeTeX, que incorporou novas funcionalidades *diretamente no* software XeTeX. Em contraste com o XeTeX, os programadores do LuaTeX optaram por “...fornecer um conjunto mínimo de ferramentas e nenhuma solução.” (ver [Manual de Referência do LuaTeX](https://www.pragma-ade.com/general/manuals/luatex.pdf)). Em vez de fornecer um conjunto de funcionalidades adicionais *integradas no* motores baseados em LuaTeX, os mecanismos internos dos motores LuaTeX são abertos para que programadores e utilizadores experientes possam aproveitar a linguagem de script Lua integrada para construir as suas próprias soluções. Por exemplo, ao contrário do XeTeX, o motor LuaTeX não pode *diretamente* usar fontes OpenType; em vez disso, as fontes OpenType têm de ser carregadas e “preparadas para uso” através de funções de carregamento de fontes escritas em código Lua. Essas funções de carregamento de fontes são referidas como *funções de retorno* funções: código Lua que o LuaTeX irá chamar (“executar”) quando é feita uma solicitação para carregar uma fonte. Além disso, o motor LuaTeX não fornece quaisquer *suporte* capacidades de composição de texto—essas também têm de ser fornecidas por código externo ao qual o motor LuaTeX possa recorrer para lhe fornecer serviços de composição de texto. Mais uma vez, isto contrasta com o motor XeTeX, que incorporou capacidades de composição de texto no software principal. #### luaotfload: essencial para usar fontes OpenType em LuaTeX/LuaHBTeX O mecanismo de retorno do LuaTeX para carregamento de fontes proporciona uma grande flexibilidade, embora à “custa” de programação adicional. Felizmente para os utilizadores do LuaLaTeX, a comunidade TeX desenvolveu um pacote chamado `luaotfload`, que faz parte do [lançamento anual do TeX Live](https://www.tug.org/texlive/) e está, claro, disponível para os utilizadores do Overleaf. `luaotfload` é [disponível no CTAN](https://ctan.org/pkg/luaotfload?lang=en) e tem um [repositório de desenvolvimento no GitHub](https://github.com/latex3/luaotfload) onde pode acompanhar os desenvolvimentos mais recentes e [novos lançamentos](https://github.com/latex3/luaotfload/releases). `luaotfload` pode ser carregado diretamente no preâmbulo de um documento LaTeX através de ```latex \usepackage{luaotfload} ``` Note que `luaotfload` é o nome de um *pacote*, o que significa que tem o nome de ficheiro `luaotfload.sty`. Se quisesse usar `luaotfload` com plain TeX, pode fazê-lo adicionando a linha ```latex \input luaotfload.sty ``` ao seu documento plain TeX. Normalmente, os utilizadores do LuaLaTeX—ou seja, aqueles que compõem LaTeX usando LuaTeX/LuaHBTeX—não precisam de lidar diretamente com `luaotfload` porque o [`fontspec` pacote](https://ctan.org/pkg/fontspec) carregará o `luaotfload` pacote por si, tratando de muitos detalhes de baixo nível através de comandos ao nível do utilizador fornecidos pelo `fontspec` pacote. ### LuaHBTeX: novas opções para composição de texto `luaotfload` é uma biblioteca Lua madura e poderosa que fornece o manuseamento de fontes OpenType pelo LuaTeX—juntamente com a disponibilização de serviços de composição de texto para um conjunto de idiomas e escritas. Originalmente, as funções de composição de texto do `luaotfload` eram implementadas em código Lua puro, mas o lançamento do TeX Live 2020 trouxe outra opção convencional para composição de texto—um novo motor baseado em LuaTeX chamado LuaHBTeX. O “HB” em LuaHBTeX significa HarfBuzz—em essência, LuaHBTeX é o motor LuaTeX original *mais* com um motor integrado de composição de texto HarfBuzz. Em consonância com a filosofia de design do LuaTeX, a disponibilidade do HarfBuzz não *automaticamente* garante que o texto será composto pelo LuaHBTeX: o HarfBuzz é outra ferramenta que pode ser usada para construir soluções de composição de texto. A integração do HarfBuzz no LuaHBTeX é [programável através de código Lua](#introduction-to-the-luahbtex-harfbuzz-api), o que permitiu `luaotfload`aos programadores do luaotfload adicionar soluções de composição de texto baseadas no HarfBuzz. Consequentemente, [a partir da versão 3.1, lançada em 5 de novembro de 2019](https://github.com/latex3/luaotfload/releases/tag/v3.1), `luaotfload` foi melhorado para tirar partido do HarfBuzz—tornando as capacidades de composição de texto do HarfBuzz fáceis de aceder para o utilizador comum. Os leitores interessados nos detalhes técnicos da integração do HarfBuzz com o LuaTeX podem ler este [artigo de Khaled Hosny](https://www.tug.org/TUGboat/tb40-1/tb124hosny-harfbuzz.pdf). ### luaotfload: duas opções para composição de texto (quando usar HarfBuzz?) Os utilizadores do LuaLaTeX têm agora duas opções para composição de texto: * `luaotfload`a implementação original do luaotfload (baseada em nós) de composição de texto, escrita puramente em Lua; * `luaotfload`a composição baseada em HarfBuzz do luaotfload—acedida por código Lua que chama as funções de composição de texto do HarfBuzz. `luaotfload` fornece acesso a estes dois sistemas de composição através da sua “`modo`” — embora a maioria dos utilizadores use a opção equivalente `fontspec` “`Renderer`” em vez de usar diretamente as funções de baixo nível de `luaotfload`. Cada uma das `luaotfload`soluções de composição de texto do luaotfload tem os seus pontos fortes e as suas fraquezas (atuais), mas qual deve usar, e quando? Eis alguns pontos a considerar: * `luaotfload`O processamento nativo baseado em nós do luaotfload pode consumir muita memória, particularmente com grandes fontes OpenType CJK. Usar HarfBuzz para compor texto CJK pode trazer melhorias de velocidade e reduzir o uso de memória. * Use HarfBuzz para escritas complexas porque “...melhora muito a renderização de escritas índicas e árabes e é altamente recomendado para tais escritas.” (ver `luaotfload` manual). * A integração do HarfBuzz em `luaotfload` ainda é relativamente recente e está a passar por desenvolvimento adicional. No momento da escrita (julho de 2021), é aconselhável usar a composição integrada do luaotfload (definindo `mode=node`) para as fontes principais do seu documento, particularmente se o documento usar a escrita latina. Veja este [problema no GitHub](https://github.com/latex3/luaotfload/issues/175#issue-801120377), que resume os problemas e discussões. Se quiser experimentar, pode usar `luaotfload` para carregar um ficheiro de fonte e criar duas fontes LaTeX: uma que usa composição baseada em HarfBuzz e a outra usando composição baseada em Lua. O Overleaf criou um [projeto de exemplo](#sample-project-arabic-shaping), que demonstra isto. * Não use HarfBuzz para lidar com fontes matemáticas. Como discutido por programadores no tex.stackexchange, HarfBuzz [não foi concebido para lidar com fontes para composição tipográfica matemática](https://tex.stackexchange.com/questions/544881/does-luahbtex-with-harfbuzz-renderer-completely-supports-math-formating) por isso não o use para esse fim. **Projeto de exemplo: composição do árabe** Aqui está um projeto do Overleaf que usa várias tipografias árabes de alta qualidade para comparar `luaotfload`os serviços de composição de texto baseados em nós do luaotfload (`mode=node`) com os do HarfBuzz (`mode=harf`): * Este projeto inclui a saída mostrada na imagem seguinte: ![Compor tipograficamente o árabe](/files/e70f4639f5bc6e6d01123a871079a5392e9466b3) ### Escolher o “Renderer” no fontspec Como referido na sua [documentação](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), `fontspec` “...permite que utilizadores de XeTeX ou LuaTeX carreguem fontes OpenType num documento LaTeX”. Se usar os motores LuaTeX ou LuaHBTeX, `fontspec` carregará o `luaotfload` biblioteca para si e, além disso, fornecer um conjunto de comandos convenientes ao nível do utilizador que aliviam a necessidade de lidar com `luaotfload`a funcionalidade de baixo nível do Então, como escolhe entre a composição do HarfBuzz ou a composição integrada fornecida por `luaotfload`? A resposta está contida no excelente [`fontspec` documentação](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), especificamente na Parte VI: funcionalidades de fonte apenas para LuaTeX. `fontspec` fornece uma definição chamada `Renderer` que pode ser definida quando a fonte é definida através de `fontspec`. `Renderer` controla o processamento de baixo nível da fonte. As duas opções relevantes são * `Renderer = Node`: o “modo” predefinido para compor fontes OpenType—isto usa `luaotfload`as funções de composição de texto do luaotfload implementadas puramente em Lua. * `Renderer = Harfbuzz`: este “modo” define/carrega a fonte para uso com o motor de composição de texto HarfBuzz. `luaotfload` usa a API do LuaHBTeX para chamar funções no HarfBuzz. Para mais informações, consulte [`fontspec` documentação](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf). ## Motores TeX, HarfBuzz e emoji coloridos Embora XeTeX e LuaHBTeX integrem ambos o HarfBuzz, fornecem níveis diferentes de suporte para algumas das funcionalidades mais avançadas do HarfBuzz—nomeadamente o carregamento e a utilização de fontes de cor OpenType. ### XeTeX e fontes de cor OpenType Como foi referido, há duas categorias de fontes de cor OpenType com base no formato de dados usado para armazenar os glifos da fonte: baseadas em vetores e baseadas em raster. #### XeTeX e fontes de cor OpenType baseadas em raster O XeTeX não consegue carregar fontes coloridas OpenType baseadas em raster — como as da Google [Noto Color Emoji](https://www.google.com/get/noto/help/emoji/) incluída no TeX Live 2020. Por exemplo, se tentar carregar Noto Color Emoji (NotoColorEmoji.ttf), o XeLaTeX falhará com um erro potencialmente enganador a afirmar que Noto Color Emoji “não pode ser encontrada”. O seguinte código LaTeX, composto com XeLaTeX, *não funciona*: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{NotoColorEmoji.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} \smiley \end{document} ``` [Abra este código XeLaTeX no Overleaf (ele ***não*** funciona).](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) Falha com o erro: ``` ! Erro do pacote fontspec: A fonte "NotoColorEmoji" não pode ser encontrada. ``` Da mesma forma, um exemplo simples de Plain TeX processado por XeTeX também falha ```latex \font\emojifont="[NotoColorEmoji.ttf]" at 12pt \emojifont \char"1F600 \bye ``` [Abra este exemplo de Plain TeX (XeTeX) no Overleaf (ele ***não*** funciona).](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) O exemplo de Plain TeX apresenta uma mensagem de erro semelhante, mas diferente: ``` ! Fonte \emojifont=[NotoColorEmoji.ttf] at 12.0pt não carregável: ficheiro Metric (TFM) e ou fonte instalada não encontrada. l.1 \font\emojifont="[NotoColorEmoji.ttf]" at 12pt Não consegui ler os dados de tamanho desta fonte, por isso vou ignorar a especificação da fonte. [Os magos podem corrigir ficheiros TFM usando TFtoPL/PLtoTF.] Talvez queira tentar inserir uma especificação de fonte diferente; por exemplo, digite `I\font='. ``` **Exemplo simples em LuaHBTeX** Para comparação, aqui está um exemplo mínimo de Plain TeX compilado com LuaHBTeX ```latex \input luaotfload.sty \font\emojifont=NotoColorEmoji.ttf:mode=harf at 12pt \emojifont \Uchar"1F600 \bye ``` [Abra este exemplo de Plain TeX (LuaHBTeX) no Overleaf (ele compila com sucesso).](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) #### A verdadeira causa da falha do XeTeX As mensagens de erro fornecidas pelo XeTeX obscurecem parcialmente a verdadeira causa do problema: as fontes coloridas OpenType, em particular as variantes baseadas em raster, são *contém* suportadas pelo XeTeX. Na realidade, o XeTeX (Kpathsea) consegue *encontrar* a fonte Noto Color Emoji, mas o XeTeX não consegue carregá-la totalmente *carregar* essa fonte e não consegue inicializar as tabelas internas de dados da fonte necessárias para usar essa fonte na composição tipográfica. Internamente, o XeTeX *começa* analisa o processo de carregamento da fonte e testa-a quanto à “escalabilidade” (usando a “definição” de “escalabilidade” do FreeType), mas esse teste falha, e o XeTeX emite uma mensagem de erro padrão do motor TeX, que pode ser considerada enganadora. **Nota técnica** O processamento de NotoColorEmoji.ttf pelo XeTeX foi investigado compilando uma versão de depuração do executável XeTeX. O IDE Eclipse foi usado para definir um ponto de interrupção na função do XeTeX `creatFontFromFile(filename, index, pointsize)`, e depois avançar pelo código para observar o processamento subsequente. #### XeTeX e fontes coloridas OpenType baseadas em vetores O XeTeX consegue *carregar* fontes coloridas OpenType baseadas em vetores, mas não produzirá emoji colorido no PDF resultante — se o XeTeX produzir algum. Ao contrário do LuaTeX, LuaHBTeX e pdfTeX, o XeTeX não *diretamente* produz documentos compostos em formato PDF. Em vez disso, o XeTeX produz um intermédio `.xdv` (e**x**stend **dv**i) formato de ficheiro que é convertido em PDF por uma utilidade chamada `xdvipdfmx`. Na altura em que este texto foi escrito, `xdvipdfmx` não consegue incorporar no PDF os dados apropriados do glifo emoji colorido, por isso, no melhor dos casos, verá emoji monocromático — o resultado “de recurso” — no PDF, ou talvez nada de todo, dependendo da fonte usada. Aqui está um exemplo XeLaTeX que usa a fonte colorida OpenType [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr), disponível no TeX Live. TwemojiMozilla.ttf usa o formato vetorial COLR/CPAL da Microsoft para armazenar glifos coloridos e é incluída no TeX Live 2020. Neste exemplo, o XeTeX consegue carregar a fonte, gerar um `.xdv` e um ficheiro PDF, mas o glifo emoji não está presente no PDF composto: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} Aqui está um smiley: \smiley \end{document} ``` [Abra este código XeLaTeX no Overleaf (ele NÃO funciona).](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) Em contraste, o código acima funciona com LuaLaTeX se definir `\emojifont` usando o `fontspec` configuração `[Renderer=HarfBuzz]`: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf}[Renderer=HarfBuzz] \newcommand{\smiley}{{\emojifont\char"1F600}} Aqui está um smiley: \smiley \end{document} ``` [Abra este código LuaLaTeX no Overleaf (ele funciona).](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 fontes coloridas OpenType Através do seu mecanismo integrado de composição HarfBuzz e da `luaoftload` biblioteca, o LuaHBTeX fornece suporte para todas as quatro variedades de fonte colorida OpenType. Os utilizadores do LuaLaTeX podem tirar pleno partido do processamento baseado em Unicode de texto contendo caracteres emoji ou simplesmente embelezar os seus documentos com texto altamente colorido usando fontes coloridas OpenType. Como foi observado anteriormente, as quatro variantes de fonte colorida OpenType podem ser classificadas em dois grupos: * as que contêm glifos em formatos de imagem raster, como PNG; * outras que usam formatos vetoriais de SVG ou o mecanismo COLR/CPAL da Microsoft. Os formatos de glifo baseados em vetores têm a vantagem da escalabilidade: produzem gráficos de glifos nítidos em qualquer tamanho de ponto. **Usar fontes coloridas COLR/CPAL da Microsoft com LuaHBTeX** Se quiser usar um formato vetorial para as suas fontes emoji coloridas OpenType, dê uma vista de olhos à fonte [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr?lang=en), que se baseia no formato COLR/CPAL da Microsoft. TwemojiMozilla.ttf está incluída no TeX Live, mas pode obter a versão mais recente a partir da sua [repositório GitHub](https://github.com/mozilla/twemoji-colr/releases) e carregá-la no seu projeto Overleaf. Aqui está um pequeno, `fontspec`-baseado, exemplo usando `Renderer=Harfbuzz`, que compõe um pato emoji grande (vetorial): ```latex \documentclass{article} \usepackage{fontspec} \title{Demonstração do pato} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{TwemojiMozilla.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Abra este exemplo LuaLaTeX para compor um pato vetorial.](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) Aqui está o pato (vetorial) produzido pelo exemplo acima: ![](/files/2d6f6f765c675e839e545eb664def93aa6cacabe) #### Utilização de tipos de letra OpenType coloridos baseados em SVG com LuaHBTeX Na altura desta atualização do artigo (julho de 2023), há pouca documentação formal sobre usar fontes coloridas OpenType com sabor SVG com LuaLaTeX. Alguns [comentários feitos em discussões online](https://github.com/latex3/luaotfload/issues/96) sugerem usar `fontspec`’s `RawFeature`, como mostrado no pseudocódigo abaixo. Substitua `*nome do seu ficheiro de fonte SVG aqui*` pelo nome de um ficheiro de fonte baseado em SVG que esteja acessível ao seu código LaTeX: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emoji[RawFeature={+svg},SizeFeatures={Size=20}]{nome do seu ficheiro de fonte SVG aqui} \emoji O seu emoji aqui... \end{document} ``` Se omitir `fontspec` e carregar `luaotfload` diretamente, talvez precise de declarar e especificar uma fonte da seguinte forma — as nossas experiências indicam que precisa de omitir a `mode=harf` opção para que isto funcione: ```latex \font\emoji=[nome do seu ficheiro de fonte SVG aqui]:+svg; ``` **Algumas notas de cautela** Os leitores interessados em usar fontes coloridas OpenType com sabor SVG devem notar: * fontes OpenType com sabor SVG que contenham um grande número de glifos podem ser [computacionalmente dispendiosas para o LuaLaTeX](#processing-svg-glyph-data) processar, podendo resultar em [timeouts do Overleaf](/latex/overleaf-learn-latex-pt/base-de-conhecimento/038-fixing-and-preventing-compile-timeouts.md). * o suporte do LuaLaTeX para estas fontes pode ser [considerado experimental](https://github.com/latex3/luaotfload/issues/96#issuecomment-530317399): os resultados podem variar consoante a versão do TeX Live usada pelo seu projeto; por conseguinte, é aconselhável experimentar e proceder com cautela. **Processamento de dados SVG do glifo** O SVG permite aos designers produzir desenhos complexos e coloridos que representam os glifos de uma fonte — sujeitos a algumas restrições do SVG [documentadas na especificação OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/svg). No entanto, os motores TeX, incluindo o LuaHBTeX, não podem importar diretamente (usar) ficheiros ou dados SVG — como os dados SVG usados para descrever as formas dos glifos dentro das fontes coloridas OpenType com sabor SVG. Os dados SVG de um glifo têm de ser convertidos para formato PDF porque o LuaHBTeX pode usá-lo para compor o glifo e produzir o documento PDF final. Essa conversão de SVG para PDF é tratada por código Lua dentro de `luaoftload`: os dados SVG de cada glifo são extraídos do ficheiro da fonte, guardados num temporário `.svg` e convertidos em PDF usando o Inkscape através da sua linha de comandos. Extrair os dados SVG e convertê-los em PDF implica alguma sobrecarga de processamento, resultando em tempos de compilação de documento potencialmente longos — especialmente em documentos que usam grandes fontes SVG contendo milhares de glifos emoji. #### Fontes coloridas OpenType baseadas em raster **Usar o formato de fonte colorida OpenType CBDT/CBLC da Google com LuaHBTeX** [Noto Color Emoji](https://fonts.google.com/noto/specimen/Noto+Color+Emoji) é uma fonte colorida OpenType incluída com o TeX Live, o que facilita a sua utilização num projeto Overleaf. Como o Noto Color Emoji usa gráficos em formato PNG para representar glifos emoji, podemos usá-la para compor um pato emoji grande (raster) — como demonstrado pelo exemplo seguinte. Note novamente que a `fontspec` declaração da fonte (`\emojifont`) usa `Renderer=Harfbuzz`. ```latex \documentclass{article} \usepackage{fontspec} \title{Demonstração do pato} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{NotoColorEmoji.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Abra este exemplo LuaLaTeX para compor um pato 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) Aqui está o pato raster produzido pelo exemplo acima: ![Um emoji de pato raster composto com LaTeX](/files/2a8e646a7b1bc5d784e69ec288a0b001c5ecd16b) Se tentar usar `NotoColorEmoji.ttf` mas omitir `[Renderer=Harfbuzz]` do `fontspec` declaração, o LuaHBTeX falhará e emitirá uma mensagem de erro quando tentar escrever o ficheiro PDF: ```latex ! erro: (ficheiro /usr/local/texlive/2020/texmf-dist/fonts/truetype/google/noto-em oji/NotoColorEmoji.ttf) (ttf): tabela loca não encontrada ``` A razão para este erro na [tabela loca](https://docs.microsoft.com/en-us/typography/opentype/spec/loca) é [explicada no GitHub](https://github.com/latex3/luaotfload/issues/98#issuecomment-531610153). **Usar o formato de fonte colorida OpenType sbix da Apple com LuaHBTeX** Testes offline demonstram que o LuaHBTeX suporta a `sbix` variante de fonte colorida OpenType, mas, à data da redação deste artigo, não conseguimos localizar uma fonte emoji colorida `sbix`da variante adequada e com licença apropriada para demonstrar a composição de um pato. Por favor [contacte-nos](https://www.overleaf.com/contact) se souber de uma, e atualizaremos este artigo rapidamente para a usar. ## Introdução à API HarfBuzz do LuaHBTeX ![Db.gif](/files/58f345e3ec1fb5d65660af2714d7e5482455e871) ![Db.gif](/files/58f345e3ec1fb5d65660af2714d7e5482455e871) A composição tipográfica, particularmente para linguagens de escrita complexas, e até para emoji, é uma tarefa inerentemente difícil, por isso, sem surpresa, o HarfBuzz é uma biblioteca sofisticada que pode ser difícil de usar — a menos que já esteja familiarizado com operações de composição de texto. Nesta secção final, analisamos a integração do HarfBuzz no LuaHBTeX e como acedê-la através de código Lua dentro de `\directlua`. O nosso exemplo usa código bastante básico para demonstrar a API HarfBuzz do LuaHBTeX. É algo artificial, não tem qualidade de nível de produção, nem é muito prático, porque o seu único objetivo é introduzir algumas ideias centrais. Dividimos o código Lua em dois `\directlua` blocos: o primeiro carrega a `luaharfbuzz` biblioteca e cria algumas variáveis globais que usaremos no nosso segundo `\directlua` bloco, onde definimos uma macro chamada `\codestoemoji`. Parece apropriado replicar o uso de Knuth dos sinais duplos de perigo no bordo (imagem cortesia de [este site](http://www.truetex.com/db.htm)) porque o conteúdo é algo de baixo nível e “espreita por baixo do capô” — embora esperemos que possa ser do interesse do leitor mais intrépido. A integração do HarfBuzz no LuaHBTeX é derivada do [projeto luaharfbuzz no GitHub](https://github.com/ufyTeX/luaharfbuzz/wiki#projects-using-luaharfbuzz) onde pode encontrar uma [introdução ao projeto](https://github.com/ufyTeX/luaharfbuzz/wiki) juntamente com uma [listagem da API luaharfbuzz](http://ufytex.github.io/luaharfbuzz/). ### Primeiros passos: carregar a biblioteca luaharfbuzz e encontrar uma fonte Para usar a API HarfBuzz do LuaHBTeX, primeiro precisamos de carregar a biblioteca (módulo) chamada `luaharfbuzz`, integrada no LuaHBTeX, e guardar a tabela devolvida numa variável (global) a que chamaremos `hblib`: ```latex hblib=require("luaharfbuzz") ``` Em seguida, precisamos de localizar uma fonte emoji colorida OpenType adequada: usaremos o Noto Color Emoji — note que estamos a ser muito preguiçosos e não estamos a fazer qualquer verificação de erros caso não a encontremos! Para a encontrar, usaremos a `kpse` (Kpathsea), que também faz parte do LuaTeX/LuaHBTeX: ```latex pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") ``` Agora que temos acesso à biblioteca HarfBuzz, através da nossa variável `hblib`, e o caminho para uma fonte adequada (`pathtofontfile`), podemos começar a usá-la `hblib`. Para começar, vamos criar uma fonte HarfBuzz e uma face HarfBuzz para usar no segundo `\directlua` bloco de código onde definimos a nossa macro. ```latex %Criar face HarfBuzz e fonte HarfBuzz a partir de Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) ``` #### Fonte HarfBuzz e face HarfBuzz: o que são? Um [Objeto face HarfBuzz](https://harfbuzz.github.io/fonts-and-faces.html) representa um tipo de letra carregado a partir de um ficheiro de fonte, mas sem parâmetros específicos (como o tamanho) definidos. Um [Objeto fonte HarfBuzz](https://harfbuzz.github.io/fonts-and-faces.html) representa uma *instância específica* de uma face HarfBuzz; consequentemente, diferentes objetos de fonte HarfBuzz podem ser derivados de uma única face HarfBuzz: cada fonte HarfBuzz pode ter as suas propriedades, como o tamanho, definidas com valores diferentes. Uma face HarfBuzz é um nível de abstração superior a uma fonte HarfBuzz. ### Usar glifos de fonte para criar ficheiros PNG A parte final do nosso primeiro `\directlua` bloco é uma função chamada `writePNGglyph(hbfontobject, glyphID)` que usamos para demonstrar que algumas fontes coloridas OpenType, como Noto Color Emoji, usam gráficos PNG para representar os glifos emoji que contêm. Esta função usa a API HarfBuzz do LuaHBTeX para extrair dados PNG dos glifos e escrever esses dados num `.png` ficheiro com o nome `Graphics.png`. O nome desse `.png` ficheiro é devolvido para uso por `\includegraphics` para incorporar imagens PNG de glifos no nosso PDF composto. Com o `writePNGglyph(hbfontobject, glyphID)` em vigor, o nosso primeiro `\directlua` bloco de código fica assim: ```latex \directlua{ % Carregar a biblioteca luaharfbuzz a partir do LuaHBTeX hblib=require("luaharfbuzz") % Localizar a fonte Noto Color Emoji no servidor do Overleaf pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Criar face HarfBuzz e fonte HarfBuzz a partir de Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Esta função aceita uma fonte e um ID de glifo: % extrai os dados PNG dos glifos e escreve % num ficheiro .png function writePNGglyph(hbfontobject, glyphID) % Obter dados PNG do glifo local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Construir um nome de ficheiro para o nosso ficheiro .png local fname="Glyph"..glyphID..".png" % Escrever o ficheiro .png e devolver o nome do ficheiro local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Devolver o nome do ficheiro para \includegraphics usar return fname end } ``` ### Segundo bloco \directlua: criar a macro \codestoemoji O objetivo é definir uma macro `\codestoemoji` que podemos chamar com um trecho de texto contendo códigos de caracteres emoji que queremos que o HarfBuzz componha. Especificamente, vamos usar `\Uchar` para representar cada carácter emoji; por exemplo: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` Há muita coisa a acontecer na definição de `\codestoemoji` que explicaremos abaixo, mas a definição tem este aspeto: ```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() % A tabela de glifos, hbglyphs, é indexada a partir de 1 local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduzir o tamanho das nossas imagens PNG importadas local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} ``` #### Compreender a definição da macro \codestoemoji O `\codestoemoji` macro é maioritariamente código Lua contido dentro de `\directlua`, por isso, se quiser saber mais sobre *como* `\directlua` funciona, consulte o artigo do Overleaf [Compreender `\directlua`](/latex/overleaf-learn-latex-pt/artigos-aprofundados/09-an-introduction-to-luatex-part-2-understanding-directlua.md). Explica como o LuaTeX e o LuaHBTeX processam `\directlua` quando comandos TeX/LaTeX são incluídos no código Lua e, em particular, a necessidade de usar `\noexpand` e `\unexpanded`. **Lidar com o parâmetro da macro: "#1"** A macro começa com estas três linhas: ```latex local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) ``` que executam as seguintes tarefas: * `local str="#1"`: isto cria uma string Lua a partir da entrada passada pela macro; * `local hbbuffer = hblib.Buffer.new()`: isto usa a API HarfBuzz para criar um buffer para conter o texto que queremos que o HarfBuzz componha; * `hbbuffer:add_utf8(str)`: isto adiciona uma string em formato UTF-8, criada a partir da entrada da nossa macro, ao buffer HarfBuzz. A primeira linha de código ```latex local str="#1" ``` parece bastante simples, mas o seu funcionamento envolve bastante complexidade, o que vale a pena explorar um pouco mais em detalhe. Se considerarmos a terceira linha de código ```latex hbbuffer:add_utf8(str) ``` vemos que usa a nossa `variável str` para fornecer ao buffer HarfBuzz uma string Unicode formatada em UTF-8. Para isso funcionar, a variável `variável str` tem ela própria de conter texto Unicode formatado em UTF-8; por isso, surge a questão: *como* o LuaHBTeX “converteu” o argumento da macro `"#1"`, contendo `\Uchar` comandos, para a variável de string Lua `variável str` contendo texto UTF-8 para o HarfBuzz? Se olharmos para o uso pretendido da `\codestoemoji` macro: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` a entrada, como `\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065...`, não se parece nada com uma sequência de caracteres emoji codificados em UTF-8. Além disso, o HarfBuzz não sabe nada sobre comandos TeX. De alguma forma, a entrada TeX bruta composta por `\Uchar` comandos é transformada em caracteres Unicode codificados em UTF-8 que o HarfBuzz pode usar, mas *como*? a resposta está no comportamento do `\Uchar` comando: tentar chamar `\codestoemoji` usando `\char` em vez de `\Uchar` falhará, mas *porquê*? **Expansão de \Uchar em \directlua** Quando a `\codestoemoji` macro é chamada, o `\directlua` comando, armazenado dentro da definição da macro, tem de preparar código Lua para enviar para o interpretador Lua incorporado do LuaHBTeX. Parte desse processo de preparação do código é a expansão de quaisquer comandos TeX/LaTeX presentes no código Lua original na definição da macro, juntamente com a expansão de quaisquer argumentos da macro fornecidos pelo utilizador. Esse processo de expansão produz uma lista de tokens que é subsequentemente convertida de volta para texto, gerando o código Lua a ser passado para o interpretador Lua. Por conveniência, reproduzimos um diagrama do artigo do Overleaf [Compreender `\directlua`](/latex/overleaf-learn-latex-pt/artigos-aprofundados/09-an-introduction-to-luatex-part-2-understanding-directlua.md): ![A mecânica de \directlua](/files/f9c37e521fa4c7ac68a73ad490d795d5450a7beb) A macro `\codestoemoji` destina-se a ser chamada usando `\Uchar` comandos e, [como observado anteriormente no artigo](#the-key-difference-expansion), `\Uchar` é um comando expansível cuja expansão gera um token de carácter. Dentro das atividades de processamento de `\directlua`, o LuaHBTeX expande cada `\Uchar` comando em que *remove* cada `\Uchar` da entrada e *substitui* o substitui pelo valor de expansão correspondente: um token de carácter representando o ``. Na fase final do processamento, a lista inicial de tokens gerada por `\directlua` é convertida *de volta para texto* para se tornar o código Lua destinado ao interpretador Lua (ver diagrama acima). Todos os tokens de carácter produzidos pela expansão de `\Uchar` também são *convertidos de volta para texto*: essa conversão de tokens de carácter para texto gera as representações UTF-8 dos originais `` valores. No nosso exemplo, quando o código Lua é gerado e fica pronto para o interpretador Lua, a entrada da macro para "#1" foi convertida numa sequência de texto UTF-8: a `variável str` variável é agora uma string de texto UTF-8 que pode ser adicionada em segurança ao buffer HarfBuzz. **Porque é que \char não funciona?** A resposta direta é porque `\char` é *contém* um comando expansível. Ao contrário `\Uchar` dos comandos, `\char` comandos *não são removidos* da entrada durante `\directlua`o processamento inicial para gerar uma lista de tokens, eles “passam por” para serem incorporados na lista de tokens que está a ser construída por `\directlua`. Por exemplo, se o argumento para `\codestoemoji` continha `\char"1F3F4` o LuaHBTeX converteria isso numa sequência de tokens e guardá-los-ia como parte da lista total de tokens a ser gerada. Na fase seguinte do processamento, ao converter os tokens de volta em texto, o código Lua resultante conteria a *string literal* `\char"1F3F4` no texto usado para definir a nossa variável `variável str`. Quando o conteúdo de `variável str` é adicionado ao buffer do HarfBuzz, ele não conterá uma sequência codificada em UTF-8 que represente o carácter emoji "1F3F4, conterá a string literal `\char"1F3F4`, que o HarfBuzz tentará representar e, para os nossos propósitos, não produziria um glifo emoji. De resto, a string `\char"1F3F4` também geraria erros de sintaxe Lua, a menos que fosse criada como uma “string de colchetes longos”—veja [O que são sequências de escape Lua](/latex/overleaf-learn-latex-pt/artigos-aprofundados/09-an-introduction-to-luatex-part-2-understanding-directlua.md#what-are-e2809clua-escape-sequencese2809d3f) para contexto sobre esse problema. Se tentarmos usar `\codestoemoji` por um `\char` o comando, assim: ```latex \codestoemoji{\char"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` o LuaHBTeX irá falhar e relatar um erro de sintaxe algo como isto: ```latex [\directlua]:1: sequência de escape inválida perto de '"\c'. \codestoemoji ...ing \includegraphics }.}]]) end } l.75 ...r"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} O interpretador lua encontrou um problema, por isso o restante deste bloco lua será ignorado. ``` #### Chamando a função de representação HarfBuzz **Definir parâmetros do buffer** O HarfBuzz por vezes requer informação adicional sobre o texto que lhe é pedido para representar. Pode fornecer essa informação configurando o seu `` usando *métodos do buffer*, como: * `:set_direction(*direção HarfBuzz*)`; * `:set_language(*língua HarfBuzz*)`; * `:set_script(*escrita HarfBuzz*)`. Por exemplo, precisamos de informar o HarfBuzz de que a direção do nosso texto emoji será da esquerda para a direita. Para isso, usamos o método `set_direction()` na nossa `` (chamada `hbbuffer`) escrevendo: ```latex hbbuffer:set_direction(hblib.Direction.new("ltr")) ``` onde `hblib.Direction.new("ltr")` cria um “objeto de direção” adequado para ser passado ao mecanismo HarfBuzz via Lua. **Executar a representação** Depois de o buffer estar adequadamente inicializado, podemos pedir ao HarfBuzz que faça a representação real através da função `shape_full()`. No nosso exemplo, escrevemos: ```latex local res = hblib.shape_full(hbfont, hbbuffer, {},{}) ``` O 3.º e 4.º parâmetros da `shape_full()` função precisam de ser tabelas Lua — usamos tabelas vazias “`{}`” para ambos os parâmetros. A forma geral de `shape_full()` é: ```latex shape_full(fonte Harfbuzz, buffer Harfbuzz, {características da fonte}, {"shaper"} ``` * **`{"shaper"}`**: Normalmente não precisa de ser definido, mas as opções são `{"ot"}` ou `{"graphite2"}`. Mais informação sobre o conceito de um “shaper” pode ser encontrada na [documentação do HarfBuzz](https://harfbuzz.github.io/shaping-and-shape-plans.html)—note que isto documenta a API C de baixo nível, não a `luaharfbuzz` ligação (implementação) baseada em Lua. * **`{font features}`**: Esta é uma tabela que lista as [características OpenType](https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist)—suportadas pela fonte— que quer que o HarfBuzz aplique durante a representação. Qualquer funcionalidade de fonte que queira usar precisa de ser criada usando uma `luaharfbuzz` função da biblioteca ```latex library_instance.Feature.new(feature_string) ``` onde * `library_instance` é a sua `luaharfbuzz` variável de instância da biblioteca (`hblib` no nosso exemplo); * `feature_string` usa uma [sintaxe para definir funcionalidades](https://github.com/ufytex/luaharfbuzz/wiki/Feature-Strings). Exemplos disso são `+smcp` para ativar capitais pequenas ou `-kern` para desativar o kerning. Por exemplo: ```latex local dosmcp = hblib.Feature.new("+smcp") local nokern = hblib.Feature.new("-kern") % Use as suas funcionalidades de fonte assim local res = hblib.shape_full(hbfont, hbbuffer, {dosmcp,nokern},{}) ``` #### Aceder ao resultado: obter os glifos E, por fim, se a operação de representação for bem-sucedida, os glifos representados são devolvidos na variável do buffer `hbbuffer` que criámos anteriormente no código. Acedemos aos glifos através do método do buffer `get_glyphs()` e usamos um ciclo para obter cada glifo individual. Note que a tabela Lua que contém os glifos, `hbglyphs` no nosso exemplo, está indexada a partir de 1, não de 0. O *identificador do glifo* (confusamente chamado `codepoint`), e a fonte HarfBuzz (`hbfont`), é passada para a `writePNGglyph()` função que cria um ficheiro PNG usando a representação em imagem raster da fonte desse glifo. `writePNGglyph()` escreve um ficheiro PNG e devolve o nome do ficheiro PNG, que é usado para importar o ficheiro PNG (dimensionado) para o nosso documento LaTeX via `\includegraphics[scale=0.75]{}`. Note como podemos usar `\includegraphics` diretamente dentro do código Lua. ```latex if (res) then local hbglyphs=hbbuffer:get_glyphs() % A tabela de glifos, hbglyphs, é indexada a partir de 1 local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduzir o tamanho das nossas imagens PNG importadas local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end ``` ### O código completo que pode Abrir no Overleaf ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \directlua{ % Carregar a biblioteca luaharfbuzz a partir do LuaHBTeX hblib=require("luaharfbuzz") % Localize o tipo de letra Noto Color Emoji no servidor do Overleaf pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Criar face HarfBuzz e fonte HarfBuzz a partir de Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Esta função aceita uma fonte e um ID de glifo: % extrai os dados PNG dos glifos e escreve % num ficheiro .png function writePNGglyph(hbfontobject, glyphID) % Obter dados PNG do glifo local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Construir um nome de ficheiro para o nosso ficheiro .png local fname="Glyph"..glyphID..".png" % Escrever o ficheiro .png e devolver o nome do ficheiro local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Devolver o nome do ficheiro para \includegraphics usar 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() % A tabela de glifos, hbglyphs, é indexada a partir de 1. local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduzir o tamanho das nossas imagens PNG importadas local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} Um pato: \codestoemoji{\Uchar"1F986} Uma bandeira: \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} \end{document} ``` [Abra este exemplo da API luaharfbuzz no Overleaf.](/latex/overleaf-learn-latex-pt/artigos-aprofundados/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md) Este exemplo produz a seguinte saída: ![Harfbuzzexample.png](/files/9d76b2b5c92ff9c123d533d4485d43be72c66595) ## Secção bónus: Diversão com matemática emoji Para terminar numa nota leve, um membro da equipa do Overleaf usou o [`emoji` pacote LaTeX](https://ctan.org/pkg/emoji?lang=en) para criar um exemplo divertido: ```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} ``` [Abra este exemplo divertido no 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) Este exemplo produz a seguinte saída: ![Emojimath2.png](/files/f1d76e98255e4a15df19fd423f3033739e153055) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/overleaf-learn-latex-pt/artigos-aprofundados/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.