> 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/sv/fordjupade-artiklar/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md). # En översikt över tekniker som stöder användningen av färgemoji-typsnitt i LaTeX ## Introduktion Den här artikeln ger en översikt över olika [bakgrundsämnen](#which-topics-do-we-cover) som rör användning av OpenType-färgfonter för att sätta färgemoji i LaTeX. Vi har försökt tillhandahålla ett brett material som passar ett brett spektrum av intressen och kunskapsnivåer. För att hålla artikeln hanterbar utelämnar vår behandling av vissa ämnen en hel del tekniska detaljer, men vi hoppas att det finns tillräckligt med material för att vägleda din utforskning av att sätta färgemoji i LaTeX. **Uppdatering (juli 2023)**: Den här artikeln publicerades första gången i augusti 2021 och reviderades i juli 2023 för att uppdatera avsnittet om [Att använda SVG-baserade OpenType-färgfonter med LuaHBTeX](#using-svg-based-opentype-color-fonts-with-luahbtex). ### Vilka ämnen behandlar vi? Den här artikeln behandlar följande allmänna ämnen: * Unicode: standarden som kodar emoji som tecken och fastställer deras förväntade beteende i textbearbetnings- och sättningsprogram. * OpenType-färgfonter: specialiserade teckensnitt som ger färgstarka representationer av emoji-tecken som visas i ditt LaTeX-dokument. * Textformning: en introduktion till en nyckelkomponent i sättning av språk med komplexa skriftsystem och emoji. * HarfBuzz: komponenten i LuaHBTeX som möjliggör avancerad flerspråkig sättning och användning av OpenType-färgfonter för att sätta emoji i LaTeX. * Olika TeX-motorer: att utforska deras stöd för OpenType-färgfonter och välja vilken TeX-motor som ska användas. * LuaHBTeX:s HarfBuzz-API: en introduktion till ”magin” bakom [textformningen](#the-concept-of-text-shaping) i LuaHBTeX. ### Tre sätt att sätta färgemoji Färgemoji kan sättas med LaTeX med tre huvudmetoder: 1. Att använda vanliga LaTeX-grafikverktyg som TikZ, MetaPost eller Asymptote för att rita emojin. 2. Att infoga emoji med hjälp av förberedda emoji-grafiker som lagras i externa filer. 3. Att behandla emoji som Unicode-kodad text och använda [textformningen](#the-concept-of-text-shaping) med [OpenType-färgfonter](#opentype-color-fonts) för att sätta dem i text. De praktiska alternativen för att inkludera färgemoji i ditt LaTeX-dokument beror på vilken TeX-motor som används för att kompilera dokumentet: dvs. om du använder: * pdfLaTeX: pdfTeX-motor + LaTeX; * XeLaTeX: XeTeX-motor + LaTeX; * LuaLaTeX: LuaHBTeX-motor (från och med TeX Live 2020) + LaTeX. Alla dessa tre TeX-motorer kan använda LaTeX-verktyg eller paket för att rita emoji eller använda `\includegraphics{...}` för att infoga emoji som lagras i externa grafikfiler. Att rita eller importera grafik är idealiska tekniker för att sätta emoji när du behöver en lösning som inte beror på den TeX-motor som används för att kompilera LaTeX-dokumentet. Om ditt arbetsflöde däremot ger flexibilitet att välja en viss TeX-motor, och du föredrar att använda OpenType-färgfonter och Unicode-baserad textbearbetning, är den nyaste versionen av LuaTeX, kallad LuaHBTeX, det du behöver. Från och med TeX Live 2020 används LuaHBTeX för att kompilera LaTeX-dokument baserade på formatet LuaLaTeX. ## Bakgrund om Unicode och emoji-tecken ### Teckenkodningar Datorer lagrar, överför och bearbetar text med hjälp av en följd av numeriska (heltal) värden som representerar textens ingående *tecken*. Tillförlitlig textbearbetning kräver att producenter och konsumenter av text är överens om vilka heltalsvärden som ska användas för att representera enskilda tecken inom textströmmen. Med andra ord, vad är textens *tecknet* *kodning?* En kodning är den uppsättning överenskomna heltalsvärden som tilldelas för att representera en viss uppsättning tecken: varje tecken representeras av ett heltalsvärde inom den kodning som används. ### Sedan kom Unicode Historiskt sett, under eran med 8-bitars text, användes många olika teckenkodningar, vilket alltid väckte spöket av *kodningsavvikelser*: att producenter och konsumenter av text felaktigt antar olika kodningar, vilket leder till fel i textbearbetningen. Alla som har arbetat med TeX/LaTeX i några år har sannolikt stött på kodningsavvikelser mellan inmatningstexten och de teckensnitt som används för att sätta ett dokument. Om dokumentets teckensnitt är konfigurerade att använda en annan kodning än textens, leder det sannolikt till saknade eller felaktiga tecken i den satta PDF-filen. Dessa historiska kodningsproblem kan lösas med hjälp av en internationell standard som kodar alla världens tecken: Unicode. Unicode-standarden är inte statisk utan uppdateras regelbundet för att inkludera ytterligare tecken och skriftsystem inom sitt kodningsschema. Det finns en [formell granskningsprocess för att föreslå nya tecken](http://www.unicode.org/pending/proposals.html) med ett särskilt [förfarande för nya emoji-tecken](https://www.unicode.org/emoji/proposals.html). ### Hur många Unicode-tecken? Unicode kodar ett teoretiskt maximum på 1 114 112 tecken. Var och en av de 1 114 112 heltalsvärdena kallas en *kodpunkt*: heltalsvärdet som tilldelas för att identifiera varje tecken. Av olika tekniska skäl kan dock endast [1 112 064 kodpunkter](https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology) tilldelas faktiska tecken: 2048 kodpunkter kan inte tilldelas och är förbjudna att använda inom Unicode-kompatibel text. Vid tidpunkten för skrivandet (den första versionen av denna artikel) hade version 13 av Unicode-standarden tilldelat totalt 143 859 kodpunkter till faktiska tecken, inklusive [3304 tecken som nu kodas som emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (se sida 2 i det dokumentet). Tillväxten i antalet tecken som kodas av Unicode dokumenteras väl i artikeln [Hur många Unicode-tecken finns det?](https://www.babelstone.co.uk/Unicode/HowMany.html) och i en [Wikipedia-artikel](https://en.wikipedia.org/wiki/Unicode#Versions). ### Unicode-plan Hela samlingen av 1 114 112 Unicode-kodpunkter är grupperad i 17 så kallade plan: plan 0 till plan 16, där var och en innehåller 65 536 kodpunktsvärden, vilket ger totalt $$17\times2^{16} = 1,114,112$$ tecken. Plan 0, kallad [Grundläggande flerspråkiga planet](https://en.wikipedia.org/wiki/Plane_\(Unicode\)#Basic_Multilingual_Plane), kodar de vanligast använda tecknen. Plan 1–16 kallas [kompletterande plan](http://unicode.org/glossary/#supplementary_planes). ### Emojins framväxt Nya tecken uppstår genom förändrade sätt att kommunicera mellan människor, och mobiltelefontekniken gav upphov till en sådan uppsättning tecken: emoji, som utvecklades i Japan under slutet av 1990-talet. Det är inte förvånande att [Unicode FAQ om emoji](https://unicode.org/faq/emoji_dingbats.html) noterar > ”Ordet emoji kommer från japanskans [絵](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E7%B5%B5) (e ≅ bild) + [文字](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E6%96%87) (moji ≅ skrivet tecken).” Läsare som är intresserade av emojins bakgrund och historiska utveckling kan ha nytta av denna [Unicode-introduktion](https://unicode.org/reports/tr51/#Introduction) eller artikeln [Jag instämmer i den emojin: standarderna, strukturerna och emojins sociala produktion](https://firstmonday.org/ojs/index.php/fm/article/view/9381). Det var inte förrän 2010, med utgivningen av [version 6.0 av Unicode-standarden](https://www.unicode.org/versions/Unicode6.0.0/), som många emoji formellt erkändes som *tecken* i sin egen rätt. Unicode 13.0 kodade [3304 tecken som emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (se sida 2 i det dokumentet), och Unicode 13.1 listar [listar 3521 emoji](https://unicode.org/emoji/charts/emoji-counts.html). ### Emoji lever på en högre nivå Unicode tilldelade många emoji-tecken till kodpunkter utanför den Grundläggande flerspråkiga planet (BMP), kodade [i plan 1](https://en.wikibooks.org/wiki/Unicode/Character_reference/1F000-1FFFF) med kodpunkter i intervallet 1F000–1FFFF—vilket har en viktig konsekvens för alla som vill *kopiera och klistra in* emoji-tecken i Overleafs redigerare (Code Editor eller Visual Editor). Overleafs textredigerare kan bara hantera tecken inom den Grundläggande flerspråkiga planet, även om vi hoppas att framtida uppgraderingar kommer att införa stöd för icke-BMP-tecken. Observera att denna begränsning endast påverkar icke-BMP-tecken i text som klistras in i filer som ska redigeras via Overleafs redigerare. Det finns andra sätt att komma åt emoji-tecken: * Genom att använda de primitiva kommandona `\char"` eller `\Uchar"` (se [detta avsnitt](#optional-detail-luatexluahbtex-char-vs-uchar) i artikeln). * Genom att använda inmatningstextfiler som innehåller emoji-tecken i UTF-8-format. * Genom att använda LaTeX-kommandon (makron) som infogar emoji-tecken. #### Att klistra in emoji och andra icke-BMP-tecken i Overleaf Om du klistrar in ett emoji-tecken, till exempel 😀, i Overleafs Code Editor, kommer det för närvarande att omvandlas till tecknen ��. ![Fel på grund av att icke-BMP-tecken kopieras + klistras in i Overleafs redigerare](/files/5055b9e5408dbb7bbe855b5d7ff01522d41067ef) Tecknet � har Unicode-kodpunkten FFFD och dess officiella namn är REPLACEMENT CHARACTER och används för att ”[ersätta ett okänt, oigenkänt eller orepresenterbart tecken](https://en.wikipedia.org/wiki/Specials_\(Unicode_block\))”. ### Användning av Unicode-kodpunkter (U+) i LuaLaTeX Unicode-dokumentationen representerar kodpunktsvärden med notationen `U+`—såsom `U+1F600`, där `1F600` är `` av Unicode-kodpunkten för emoji-tecknet 😀. För att använda dessa kodpunktsvärden i LuaLaTeX tar du bort `U+` och skriver `\char"` eller `\Uchar"`. Paketet `"` anger för en TeX-motor att talet som anges är specificerat i hexadecimal form. Till exempel, för att använda emoji-tecknet 😀 skulle du skriva `\char"1F600` eller `\Uchar"1F600`—med ett teckensnitt som kan sätta det i text. Ett minimalt LuaLaTeX-exempel som använder `\char` och `\Uchar` för att sätta emoji-tecknet 😀 kan vara: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz]{NotoColorEmoji.ttf} %Använd \emojifont i en grupp för att hålla dess effekter lokala {\emojifont \Uchar"1F600 \char"1F600} \end{document} ``` [Öppna detta LuaLaTeX-exempel i 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) **(valfri detalj) LuaTeX/LuaHBTeX: \char kontra \Uchar** Utöver det konventionella `\char` kommandot för att sätta ett visst ``, med det aktuella teckensnittet, tillhandahåller LuaTeX-, LuaHBTeX- och XeTeX-motorerna också `\Uchar` kommandot. Ur en användares perspektiv ser resultatet av `\char` och `\Uchar` likadant ut, men det finns en subtil skillnad i hur dessa kommandon fungerar, som vi noterar nedan. **Den viktigaste skillnaden: expansion** `\Uchar` är ett så kallat [expanderbart kommando](/latex/sv/fordjupade-artiklar/22-how-does-expandafter-work-the-meaning-of-expansion.md#expansion-a-general-term-for-a-set-of-operations) medan `\char` inte är expanderbart. När ett `\char` eller `\Uchar` kommando ”körs” — dvs. kommandot lagras inte som en del av ett makro eller annan tokenlista — sker följande inne i TeX-motorn: * **`\char`** instruerar TeX-motorn att omedelbart infoga en teckentoken som representerar ``, i det innehåll som det för närvarande sätter. * I motsats till detta, **`\Uchar`** har två distinkta bearbetningssteg: 1. Den `\Uchar` kommandot är *expanderats*kört, och `` omvandlas till en tillfällig tokenlista som innehåller ett enda [teckentoken](/latex/sv/fordjupade-artiklar/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md#tex-tokens-101-28and-notions-of-expansion29) som representerar ``. 2. Denna tokenlista med ett enda tecken är nu *gjord tillgänglig* för TeX-motorn som källan till dess nästa indata. I praktiken ”flyttar TeX-motorn tillfälligt blicken” för att använda den tokenlista med en token som platsen för dess nästa indataobjekt (token). Som standard går TeX-motorn helt enkelt tillbaka för att läsa (mata in) den tokenen och sätta motsvarande tecken, vilket återger beteendet hos `\char` kommandot. **Men**, eftersom den där `` inte sattes omedelbart i text, utan tillfälligt *lagras* (sparades) som en enda token, kan primitiva TeX-kommandon eller LaTeX-makron använda (absorbera) den tokenen — den behöver inte sättas direkt utan kan användas i vidare bearbetning efter behov. I praktiken, `\char` säger ”sätt detta `` nu”, medan `\Uchar` har en form av ”fördröjd verkan” genom att skapa en lagrad teckentoken och göra den tillgänglig som nästa indatapunkt (en token). Den tokenen kan antingen användas (absorberas) av TeX-kommandon och makron eller läsas in på nytt av TeX-motorn och sättas. ### Unicode (kodning) är inte hela historien Möjligheten att använda emoji-tecken i Unicode-kodad text är bara en del av emojins framgångshistoria. Ökningen i användningen av emoji möjliggjordes också av utvecklingen inom [OpenType-teckensnittsteknik](https://learn.microsoft.com/en-us/typography/opentype/)—teckensnitt vars glyfdata (teckendesign) kan innehålla [färginformation](https://learn.microsoft.com/en-us/typography/opentype/spec/colr): så kallad [OpenType-färgfonter](#opentype-color-fonts). Förutom lämpliga teckensnitt kräver användning av färgemoji ytterligare programvarukomponenter vars uppgifter omfattar: * förbearbetning ("[formning](#the-concept-of-text-shaping)") av Unicode-kodad text, *förbereda* den för visning med ett visst teckensnitt; * *rendering och visning* av ett teckensnitts färgstarka emoji *glyfer* på en enhets skärm. #### Glyph kontra tecken: är de inte samma sak? Termerna ”glyph” och ”tecken” används ofta som om de vore utbytbara — de syftar på samma grundläggande begrepp — men det finns en subtil, även om viktig, skillnad i deras betydelse. Unicode [definierar termen ”tecken”](http://www.unicode.org/glossary/#character) som: > ”Den minsta komponenten i skrivet språk som har semantiskt värde; syftar på den abstrakta betydelsen och/eller formen, snarare än en specifik form… ” I motsats till detta är en ”glyph” en *specifik* *form* (design) för *den visuella representationen* av ett visst *tecknet*. Frågan om tecken kontra glyphs kan lätt observeras när text med emoji visas på olika mjukvarusystem/plattformar, till exempel när samma text läses på din iOS- eller Android-baserade mobiltelefon eller Windows-dator. Oavsett vilken enhet eller plattform som används skulle den underliggande texten (sekvensen av tecken) innehålla samma Unicode-kodade *emoji* *tecken*. Det är enhetsspecifika funktioner som deltar i *förbearbetningen* av den texten och därefter *renderingen* och *visnings* av resultaten, kanske med hjälp av enhetsspecifika teckensnitt, vilket ger olika glyfer (teckendesign) för att representera samma emoji-tecken. Unicodes [Fullständiga emoji-lista](https://unicode.org/emoji/charts/full-emoji-list.html) tillhandahåller exempelbilder som representerar varje Unicode-emoji-tecken — som visar olika glyfer som används av olika teknikleverantörer. Inte bara väljer teckensnittsdesigners sina egna särskilda designer (glyfer) för att representera emoji-tecken, utan enskilda teckensnitt varierar också i antalet emoji-tecken de stöder (har glyfer för) och kan innehålla eller inte innehålla mer avancerade funktioner för emoji-textbearbetning som ingår i Unicode-specifikationerna för emoji. Begreppet och konceptet tecken, deras semantik och kodning, utgör grunden för Unicode-världen: den handlar om tecken. Designen och den visuella representationen av enskilda tecken, som glyfer, hör till teckensnittstekniker och teckensnittsdesignens hantverk. #### Unicode-emoji: mycket mer än textkodning Unicodes kärnroll är att tillhandahålla en global kodningsstandard som definierar vilket heltalsvärde, kallat en *kodpunkt,* som ska användas för att representera varje tecken, inklusive emoji, inom en ström av Unicode-kodad text. Unicodes specifikation för emoji definierar också *bearbetningsbeteenden* för vissa *sekvenser* av emoji-tecken som förekommer inom en ström av Unicode-kodad text. Definierade sekvenser av emoji-tecken kan ”slås samman” genom en process som kallas [textformningen](#the-concept-of-text-shaping) för att skapa en enda resulterande (”sammansatt”) emoji-glyf — den enda glyfen skulle användas av enhetens operativsystem för att representera den ursprungliga teckensekvensen som finns i texten. Unicodes tekniska rapport om [Unicode-emoji](https://unicode.org/reports/tr51/) dokumenterar den rika uppsättning funktioner som är tillgängliga för programvara som vill tillhandahålla Unicode-kompatibel bearbetning av emoji-tecken. Som exempel definierar (kodar) Unicode tecken som kallas [emoji-modifierare](http://www.unicode.org/reports/tr51/#Emoji_Modifiers_Table) som kan användas för att generera *varianter* av ”bas-emoji”-tecken, såsom variationer i [hudton baserad på Fitzpatrick-skalan](http://www.unicode.org/reports/tr51/#Diversity). Observera att uppsättningen av bas-emoji-tecken och de tillämpliga modifierarna definieras som en del av den övergripande [Unicode-emoji-standarden](http://www.unicode.org/reports/tr51). Unicode-sidan [Emoji-sekvenser](http://unicode.org/emoji/charts/emoji-sequences.html) tillhandahåller ett diagram över de sekvenser som för närvarande anges av Unicode-specifikationen. Håll muspekaren över någon av emoji-glyfbilderna för att se en liten popup-verktygstips som talar om för dig den underliggande Unicode-emoji-teckensekvens som skapar den glyfen: ![EmojiSequenceChart.png](/files/4f0ba36277a57db5419c4a8596c1e3dae1053d72) Till exempel är emoji-glyfen: ![HandMediumSkinTone.png](/files/2832f0e8d64d3a21e3441a3d1ac00c03210da43c) finns listad i [avsnittet för modifierarsekvenser](http://unicode.org/emoji/charts/emoji-sequences.html#modifier_sequences) och skapas av tvåteckenssekvensen U+1F44B U+1F3FD. Dessa komponenttecken är: U+1F44B:![UnicodeWavingHandDefault.png](/files/e8d272bd829099790839f59f972d85d50d9a1fce) (VINKANDE HAND) U+1F3FD:![FitzPatrick3.png](/files/a3345d610e5dec11579f85dafd8ff5dbb2ff4f11) (EMOJI-MODIFIERARE FITZPATRICK TYP 4) **Användning av hudtonmodifierare i LuaHBTeX** Följande exempel använder LuaHBTeX för att demonstrera användningen av emoji-modifierare: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=HarfBuzz,SizeFeatures={Size=20}]{NotoColorEmoji.ttf} Isolerad vinkande hand: {\emojifont\Uchar"1F44B}\par Isolerad modifierare: {\emojifont\Uchar"1F3FD}\par Kombinerat resultat: {\emojifont\Uchar"1F44B\Uchar"1F3FD} \end{document} ``` [Öppna detta LuaLaTeX-exempel med emoji-modifierare i 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) Det här exemplet ger följande utdata: ![ModifiersInLuaHBTeX.png](/files/b30dd00d38c57f27bb7cfb4a21ab9adc314bec16) #### UTF-8: dess roll i lagring av Unicode-text All text eller kod som du skriver eller klistrar in i Overleafs Code Editor (eller Visual Editor) kommer att lagras i UTF-8-format, så vi ska kort gå igenom vad UTF-8 faktiskt betyder. UTF står för Unicode Transformation Format, och UTF-8:s roll i lagring eller överföring av Unicode-kodad text anges av frasen ”Transformation *Format*.” Unicodes kodpunktsvärden sträcker sig från 0 till ett maximum på 1 114 111, så det är omöjligt att representera alla Unicode-teckenvärden med en enda 8-bitars byte, som bara kan lagra upp till 256 olika värden: 0 till 255. Det är dock möjligt att representera vilket Unicode-kodpunktsheltal som helst med en *följd av* bytestora värden — vilket är principen bakom UTF-8. UFT-8 tillhandahåller ett ”recept” för att *omvandla* (dvs. att ”koda” eller ”konvertera”) ett Unicode-heltalsvärde för en kodpunkt till en unik följd av 1 till 4 på varandra följande bytestora heltal: antalet på varandra följande byte som krävs beror på värdet på kodpunktsheltalet. Följaktligen kan du läsa om UTF-8 som lagrar Unicode-tecken som *flerbytessekvenser* eftersom ett enda Unicode-tecken (kodpunktsheltal) representeras i UTF-8 som en sekvens av 1 till 4 på varandra följande byte. Naturligtvis kan text som lagras i UTF-8 konverteras tillbaka till sin ursprungliga följd av heltalsvärden för Unicode-kodpunkter — det är vad XeTeX eller LuaTeX/LuaHBTeX måste göra när de läser en LaTeX-indatafil lagrad i UTF-8-format. Dessa TeX-motorer behöver känna till Unicode-kodpunktsvärdena (teckenvärdena) i indata innan de kan sätta texten. Observera att pdfTeX inte har inbyggd förmåga att avkoda UTF-8, så den måste förlita sig på TeX-makron för att bearbeta (avkoda) indatatext formaterad i UTF-8. **Några UTF-8-exempel** * Den arabiska bokstaven ش (”sheen”) har Unicode-kodpunkten 0634 i hexadecimal form (bas 16) eller 1588 i decimal form (bas 10). I UTF-8 representeras ش som 2 (hexadecimala) värden D8 och B4, så tecknet ش skulle lagras som de två på varandra följande byten D8B4 i UTF-8-kodad text. * Emoji-tecknet 😀 har Unicode-kodpunkten 1F600 i hexadecimal form (bas 16) eller 128512 i decimal form (bas 10). I UTF-8 representeras 😀 som 4 (hexadecimala) värden F0, 9F, 98 och 80, så tecknet 😀 skulle lagras som de 4 på varandra följande byten F09F9880 i en UTF-8-textfil. #### Specialtecken som används i Unicode-baserad emoji-textbearbetning Inte alla tecken som kodas inom Unicode är avsedda för visuell presentation via glyferna i ett teckensnitt: vissa kodade tecken betecknas som *icke-utskrivbara tecken* vars syfte är att hjälpa specialiserade textbearbetningsfunktioner (i stödjande programvara). Olika programvaruapplikationer ger olika nivåer av stöd för de icke-utskrivbara tecken som kodas in i Unicode, så resultatet beror på den programvarumiljö — applikationer och teckensnitt — som används. **Två icke-utskrivbara tecken att känna till** * **Nollbreddsbindare (ZWJ)**, kodpunkt 200D (hexadecimal), är, som namnet antyder, utformad för att utlösa ”bindningsbeteendet” hos inmatningstecken — men bara om dessa inmatningstecken *har* ett definierat bindningsbeteende. * **Nollbreddsicke-bindare (ZWNJ)**, kodpunkt 200C (hexadecimal), är utformad för att *förhindra* det ”bindningsbeteende” som inmatningstecken annars skulle kunna uppvisa. Du kan till exempel använda ZWNJ för att förhindra bindningsbeteendet hos på varandra följande arabiska tecken som normalt skulle bearbetas (formas) till sina bindningsformer. Unicode har publicerat en lista över [rekommenderade emoji-ZWJ-sekvenser](https://unicode.org/emoji/charts/emoji-zwj-sequences.html) som använder en U+200D ZERO WIDTH JOINER (ZWJ) för att kombinera emoji-teckensekvenser till en enda sammansatt emoji-glyf — om den finns tillgänglig i de teckensnitt som används. **Exempel på användning av nollbreddsicke-bindare** Följande minimala kodfragment använder Scheherazade OpenType-teckensnitt, som ingår i TeX Live, för att definiera ett LaTeX-teckensnitt kallat `\arabicfont` som vi kan använda för att sätta lite arabiska. Raden ```latex {\arabicfont Icke-bindande:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} ``` använder ett nollbreddsicke-bindande tecken, via `\Uchar"200C`, för att förhindra det normala bindningsbeteendet hos de två arabiska bokstäverna ل (lam) och ا (alef). Observera användningen av `\textdir TRT` för att ställa in textens riktning som höger-till-vänster: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\arabicfont[Script=Arabic,Renderer=Harfbuzz,SizeFeatures={Size=40}]{Scheherazade} {\arabicfont Bindande:\textdir TRT\Uchar"0644\Uchar"0627}\par {\arabicfont Icke-bindande:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} \end{document} ``` [Öppna detta LuaLaTeX-exempel i 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) Det här exemplet ger följande utdata: ![NonJoiner.png](/files/a7b8c7884b5c5a864111af5198437380f34ef31a) ## Begreppet ”textformning” Låt oss börja med ett visuellt exempel med en urduöversättning av ordet ”utbildningsmässig”. Texten i urduöversättningen kan skrivas på ett tangentbord eller en pekskärm och skulle skapas som en enkel linjär sekvens av Unicode-arabiska tecken. Men när den texten sätts, eller visas på en enhetsskärm i [Nastaliq-stil](https://en.wikipedia.org/wiki/Nastaliq), blir resultatet en komplex tvådimensionell arrangemang av glyfer. Med vårt urduexempel jämför följande grafik den linjära inmatningen av Unicode-arabiska *tecken* med utdata satt i Nastaliq-stil, som består av en tvådimensionell uppsättning av *glyfer* finns i det (gratis) teckensnittet [Awami Nastaliq](https://software.sil.org/awami/download/): ![](/files/96f8bd066766f0a43700edd062bd68bd4ea6f4d6) Processen att ”översätta” inmatningstecken till en uppsättning korrekt placerade utglyfer kallas *textformningen*, och är en viktig komponent i bearbetningen av text före dess visning eller sättning. Vårt exempel använde text på urdu (arabiskt skrift) eftersom resultatet av formningen är tydligt synligt, till skillnad från språk som använder latinsk skrift, såsom engelska, där formningen är mycket mindre framträdande — till exempel produktionen av enkla ligaturer. Textformning är avgörande när man använder skriftsystem såsom [Arabiska](https://en.wikipedia.org/wiki/Arabic), [Hebreiska](https://en.wikipedia.org/wiki/Hebrew_language), [Devanagari](https://en.wikipedia.org/wiki/Devanagari) eller [Malayalam](https://en.wikipedia.org/wiki/Malayalam), bara fyra exempel på så kallade *komplexa skriftsystem*. För att säkerställa korrekt presentation av text i dessa skriftsystem, och de språk som använder dem, behöver formningsprocessen noggrant hantera alla formningsregler och nyanser som finns i den specifika kombinationen av skrift och språk. Till exempel kräver vissa språk att flera inmatningstecken används för att generera en viss utglyf, eller så kan det finnas komplexa krav för noggrann placering av diakritiska tecken och omplacering mellan glyfer för att säkerställa att enskilda glyfer är korrekt placerade i förhållande till varandra. I allmänhet kräver formning av ett textstycke flera typer av information: * Skriftsystemet eller *skriftsystemet* som texten är skriven på. * Den specifika *språket* som används. Enskilda skriftsystem kan användas för flera språk, och varje kombination av skriftsystem och språk har sina egna nyanser i formningen. * Skriftens *riktning* för texten—såsom höger-till-vänster eller vänster-till-höger. * Ett *typsnitt* som tillhandahåller de glyfer som behövs för att representera den formade texten och, valfritt, innehåller ytterligare ”formningsregler” som vägleder textformningsprocessen. Kraven på textformning, särskilt för komplexa skriftsystem och deras tillhörande språk, kan vara extremt detaljerade och nyanserade, vilket visar behovet av specialiserad programvara som kan tillämpa potentiellt mycket komplexa ”regler” för textformning. Inte överraskande finns sådan programvara, och den kallas en *textformningsmotor*; den vi kommer att diskutera kallas [HarfBuzz](https://en.wikipedia.org/wiki/HarfBuzz), vars dokumentation är värd att läsa—till exempel [Varför behöver jag en formningsmotor?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html). **Vidare läsning om textformning** Dessa korta introduktioner rekommenderas varmt: * [Vad är textformning?](https://harfbuzz.github.io/what-is-harfbuzz.html#what-is-text-shaping) * [Varför behöver jag en formningsmotor?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html) **Teknisk not: flera formningstekniker (modeller)** HarfBuzz textformningsmotor stöder flera ”formningstekniker” som skiljer sig åt i hur de implementerar formningsprocessen—varje implementation kallas en *formare*, även inom `luaotfload` dokumentationen. Huvudfokus i denna artikel är OpenType-formning, men en alternativ, kostnadsfri teknik är [Graphite](https://scripts.sil.org/cms/scripts/page.php?site_id=projects\&item_id=graphite_aboutOT), utvecklad av [SIL International](https://www.sil.org/). En annan formningsmodell som stöds av HarfBuzz är [Apple Advanced Typography (AAT)](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html)—fonter som stöder AAT används i allmänhet på Apples teknikplattformar. **Exempel med Graphite-formaren** Följande exempel sätter text på urdu med hjälp av ett typsnitt som heter [Awami Nastaliq](https://software.sil.org/awami/download/), som stöder Graphite-formning och finns tillgängligt på Overleaf. Awami Nastaliq är skapat av [SIL International](https://www.sil.org/), organisationen som ansvarar för utvecklingen av Graphite-tekniken. Följande exempel demonstrerar den avancerade formningsförmågan hos Graphite-baserade typsnitt—lägg märke till hur `luaotfload` typsnittsdeklarationen väljer Graphite-formning med `shaper=graphite2`. ```latex \documentclass{article} \usepackage{luaotfload} \begin{document} \font\urdutest={file:AwamiNastaliq-Regular.ttf:mode=harf;shaper=graphite2} at 100bp % Teknologi \pardir TRT\textdir TRT \urdutest ٹیکنالوجی \vskip 75bp % Utbildning \pardir TRT\textdir TRT \urdutest تعلیمی \end{document} ``` [Öppna detta exempel i 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) Det här exemplet ger följande utdata: ![](/files/87f513883b7e1714d6cff6e430cc2a774a8a26fd) #### Emoji och textformning Textformning har introducerats med exempel från ett komplext skriftspråk, urdu. Men det kan komma som en överraskning att korrekt återgivning av emoji-glyf(er) kräver att textformning tillämpas på Unicode-text som innehåller sekvenser av emoji-tecken—[som HarfBuzz huvudutvecklare påpekar](https://github.com/harfbuzz/harfbuzz/issues/2428#issuecomment-639108677): > ...att forma emoji med HarfBuzz ligger helt inom området och är faktiskt nödvändigt för att få familjeemoji, hudfärg osv. Vi kommer att titta på exempel på detta. ### Ansvarsuppdelning: textformningsmotor + OpenType-typsnitt I praktiken är textformning en ”gemensam operation”, eller arbetsdelning, mellan logiken och reglerna inbyggda i textformningsmotorn och ytterligare formningsregler och data inbyggda i de typsnitt som används—från och med nu behandlar vi OpenType-baserad formning *endast*. För att utföra formning förses textformningsmotorn vanligtvis med viss Unicode-text, ett angivet skriftsystem och språk, eventuellt en skrivriktning och, viktigast av allt, ett OpenType-typsnitt att använda under formningsprocessen—typsnittet kommer att ge utdata: en uppsättning glyfer och positioneringsdata. Om så begärs kan formningsmotorn tillämpa ytterligare regler ([OpenType-funktioner](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features)) som finns i det OpenType-typsnitt som används—vilka regler som ska tillämpas kan vanligtvis väljas av användaren från listan över funktioner som stöds av typsnittet. Resultatet av formningsprocessen är en *lista över glyfer* som finns i OpenType-typsnittet, tillsammans med *inter-glyf* positioneringsdata. Denna positioneringsdata avser *det relativa läget för de formade glyferna*; den hänvisar inte till absolut positionering på den sättda sidan eller annat medium/innehåll såsom en webbsida, Tweet osv. Renderingsprogramvaran (sättningsmotorn, webbläsaren osv.) använder den inter-glyfiska positioneringsinformationen för att säkerställa att glyferna positioneras korrekt i förhållande till varandra efter att de har sammanställts och införlivats i den slutliga utmatningen. #### Vad är en lista över glyfer? Internt tilldelas varje glyf i ett OpenType-typsnitt en numerisk identifierare, ett heltalsvärde kallat glyfindexet—även kallat glyfidentifieraren eller GID. Efter att textformningsmotorn har slutfört sin formningsuppgift kommer den att returnera resultatet som en *lista över glyfidentifierare* plus *positioneringsdata* för dessa glyfer. Enskilda glyfer i OpenType-typsnitt tilldelas index (identifierare) av typsnittets skapare, vilket gör det till ett mycket typsnittsspecifikt och godtyckligt värde—det kan också variera mellan versioner av ett visst typsnitt. Du bör aldrig anta att samma GID-värde gäller för ”liknande” glyfer i olika typsnitt; det gör det nästan säkert inte. Om du har en lista över glyfidentifierare som tillhandahålls av en formningsmotor, kan du bara använda dem för att komma åt glyferna i det typsnitt som de hämtades från. #### Vad är OpenType-typsnitt? Webben är *översvämmad* med förklaringar och detaljer om OpenType-typsnitt, så vi begränsar oss till en kort beskrivning. OpenType-specifikationen [OpenType-specifikationen](https://docs.microsoft.com/en-us/typography/opentype/spec/) är ett komplext dokument utformat för utvecklare, men i grunden definierar den ett filformat, eller en behållare, för typsnittsdata. Ett OpenType-typsnitt innehåller data som beskriver glyfformerna, tillsammans med information om vilka skriftsystem och språk som stöds, metadata om typsnittet och olika ”tabeller” som definierar [typografiska funktioner](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features) som stöds av typsnittet. En textformningsmotor kan vanligtvis instrueras att selektivt tillämpa (använda) ett typsnitts funktioner under formningsprocessen och tillämpa specifika typografiska effekter (”regler”) som väljer lämplig uppsättning glyfer som finns i typsnittet. Det valda typsnittet måste stödja och tillhandahålla glyfer för alla funktioner som textformningsmotorn ombeds tillämpa. #### Kodade och okodade ”glyfer” OpenType-typsnitt inkluderar en datatabell kallad [cmap](https://docs.microsoft.com/en-us/typography/opentype/spec/cmap) (Character to Glyph Index Mapping) som mappar mängden Unicode-tecken som stöds av typsnittet till motsvarande glyfindex i det typsnittet. Följande video ger en kort inblick i cmap-tabellen som finns i ett typsnitt som heter `lmmono10-regiular.otf` (ingår i TeX Live). {% embed url="" %} Typsnitt innehåller dock vanligtvis många glyfer som inte representerar ett specifikt Unicode-tecken och som inte ingår som en del av den cmap-tabellen. Följaktligen kan mängden glyfer som finns i ett OpenType-typsnitt delas in i två huvudmängder: * kodade glyfer som representerar Unicode-tecken; * okodade glyfer som inte representerar Unicode-tecken. Kodade glyfer kan nås genom att inkludera rätt Unicode-tecken i texten—men hur är det med okodade glyfer, hur används/de åtkoms? Dessa glyfer används vanligtvis för att ge utdata från textformningsoperationer, inklusive tillämpning av typsnittsfunktioner för att producera specifika visuella/typografiska effekter. ### OpenType-färgfonter Emoji-tecken förväntas visas/återges i fullfärg—svartvita emoji ger inte riktigt den ”fullständiga emojiupplevelsen”. Men vid tidpunkten för Unicodes initiala kodning av emoji hade [OpenType-typsnittsspecifikationen](https://docs.microsoft.com/en-us/typography/opentype/spec/) ingen lämplig möjlighet för att bädda in *colorful*-glyfdata i OpenType-typsnitt. Denna ”lucka” i OpenType fick ledande teknik-/plattformleverantörer att söka lösningar, och det efterföljande ”loppet” resulterade i [olika förslag om att utöka OpenType](https://www.fontlab.com/news/color-font-format-proposals/) för att stödja OpenType-färgtypsnitt—not bara för att visa färgade emoji-tecken (glyfer) utan för att återge vilken glyf som helst i färg. #### Fyra varianter av OpenType-färgtypsnitt [Adobe, Microsoft, Google och Apple lämnade var sitt förslag](https://www.fontlab.com/news/color-font-format-proposals/) för att utöka OpenType så att det stöder fullfärgade OpenType-typsnitt och till slut antogs fyra förslag och inkluderades i den formella OpenType-specifikationen. För enkelhetens skull kan vi grovt gruppera dessa fyra varianter i vektorbaserade och rasterbaserade—men, som visas i denna [GitHub-repositoryt](https://github.com/simoncozens/test-fonts), är OpenType-specifikationen tillräckligt flexibel för att stödja OpenType-färgtypsnittsfiler som kombinerar dessa fyra grundtekniker. * **Vektorbaserade OpenType-typsnitt:** * **Microsoft**: glyfformer beskrivs med hjälp av en form av skiktade färgvektorer ([COLR](https://docs.microsoft.com/en-us/typography/opentype/spec/colr) och [CPAL](https://docs.microsoft.com/en-us/typography/opentype/spec/cpal) tabeller). * [**Adobe och Mozilla**](https://www.w3.org/2013/10/SVG_in_OpenType/) ([SVG-tabell](https://docs.microsoft.com/en-us/typography/opentype/spec/svg)): glyfformer ritas med SVG, som stöder glyfer konstruerade av vektorer *och rasterbilder*. Se också [Adobes användarguide för SVG-typsnitt](https://helpx.adobe.com/fonts/user-guide.html/fonts/using/ot-svg-color-fonts.ug.html). * **Rasterbaserade OpenType-typsnitt:** * **Google**: glyfer representeras av färgade PNG-bilder inbäddade i typsnittet ([CBDT](https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt) och [CBLC](https://docs.microsoft.com/en-us/typography/opentype/spec/cblc) tabeller). * **Apple**: glyfer representeras också av färgbilder inbäddade i typsnittet. Förutom PNG stöder Apples mekanism ([sbix-tabell](https://docs.microsoft.com/en-us/typography/opentype/spec/colr)) även JPEG och TIFF. Som en konsekvens måste operativsystem och programvara som stöder OpenType-färgtypsnitt hantera dagens landskap med blandad teknik. Du bör dessutom vara medveten om att enskilda OpenType-färgtypsnitt—och *versioner* av samma typsnitt—kommer att: * ha olika täckning av hela uppsättningen [Unicode-emoji-tecken](https://unicode.org/emoji/charts/emoji-list.html)—dvs. hur många emoji-tecken typsnittet tillhandahåller glyfer för; * använda olika glyfdesigner för att representera enskilda emoji-tecken; * variera i de funktioner de tillhandahåller för att stödja mer avancerade användningsområden av Unicode-standarderna, såsom [emoji-modifierare](https://unicode.org/reports/tr51/#Emoji_Modifiers_Table), och andra emoji-relaterade textbehandlingsfunktioner som beskrivs i [Unicode Technical Standard #51: Unicode Emoji](https://unicode.org/reports/tr51/). #### Buzzen kring HarfBuzz Vi har antytt behovet av en *textformningsmotor*: programvara som tar viss indata i form av Unicode-text, skriven med en specifik kombination av skriftsystem och språk, och med ett angivet typsnitt formar texten till en sekvens av glyfer, tillsammans med positioneringsdata, som kan användas för att sätta den ursprungliga indatatexten. [HarfBuzz](https://harfbuzz.github.io/) är en sådan textformningsmotor: den är [ett bibliotek med öppen källkod](https://github.com/harfbuzz/harfbuzz) och resultatet av mer än ett decennium av forskning och utveckling—och utvecklas och distribueras fortfarande aktivt som en del av många programvaruprodukter. HarfBuzz i sig utför inte ”sättning” utan tillhandahåller ”textformningstjänster” till programvara som väljer att integrera det, inklusive XeTeX, LuaHBTeX, [Adobe Photoshop och Adobe InDesign](https://en.wikipedia.org/wiki/HarfBuzz). Genom att integrera HarfBuzz kan TeX-motorer dra nytta av dess avancerade textformningsförmåga för att ge mycket sofistikerad flerspråkig sättning, särskilt för komplexa skriftsystem som arabiska, hebreiska, devanagari och många andra. Observera också att HarfBuzz används för att bearbeta och forma Unicode-emoji-texttecken, vilket vi kommer att utforska mer i detalj. Följande grafik sammanfattar den roll som HarfBuzz spelar när det integreras med programvara, såsom XeTeX eller LuaHBTeX, vid sättning av text i ett komplext skriftsystem, såsom arabiska: ![En översikt över arabisk textformning med HarfBuzz](/files/6bf2ec04d9a11483de412f36a922fc9dbb3bf0c2) **Utforska HarfBuzz** Den som är intresserad av att lära sig mer om HarfBuzz och de OpenType-formningstjänster som det tillhandahåller för XeTeX och LuaHBTeX kan [ladda ned en binär distribution av HarfBuzz](https://github.com/harfbuzz/harfbuzz/releases) som innehåller HarfBuzz-biblioteket (för programmerare) och kommandoradsverktyg `hb-view` och `hb-shape`. **Exempel: hur man använder hb-view** Skapa en ny fil i din favorittextredigerare med UTF-8-stöd och kopiera/klistra in följande sex emoji-tecken 👋👋🏻👋🏼👋🏽👋🏾👋🏿 i den textfilen, och spara sedan i UTF-8-format till en fil som till exempel heter `emoji.txt`. Observera att din textredigerare kan visa (reserv-)svartvita versioner av emojin eftersom den inte kan (är programmerad att) återge färgglyfer. När dessa 6 emoji har sparats bör filen `emoji.txt` innehålla UTF-8-data för följande sekvens av Unicode-emoji-tecken—vi har separerat emojimodifierarna med kommatecken endast för *lättare läsning*: * `1F44B` för att producera 👋 * `1F44B`, `1F3FB` för att producera 👋🏻 * `1F44B`, `1F3FC` för att producera 👋🏼 * `1F44B`, `1F3FD` för att producera 👋🏽 * `1F44B`, `1F3FE` för att producera 👋🏾 * `1F44B`, `1F3FF` för att producera 👋🏿 Det bör totalt finnas **11** Unicode-tecken, som vardera genererar 4 byte UTF-8-data, så att den resulterande `emoji.txt` filen bör vara 44 byte lång, exklusive eventuella radslutsmarkörer som används i slutet av raden som innehåller emojin. Den `hb-view` verktyget kan använda filen `emoji.txt`, tillsammans med ett lämpligt OpenType-färgtypsnitt som du väljer, till exempel `NotoColorEmoji.ttf`, för att generera en SVG-fil med HarfBuzz formade utdata. Följande kommandoradsexempel, som måste **skrivas på en rad** i din terminal, kommer att generera SVG-filen `emoji.svg`: ```latex hb-view --font-size=20 --output-file="emoji.svg" --output-format=svg --text-file=emoji.txt --font-file=NotoColorEmoji.ttf ``` Om körningen lyckas, kan filen `emoji.svg`, genererad av `hb-view`, öppnas i Inkscape och bör se ungefär ut så här: ![Hbvieemoji.png](/files/36ef40ad03b1be607287daf992194ba1a5f43e4b) `hb-view` kan användas för att utforska HarfBuzz-formning för vilken lämplig Unicode-textfil och OpenType-typsnitt som helst—det är absolut inte begränsat till användning med emoji! Skriv ```latex hb-view --help-all ``` för att se mängden kommandoradsalternativ för detta kraftfulla och praktiska verktyg. Lycka till med formningen! ## Textformning och TeX-motorer Här ska vi gå igenom textformningsförmågorna hos XeTeX och TeX-motorfamiljen LuaTeX. ### XeTeX XeTeX utvecklades i början av 2000-talet och banade väg för flera innovationer inom TeX-baserad sättning, framför allt *inbyggt* stöd för: * läsning av Unicode-text i UTF-8-format; * användning av OpenType-typsnitt; * textformning för flerspråkig sättning; * OpenType-baserad matematiksättning. XeTeX:s förmåga att enkelt och bekvämt sätta komplexa skriftspråk beror på dess inbyggda textformningsförmåga—ursprungligen baserad på den numera föråldrade, [ICU LayoutEngine](http://userguide.icu-project.org/layoutengine). Tack vare arbete av Khaled Hosny gick XeTeX över till att använda HarfBuzz för textformning, som noteras i ett tillkännagivande från [mars 2013](https://tug.org/pipermail/xetex/2013-March/024118.html). För den som vill sätta flerspråkig text nämns XeTeX vanligtvis som det TeX-valda valet—men nu finns det ett annat alternativ, LuaHBTeX, som vi ska utforska. ### LuaTeX och LuaHBTeX Utvecklingen av LuaTeX började omkring 2005 men följde en helt annan designfilosofi än XeTeX, som införde nya funktioner *direkt i* XeTeX-programvaran. Till skillnad från XeTeX valde LuaTeX:s utvecklare att ”...tillhandahålla en minimal uppsättning verktyg och inga lösningar.” (se [Referenshandbok för LuaTeX](https://www.pragma-ade.com/general/manuals/luatex.pdf)). I stället för att tillhandahålla en uppsättning ytterligare funktioner *inbyggda i* LuaTeX-baserade motorer öppnas LuaTeX-motorernas interna mekanismer upp så att utvecklare och kunniga användare kan utnyttja det integrerade skriptspråket Lua för att bygga sina egna lösningar. Till exempel kan LuaTeX-motorn, till skillnad från XeTeX, *direkt* inte använda OpenType-typsnitt; i stället måste OpenType-typsnitt läsas in och ”förberedas för användning” via fontladdningsfunktioner skrivna i Lua-kod. Dessa fontladdningsfunktioner kallas *återanrops* funktioner: Lua-kod som LuaTeX kommer att anropa (”köra”) när en begäran görs om att ladda ett typsnitt. Dessutom tillhandahåller LuaTeX-motorn inga *inbyggt* textformningsförmågor—även de måste tillhandahållas av extern kod som LuaTeX-motorn kan anlita för att ge den textformningstjänster. Även detta står i kontrast till XeTeX-motorn, som införde textformningsförmåga i kärnprogramvaran. #### luaotfload: nödvändig för att använda OpenType-typsnitt i LuaTeX/LuaHBTeX LuaTeX:s återanropsmekanism för fontladdning ger en stor flexibilitet, om än till ”priset” av extra programmering. Lyckligtvis för användare av LuaLaTeX har TeX-communityn utvecklat ett paket som heter `luaotfload`, som ingår i [den årliga utgåvan av TeX Live](https://www.tug.org/texlive/) och naturligtvis finns tillgängligt för Overleaf-användare. `luaotfload` är [finns på CTAN](https://ctan.org/pkg/luaotfload?lang=en) och har ett [utvecklingsarkiv på GitHub](https://github.com/latex3/luaotfload) där du kan följa de senaste utvecklingarna och [nya utgåvor](https://github.com/latex3/luaotfload/releases). `luaotfload` kan laddas direkt i ett LaTeX-dokuments preamble via ```latex \usepackage{luaotfload} ``` Observera att `luaotfload` är namnet på ett LaTeX *paketet*, vilket betyder att det har filnamnet `luaotfload.sty`. Om du ville använda `luaotfload` med ren TeX kan du göra det genom att lägga till raden ```latex \input luaotfload.sty ``` i ditt ren-TeX-dokument. Vanligtvis behöver användare av LuaLaTeX—dvs. de som sätter LaTeX med LuaTeX/LuaHBTeX—inte arbeta direkt med `luaotfload` eftersom [`fontspec` paketet](https://ctan.org/pkg/fontspec) kommer att ladda `luaotfload` paketet åt dig och ta hand om många lågnivådetaljer via användarnivåkommandon som tillhandahålls av `fontspec` paketet. ### LuaHBTeX: nya alternativ för textformning `luaotfload` är ett moget och kraftfullt Lua-bibliotek som tillhandahåller LuaTeX:s hantering av OpenType-typsnitt—tillsammans med tillhandahållandet av textformningstjänster för en rad språk och skriftsystem. Ursprungligen implementerades textformningsfunktionerna i `luaotfload` i ren Lua-kod, men utgåvan av TeX Live 2020 gav ett annat mainstream-alternativ för textformning—en ny LuaTeX-baserad motor kallad LuaHBTeX. ”HB” i LuaHBTeX står för HarfBuzz—i huvudsak är LuaHBTeX den ursprungliga LuaTeX-motorn *plus* med en integrerad HarfBuzz-textformningsmotor. I linje med LuaTeX:s designfilosofi innebär tillgången till HarfBuzz inte *automatiskt* att text kommer att formas av LuaHBTeX: HarfBuzz är ett annat verktyg som kan användas för att bygga textformningslösningar. LuaHBTeX:s integration av HarfBuzz är [programmerbar via Lua-kod](#introduction-to-the-luahbtex-harfbuzz-api), vilket har gjort det möjligt för `luaotfload`luaotfload:s utvecklare att lägga till HarfBuzz-baserade textformningslösningar. Följaktligen, [med början i version 3.1, som släpptes den 5 november 2019](https://github.com/latex3/luaotfload/releases/tag/v3.1), `luaotfload` förbättrades för att dra nytta av HarfBuzz—vilket gjorde HarfBuzz:s textformningsförmåga lätt att komma åt för den vanliga användaren. Läsare som är intresserade av de tekniska detaljerna kring HarfBuzz-integration med LuaTeX kan läsa denna [artikel av Khaled Hosny](https://www.tug.org/TUGboat/tb40-1/tb124hosny-harfbuzz.pdf). ### luaotfload: två alternativ för textformning (när ska man använda HarfBuzz?) Användare av LuaLaTeX har nu två alternativ för textformning: * `luaotfload`luaotfload:s ursprungliga (nodbaserade) implementation av textformning, skriven helt i Lua; * `luaotfload`luaotfload:s HarfBuzz-baserade formning—åtkomlig via Lua-kod som anropar HarfBuzz:s textformningsfunktioner. `luaotfload` ger tillgång till dessa två formningssystem via sin ”`mode`”-parameter—även om de flesta användare kommer att använda motsvarande `fontspec` “`Renderer`”-alternativet i stället för att direkt använda lågnivåfunktionerna i `luaotfload`. Var och en av `luaotfload`luaotfload:s textformningslösningar har sina styrkor och (nuvarande) svagheter, men vilken ska man använda, och när? Här är några punkter att överväga: * `luaotfload`luaotfload:s inbyggda nodbaserade bearbetning kan vara minneskrävande, särskilt för stora CJK OpenType-typsnitt. Att använda HarfBuzz för att forma CJK-text kan ge förbättrad hastighet och minskad minnesanvändning. * Använd HarfBuzz för komplexa skriftsystem eftersom det ”...förbättrar återgivningen av indiska och arabiska skriftsystem avsevärt och rekommenderas starkt för sådana skriftsystem.” (se `luaotfload` manualen). * HarfBuzz:s integration i luaotfload `luaotfload` är fortfarande relativt ny och under vidare utveckling. Vid skrivtillfället (juli 2021) är det lämpligt att använda luaotfload:s inbyggda formning (genom att sätta `mode=node`) för typsnitten i ditt huvuddokument, särskilt om dokumentet använder latinskt skriftsystem. Se detta [GitHub-ärende](https://github.com/latex3/luaotfload/issues/175#issue-801120377), som sammanfattar problemen och diskussionerna. Om du vill experimentera kan du använda `luaotfload` för att ladda en typsnittsfil och skapa två LaTeX-typsnitt: ett som använder HarfBuzz-baserad formning och det andra som använder Lua-baserad formning. Overleaf skapade ett [exempelprojekt](#sample-project-arabic-shaping), som demonstrerar detta. * Använd inte HarfBuzz för att hantera matematiska typsnitt. Som utvecklare på tex.stackexchange har diskuterat är HarfBuzz [inte konstruerat för att hantera typsnitt för matematisk sättning](https://tex.stackexchange.com/questions/544881/does-luahbtex-with-harfbuzz-renderer-completely-supports-math-formating) så använd det inte för det ändamålet. **Exempelprojekt: arabisk formning** Här är ett Overleaf-projekt som använder flera högkvalitativa arabiska teckensnitt för att jämföra `luaotfload`s nodbaserade textformningstjänster (`mode=node`) med HarfBuzz:s (`mode=harf`): * Detta projekt innehåller utdata som visas i följande bild: ![Sättning av arabiska](/files/4fd5550cf96e50c4b409e67029820b69476c77c3) ### Att välja ”Renderer” i fontspec Som noterat i dess [dokumentationen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), `fontspec` ”...gör det möjligt för användare av antingen XeTeX eller LuaTeX att ladda OpenType-typsnitt i ett LaTeX-dokument”. Om du använder LuaTeX- eller LuaHBTeX-motorerna, `fontspec` kommer att ladda `luaotfload` fontspec-biblioteket åt dig och tillhandahåller dessutom en uppsättning praktiska kommandon på användarnivå som minskar behovet av att arbeta med `luaotfload`s lågnivåfunktionalitet. Så hur väljer du mellan HarfBuzz-formning eller den inbyggda formning som tillhandahålls av `luaotfload`? Svaret finns i den utmärkta [`fontspec` dokumentationen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), särskilt del VI: fontfunktioner endast för LuaTeX. `fontspec` tillhandahåller en inställning som kallas `Renderer` som kan ställas in när typsnittet definieras via `fontspec`. `Renderer` styr lågnivåbearbetningen av typsnittet. De två alternativen av intresse är * `Renderer = Node`: standardläget för sättning av OpenType-typsnitt—detta använder `luaotfload`s textformningsfunktioner implementerade helt i Lua. * `Renderer = Harfbuzz`: detta läge definierar/laddar typsnittet för användning med HarfBuzz textformningsmotor. `luaotfload` använder LuaHBTeX:s API för att anropa funktioner i HarfBuzz. För mer information, se [`fontspec` dokumentationen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf). ## TeX-motorer, HarfBuzz och färgemoji Även om både XeTeX och LuaHBTeX integrerar HarfBuzz, ger de olika nivåer av stöd för några av HarfBuzz:s mer avancerade funktioner—framför allt inläsning och användning av OpenType-färgtypsnitt. ### XeTeX och OpenType-färgtypsnitt Som nämnts finns det två kategorier av OpenType-färgtypsnitt baserat på det dataformat som används för att lagra typsnittsglyferna: vektorbaserade och rasterbaserade. #### XeTeX och rasterbaserade OpenType-färgtypsnitt XeTeX kan inte läsa in rasterbaserade OpenType-färgfonter—såsom Googles [Noto Color Emoji](https://www.google.com/get/noto/help/emoji/) som levereras med TeX Live 2020. Till exempel, om du försöker läsa in Noto Color Emoji (NotoColorEmoji.ttf) kommer XeLaTeX att misslyckas med ett potentiellt vilseledande fel som hävdar att Noto Color Emoji “inte kan hittas”. Följande LaTeX-kod, sätts med XeLaTeX, *fungerar inte*: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{NotoColorEmoji.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} \smiley \end{document} ``` [Öppna denna XeLaTeX-kod i Overleaf (den ***gör inte*** fungerar).](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) Den misslyckas med felet: ``` ! Paketet fontspec fel: Typsnittet "NotoColorEmoji" kan inte hittas. ``` På liknande sätt misslyckas också ett enkelt Plain TeX-exempel bearbetat av XeTeX ```latex \font\emojifont="[NotoColorEmoji.ttf]" at 12pt \emojifont \char"1F600 \bye ``` [Öppna detta Plain TeX-(XeTeX)-exempel i Overleaf (det ***gör inte*** fungerar).](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) Plain TeX-exemplet rapporterar ett liknande, men annorlunda, felmeddelande: ``` ! Typsnittet \emojifont=[NotoColorEmoji.ttf] vid 12,0pt kan inte läsas in: Metric (TFM)-fil eller installerat typsnitt hittades inte. l.1 \font\emojifont="[NotoColorEmoji.ttf]" at 12pt Jag kunde inte läsa storleksdata för detta typsnitt, så jag kommer att ignorera typsnittsspecifikationen. [Trollkarlar kan fixa TFM-filer med TFtoPL/PLtoTF.] Du kan prova att infoga en annan typsnittsspecifikation; t.ex. skriv `I\font='. ``` **Plain LuaHBTeX-exempel** Som jämförelse kommer här ett minimalt Plain TeX-exempel kompilerat med LuaHBTeX ```latex \input luaotfload.sty \font\emojifont=NotoColorEmoji.ttf:mode=harf at 12pt \emojifont \Uchar"1F600 \bye ``` [Öppna detta Plain TeX-(LuaHBTeX)-exempel i Overleaf (det kompileras utan problem).](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) #### Den verkliga orsaken till XeTeX:s misslyckande Felmeddelandena som XeTeX ger döljer delvis den faktiska orsaken till problemet: OpenType-färgfonter, särskilt rasterbaserade varianter, stöds *inte* av XeTeX. I själva verket kan XeTeX (Kpathsea) *hitta* Noto Color Emoji-typsnittet, men XeTeX kan inte fullt ut *läsa in* det typsnittet och kan inte initiera interna typsnittsdatatabeller som krävs för att använda det typsnittet för sättning. Internt *startar* utför XeTeX processen att läsa in typsnittet och testar det för “skalbarhet” (med FreeTypes “definition” av “skalbarhet”), men det testet misslyckas, och XeTeX ger ett standardiserat, och möjligen vilseledande, felmeddelande från TeX-motorn. **Teknisk not** XeTeX:s hantering av NotoColorEmoji.ttf undersöktes genom att kompilera en debugversion av XeTeX-programmet. Eclipse IDE användes för att sätta en brytpunkt på XeTeX-funktionen `creatFontFromFile(filename, index, pointsize)`, och sedan stegvis gå igenom koden för att observera den efterföljande bearbetningen. #### XeTeX och vektorbaserade OpenType-färgfonter XeTeX kan *läsa in* vektorbaserade OpenType-färgfonter men kommer inte att producera färgemoji i den resulterande PDF-filen—om XeTeX alls producerar en. Till skillnad från LuaTeX, LuaHBTeX och pdfTeX, skriver XeTeX inte ut satta dokument i PDF-format. I stället producerar XeTeX en mellanliggande *direkt* utdata i `.xdv` (e**x**tended **dv**i) filformat som konverteras till PDF av ett verktyg som kallas `xdvipdfmx`. För närvarande `xdvipdfmx` kan det inte bädda in lämpliga färgemoji-glyfdata i PDF-filen, så i bästa fall kommer du att se monokroma emoji—“fallback”-resultatet—i PDF-filen, eller kanske ingenting alls, beroende på typsnittet som används. Här är ett XeLaTeX-exempel som använder OpenType-färgfonten [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr), som finns tillgänglig i TeX Live. TwemojiMozilla.ttf använder Microsofts COLR/CPAL-vektorformat för att lagra färgglyfer och levereras med TeX Live 2020. I detta exempel kan XeTeX läsa in typsnittet, generera en `.xdv` och PDF-fil, men emoji-glyfen finns inte i den satta PDF-filen: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} Här är ett leende ansikte: \smiley \end{document} ``` [Öppna denna XeLaTeX-kod i Overleaf (den FUNGERAR INTE).](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) Däremot fungerar koden ovan med LuaLaTeX om man definierar `\emojifont` med hjälp av `fontspec` inställningen `[Renderer=HarfBuzz]`: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf}[Renderer=HarfBuzz] \newcommand{\smiley}{{\emojifont\char"1F600}} Här är ett leende ansikte: \smiley \end{document} ``` [Öppna denna LuaLaTeX-kod i Overleaf (det fungerar).](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 och OpenType-färgfonter Genom sin integrerade HarfBuzz-formningsmotor och `luaoftload` biblioteket ger LuaHBTeX stöd för alla fyra varianterna av OpenType-färgfont. Användare av LuaLaTeX kan dra full nytta av Unicode-baserad bearbetning av text som innehåller emoji-tecken eller helt enkelt förgylla sina dokument med mycket färgstark text med OpenType-färgfonter. Som nämnts tidigare kan de fyra varianterna av OpenType-färgfont klassificeras i två grupper: * de som innehåller glyfer i rasterbildformat, såsom PNG; * andra som använder vektorbaserade format som SVG eller Microsofts COLR/CPAL-mekanism. Vektorbaserade glyf-format har fördelen av skalbarhet: de ger skarpa glyfgrafiker i valfri punktstorlek. **Användning av Microsoft COLR/CPAL-färgfonter med LuaHBTeX** Om du vill använda ett vektorformat för dina OpenType-färgemoji-typsnitt, kolla in typsnittet [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr?lang=en), som bygger på Microsofts COLR/CPAL-format. TwemojiMozilla.ttf ingår i TeX Live, men du kan hämta den senaste versionen från dess [GitHub-repositoryt](https://github.com/mozilla/twemoji-colr/releases) och ladda upp den till ditt Overleaf-projekt. Här är ett litet, `fontspec`-baserat exempel som använder `Renderer=Harfbuzz`, som sätter en stor (vektor)emojianka: ```latex \documentclass{article} \usepackage{fontspec} \title{Duck demo} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{TwemojiMozilla.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Öppna detta LuaLaTeX-exempel för att sätta ut en vektoranka.](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) Här är den (vektor)anka som produceras av exemplet ovan: ![](/files/22e7d3f961d4946cbefd7b923faf848ac3b3fbcf) #### Att använda SVG-baserade OpenType-färgfonter med LuaHBTeX Vid tidpunkten för denna artikeluppdatering (juli 2023) finns det lite formell dokumentation om hur man använder SVG-varianten av OpenType-färgfonter med LuaLaTeX. Några [kommentarer i onlinediskussioner](https://github.com/latex3/luaotfload/issues/96) föreslår att man använder `fontspec`’s `RawFeature`, som visas i pseudokoden nedan. Ersätt `*your SVG font file name here*` med namnet på en SVG-baserad typsnittsfil som är tillgänglig för din LaTeX-kod: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emoji[RawFeature={+svg},SizeFeatures={Size=20}]{your SVG font file name here} \emoji Your emoji here... \end{document} ``` Om du utelämnar `fontspec` och läser in `luaotfload` direkt kan du behöva deklarera och ange ett typsnitt på följande sätt—våra experiment visar att du måste utelämna `mode=harf` alternativet för att detta ska fungera: ```latex \font\emoji=[your SVG font file name here]:+svg; ``` **Några försiktighetsanteckningar** Läsare som är intresserade av att använda SVG-varianten av OpenType-färgfonter bör notera: * SVG-varianten av OpenType-typsnitt som innehåller ett stort antal glyfer kan vara [beräkningsmässigt dyra för LuaLaTeX](#processing-svg-glyph-data) att bearbeta, vilket potentiellt kan leda till [Overleaf-timeouts](/latex/sv/kunskapsbas/038-fixing-and-preventing-compile-timeouts.md). * LuaLaTeX:s stöd för dessa typsnitt kan [betraktas som experimentellt](https://github.com/latex3/luaotfload/issues/96#issuecomment-530317399): resultaten kan variera beroende på vilken TeX Live-version som används i ditt projekt; följaktligen är det lämpligt att experimentera och gå försiktigt fram. **Bearbetning av SVG-glyfdata** SVG gör det möjligt för formgivare att skapa komplexa och färgstarka design som representerar ett typsnitts glyfer—med förbehåll för vissa SVG-begränsningar [som dokumenteras i OpenType-specifikationen](https://docs.microsoft.com/en-us/typography/opentype/spec/svg). Men TeX-motorer, inklusive LuaHBTeX, kan inte direkt importera (använda) SVG-filer eller data—såsom de SVG-data som används för att beskriva glyf-former inom OpenType-färgfonter av SVG-varianten. En glyfs SVG-data måste konverteras till PDF-format eftersom LuaHBTeX kan använda det för att sätta glyfen och producera det slutliga PDF-dokumentet. Denna SVG-till-PDF-konvertering hanteras av Lua-kod inom `luaoftload`: varje glyfs SVG-data extraheras från typsnittsfilen, sparas till en tillfällig `.svg` fil och konverteras till PDF med Inkscape via dess kommandorad. Att extrahera SVG-datan och konvertera den till PDF medför en viss bearbetningsöverhead, vilket resulterar i potentiellt långa dokumentkompileringstider—särskilt för dokument som använder stora SVG-typsnitt som innehåller tusentals emoji-glyfer. #### Rasterbaserade OpenType-färgfonter **Användning av Googles CBDT/CBLC OpenType-färgfontformat med LuaHBTeX** [Noto Color Emoji](https://fonts.google.com/noto/specimen/Noto+Color+Emoji) är en OpenType-färgfont som ingår i TeX Live, vilket gör den enkel att använda i ett Overleaf-projekt. Eftersom Noto Color Emoji använder grafik i PNG-format för att representera emoji-glyfer kan vi använda den för att sätta ut en stor (raster) anka-emoji—som visas i följande exempel. Observera återigen att `fontspec` typsnittsdeklarationen (`\emojifont`) använder `Renderer=Harfbuzz`. ```latex \documentclass{article} \usepackage{fontspec} \title{Duck demo} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{NotoColorEmoji.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Öppna detta LuaLaTeX-exempel för att sätta ut en rasteranka.](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) Här är rasterankan som produceras av exemplet ovan: ![En rasteranka-emoji sätts ut av LaTeX](/files/9522e03b89257778b98371c971907fde92828d45) Om du försöker använda `NotoColorEmoji.ttf` men utelämnar `[Renderer=Harfbuzz]` från `fontspec` deklarationen kommer LuaHBTeX att misslyckas och ge ett felmeddelande när det försöker skriva ut PDF-filen: ```latex ! fel: (fil /usr/local/texlive/2020/texmf-dist/fonts/truetype/google/noto-em oji/NotoColorEmoji.ttf) (ttf): loca-tabell hittades inte ``` Orsaken till detta fel i [loca-tabellen](https://docs.microsoft.com/en-us/typography/opentype/spec/loca) är [förklaras på GitHub](https://github.com/latex3/luaotfload/issues/98#issuecomment-531610153). **Användning av Apples sbix OpenType-färgfontformat med LuaHBTeX** Offline-tester visar att LuaHBTeX stöder `sbix` varianten av OpenType-färgfont men när denna artikel skrivs har vi inte kunnat hitta ett lämpligt licensierat `sbix`-variantfärgemoji-typsnitt för att demonstrera sättning av en anka. Vänligen [kontakta oss](https://www.overleaf.com/contact) om du känner till ett, så uppdaterar vi kvacksnabbt denna artikel för att använda det. ## Introduktion till LuaHBTeX HarfBuzz API ![Db.gif](/files/0b2fe999657a8bcbbb26b406ab3dcc61b1da189e) ![Db.gif](/files/0b2fe999657a8bcbbb26b406ab3dcc61b1da189e) Textformning, särskilt för språk med komplex skrift, och till och med emoji, är en i grunden svår uppgift så, föga förvånande, är HarfBuzz ett sofistikerat bibliotek som kan vara knepigt att arbeta med—om du inte redan är bekant med textformningsoperationer. I detta sista avsnitt tittar vi på LuaHBTeX:s integrering av HarfBuzz och hur man får tillgång till den via Lua-kod inom `\\directlua`. Vårt exempel använder ganska enkel kod för att demonstrera LuaHBTeX HarfBuzz API. Det är något tillgjort, inte produktionskvalitet, och inte särskilt praktiskt eftersom dess enda syfte är att introducera några kärnidéer. Vi har delat upp Lua-koden i två `\\directlua` bitar: den första laddar `luaharfbuzz` biblioteket och skapar några globala variabler som vi kommer att använda i vår andra `\\directlua` bit, där vi definierar en makro kallad `\codestoemoji`. Det känns lämpligt att återge Knuths användning av dubbla farliga böjningsmarkeringar (bild med tillstånd av [denna webbplats](http://www.truetex.com/db.htm)) eftersom innehållet är något lågnivåmässigt och “tittar under huven”—även om vi hoppas att det kan vara av intresse för den mer äventyrlige läsaren. LuaHBTeX:s integration av HarfBuzz är härledd från [luaharfbuzz-projektet på GitHub](https://github.com/ufyTeX/luaharfbuzz/wiki#projects-using-luaharfbuzz) där du kan hitta en [introduktion till projektet](https://github.com/ufyTeX/luaharfbuzz/wiki) tillsammans med en [listning av luaharfbuzz-API:et](http://ufytex.github.io/luaharfbuzz/). ### Första steg: ladda luaharfbuzz-biblioteket och hitta ett typsnitt För att använda LuaHBTeX:s HarfBuzz-API behöver vi först ladda biblioteket (modulen) som kallas `luaharfbuzz`, inbyggt i LuaHBTeX, och spara den returnerade tabellen i en (global) variabel som vi kommer att kalla `hblib`: ```latex hblib=require("luaharfbuzz") ``` Sedan behöver vi lokalisera ett lämpligt OpenType-färgfont för emoji: vi kommer att använda Noto Color Emoji—observera att vi är väldigt lata och inte gör någon felkontroll ifall vi inte hittar det! För att hitta det använder vi `kpse` (Kpathsea)-biblioteket, som också är en del av LuaTeX/LuaHBTeX: ```latex pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") ``` Nu när vi har tillgång till HarfBuzz-biblioteket, via vår variabel `hblib`, och sökvägen till ett lämpligt typsnitt (`pathtofontfile`), kan vi börja använda `hblib`. För att börja med skapar vi ett HarfBuzz-typsnitt och ett HarfBuzz-face för användning i det andra `\\directlua` kodblocket där vi definierar vår makro. ```latex %Skapa HarfBuzz-face och HarfBuzz-typsnitt från Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) ``` #### HarfBuzz-typsnitt och HarfBuzz-face: vad är de? Ett [HarfBuzz-face-objekt](https://harfbuzz.github.io/fonts-and-faces.html) representerar ett typsnitt som lästs in från en typsnittsfil, men utan att specifika parametrar (såsom storlek) har ställts in. Ett [HarfBuzz-typsnittsobjekt](https://harfbuzz.github.io/fonts-and-faces.html) representerar en *specifik instans* av ett HarfBuzz-face; följaktligen kan olika HarfBuzz-typsnittsobjekt härledas från ett enda HarfBuzz-face: varje HarfBuzz-typsnitt kan ha sina egenskaper, såsom storlek, inställda till olika värden. Ett HarfBuzz-face är en högre abstraktionsnivå än ett HarfBuzz-typsnitt. ### Användning av typsnittsglyfer för att skapa PNG-filer Den sista delen av vårt första `\\directlua` block är en funktion kallad `writePNGglyph(hbfontobject, glyphID)` som vi använder för att visa att vissa OpenType-färgfonter, såsom Noto Color Emoji, använder PNG-grafik för att representera de emoji-glyfer de innehåller. Denna funktion använder LuaHBTeX:s HarfBuzz-API för att extrahera PNG-data från glyfer och skriva dessa data till en `.png` filen med namnet `Graphics.png`. Namnet på den `.png` filen returneras för att användas av `\includegraphics` för att bädda in PNG-glyfbilder i vår satta PDF. Med `writePNGglyph(hbfontobject, glyphID)` på plats ser vårt första `\\directlua` kodblock ut så här: ```latex \directlua{ % Ladda luaharfbuzz-biblioteket från LuaHBTeX hblib=require("luaharfbuzz") % Lokalisera Noto Color Emoji-typsnittet på Overleafs server pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Skapa HarfBuzz-face och HarfBuzz-typsnitt från Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Denna funktion accepterar ett typsnitt och ett glyf-ID: % den extraherar glyfens PNG-data och skriver % ut den till en .png-fil function writePNGglyph(hbfontobject, glyphID) % Hämta glyfens PNG-data local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Konstruera ett filnamn för vår .png-fil local fname="Glyph"..glyphID..".png" % Skriv .png-filen och returnera filnamnet local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Returnera filnamnet som \includegraphics ska använda return fname end } ``` ### Andra \directlua-blocket: skapa makrot \codestoemoji Målet är att definiera ett makro `\codestoemoji` som vi kan anropa med en textbit som innehåller emoji-teckenkoder som vi vill att HarfBuzz ska forma. Mer specifikt kommer vi att använda `\Uchar` för att representera varje emoji-tecken; till exempel: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` Det händer mycket i definitionen av `\codestoemoji` som vi förklarar nedan, men definitionen ser ut så här: ```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() % Glyftabellen, hbglyphs, är 1-baserad local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Minska storleken på våra importerade PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} ``` #### Förstå definitionen av makrot \codestoemoji Den `\codestoemoji` makrot är mestadels Lua-kod som finns inom `\\directlua`, så om du vill veta mer om *hur* `\\directlua` fungerar, kolla in Overleaf-artikeln [Förstå `\\directlua`](/latex/sv/fordjupade-artiklar/09-an-introduction-to-luatex-part-2-understanding-directlua.md). Den förklarar hur LuaTeX och LuaHBTeX bearbetar `\\directlua` när TeX/LaTeX-kommandon ingår i Lua-koden och, särskilt, behovet av att använda `\noexpand` och `\unexpanded`. **Hantera makroparametern: "#1"** Makrot börjar med dessa tre rader: ```latex local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) ``` som utför följande uppgifter: * `local str="#1"`: detta skapar en Lua-sträng från indata som skickas in av makrot; * `local hbbuffer = hblib.Buffer.new()`: detta använder HarfBuzz-API:et för att skapa en buffert som ska hålla den text som vi vill att HarfBuzz ska forma; * `hbbuffer:add_utf8(str)`: detta lägger till en UTF-8-formaterad sträng, skapad från vårt makros indata, i HarfBuzz-bufferten. Den första kodraden ```latex local str="#1" ``` verkar ganska okomplicerad men dess funktion innebär ganska stor komplexitet, vilket är värt att utforska lite mer i detalj. Om vi betraktar den tredje kodraden ```latex hbbuffer:add_utf8(str) ``` ser vi att den använder vår `str` variabel för att förse HarfBuzz-bufferten med en Unicode-sträng formaterad i UTF-8. För att detta ska fungera måste variabeln `str` själv innehålla Unicode-text formaterad som UTF-8; så frågan uppstår: *hur* omvandlade LuaHBTeX makroargumentet `"#1"`, som innehåller `\Uchar` kommandon, till Lua-strängvariabeln `str` som innehåller UTF-8-text för HarfBuzz? Om vi tittar på vår avsedda användning av `\codestoemoji` makrot: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` indatan, såsom `\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065...`, ser inte alls ut som en sekvens av emoji-tecken kodade i UTF-8. Dessutom vet HarfBuzz ingenting om TeX-kommandon. På något sätt omvandlas den råa TeX-indata som består av `\Uchar` kommandon till Unicode-tecken kodade i UTF-8 som HarfBuzz kan använda, men *hur*? Svaret ligger i beteendet hos `\Uchar` kommandot: att försöka anropa `\codestoemoji` med hjälp av `\char` i stället för `\Uchar` kommer att misslyckas, men *varför*? **\Uchar-expansion i \directlua** När `\codestoemoji` makrot anropas måste `\\directlua` kommandot, som lagras i makrots definition, förbereda Lua-kod för att skickas till LuaHBTeX:s inbyggda Lua-tolk. En del av den kodförberedande processen är expansionen av alla TeX/LaTeX-kommandon som finns i den ursprungliga Lua-koden i makrots definition, tillsammans med expansionen av alla makroargument som tillhandahålls av användaren. Denna expansionsprocess ger en tokenlista som därefter konverteras tillbaka till text, vilket genererar Lua-koden som ska skickas till Lua-tolken. För enkelhets skull återger vi ett diagram från Overleaf-artikeln [Förstå `\\directlua`](/latex/sv/fordjupade-artiklar/09-an-introduction-to-luatex-part-2-understanding-directlua.md): ![\directlua:s mekanik](/files/976111671fec2207e2137bb2a54984212180653a) Makrot `\codestoemoji` är tänkt att anropas med `\Uchar` kommandon och, [som noterats tidigare i artikeln](#the-key-difference-expansion), `\Uchar` är ett expanderbart kommando vars expansion genererar en teckentoken. Inom bearbetningen av `\\directlua`, expanderar LuaHBTeX varje `\Uchar` kommando där det *tar bort* varje `\Uchar` bort från indata och *ersätter* det med motsvarande expansionsvärde: en teckentoken som representerar ``. I det sista bearbetningssteget konverteras den ursprungliga tokenlistan som genereras av `\\directlua` till *tillbaka till text* för att bli Lua-koden som är avsedd för Lua-tolken (se diagrammet ovan). Alla teckentokens som produceras av expansionen av `\Uchar` konverteras också *tillbaka till text*: denna konvertering av teckentokens till text genererar UTF-8-representationerna av de ursprungliga `` värdena. I vårt exempel, när Lua-koden har genererats och är redo för Lua-tolken, har makroindatan för "#1" konverterats till en följd av UTF-8-text: `str` variabeln är nu en UTF-8-textsträng som säkert kan läggas till i HarfBuzz-bufferten. **Varför fungerar inte \char?** Det raka svaret är eftersom `\char` är *inte* ett expanderbart kommando. Till skillnad från `\Uchar` kommandon, `\char` kommandon *tas inte bort* från inmatningen under `\\directlua`s första bearbetning för att generera en tokenlista, passerar de igenom och blir införlivade i den tokenlista som byggs upp av `\\directlua`. Om till exempel argumentet till `\codestoemoji` innehöll `\char"1F3F4` skulle LuaHBTeX omvandla det till en sekvens av tokens och lagra dem som en del av den totala tokenlistan som genereras. I nästa bearbetningssteg, när tokens konverteras tillbaka till text, skulle den resulterande Lua-koden innehålla den *bokstavliga strängen* `\char"1F3F4` i den text som används för att definiera vår variabel `str`. När innehållet i `str` läggs till i HarfBuzz-bufferten kommer det inte att innehålla en UTF-8-kodad sekvens som representerar emoji-tecknet "1F3F4, det skulle innehålla den bokstavliga strängen `\char"1F3F4`, som HarfBuzz kommer att försöka forma och som, i vårt sammanhang, inte skulle ge ett emoji-glyf. För övrigt skulle strängen `\char"1F3F4` också ge Lua-syntaxfel om den inte skapades som en ”long-bracket-sträng”—se [Vad är Lua-escape-sekvenser](/latex/sv/fordjupade-artiklar/09-an-introduction-to-luatex-part-2-understanding-directlua.md#what-are-e2809clua-escape-sequencese2809d3f) för bakgrund om det problemet. Om vi försöker använda `\codestoemoji` med en `\char` kommandot, så här: ```latex \codestoemoji{\char"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` kommer LuaHBTeX att misslyckas och rapportera ett syntaxfel ungefär som detta: ```latex [\directlua]:1: invalid escape sequence near '"\c'. \codestoemoji ...ing \includegraphics }.}]]) end } l.75 ...r"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} Lua-tolken stötte på ett problem, så resten av denna lua-chunk kommer att ignoreras. ``` #### Anropa HarfBuzz-formningsfunktionen **Ställa in buffertparametrar** HarfBuzz kräver ibland ytterligare information om texten den ombeds forma. Du kan tillhandahålla den informationen genom att konfigurera din `` med hjälp av *buffertmetoder*, såsom: * `:set_direction(*HarfBuzz direction*)`; * `:set_language(*HarfBuzz language*)`; * `:set_script(*HarfBuzz script*)`. Till exempel behöver vi informera HarfBuzz om att riktningen för vår emoji-text kommer att vara från vänster till höger. För att göra det använder vi `set_direction()` metoden på vår `` (kallad `hbbuffer`) genom att skriva: ```latex hbbuffer:set_direction(hblib.Direction.new("ltr")) ``` där `hblib.Direction.new("ltr")` skapar ett ”riktningsobjekt” som lämpar sig för att skickas till HarfBuzz-motorn via Lua. **Utför formning** När bufferten har initierats på rätt sätt kan vi be HarfBuzz att utföra själva formningen via funktionen `shape_full()`. I vårt exempel skriver vi: ```latex local res = hblib.shape_full(hbfont, hbbuffer, {},{}) ``` Den tredje och fjärde parametern i `shape_full()` funktionen måste vara Lua-tabeller – vi har använt tomma tabeller ”`{}`” för båda parametrarna. Den allmänna formen av `shape_full()` är: ```latex shape_full(Harfbuzz font, Harfbuzz buffer, {font features}, {"shaper"} ``` * **`{"shaper"}`**: Behöver vanligtvis inte anges men alternativen är `{"ot"}` eller `{"graphite2"}`. Mer information om begreppet en ”shaper” finns i [HarfBuzz-dokumentationen](https://harfbuzz.github.io/shaping-and-shape-plans.html)—observera att denna dokumenterar det lågnivå-C-API:t, inte den Lua-baserade `luaharfbuzz` bindningen (implementeringen). * **`{font features}`**: Det här är en tabell som listar de [OpenType-funktioner](https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist)—som stöds av typsnittet—som du vill att HarfBuzz ska tillämpa under formningen. Alla typsnittsfunktioner du vill använda behöver skapas med hjälp av en `luaharfbuzz` biblioteksfunktion ```latex library_instance.Feature.new(feature_string) ``` där * `library_instance` är din `luaharfbuzz` biblioteksinstansvariabel (`hblib` i vårt exempel); * `feature_string` använder en [syntax för att definiera funktioner](https://github.com/ufytex/luaharfbuzz/wiki/Feature-Strings). Exempel på detta är `+smcp` för att aktivera kapitäler eller `-kern` för att inaktivera kerning. Till exempel: ```latex local dosmcp = hblib.Feature.new("+smcp") local nokern = hblib.Feature.new("-kern") % Använd dina typsnittsfunktioner så här local res = hblib.shape_full(hbfont, hbbuffer, {dosmcp,nokern},{}) ``` #### Åtkomst till resultatet: hämta glypherna Och till sist, om formningsoperationen lyckas, returneras de formade glypherna i buffertvariabeln `hbbuffer` som vi skapade tidigare i koden. Vi kommer åt glypherna via buffertmetoden `get_glyphs()` och använder en loop för att hämta varje enskild glyf. Observera att Lua-tabellen som innehåller glypherna, `hbglyphs` i vårt exempel, är indexerad med början på 1, inte 0. Varje glyphs *glyfidentifierare* (förvirrande nog kallad `kodpunkt`), och HarfBuzz-typsnittet (`hbfont`), skickas till `writePNGglyph()` funktionen som skapar en PNG-fil med typsnittets rasteriserade bildrepresentation av den glyfen. `writePNGglyph()` skriver ut en PNG-fil och returnerar PNG-filnamnet, som används för att importera den (skalade) PNG-filen i vårt LaTeX-dokument via `\includegraphics[scale=0.75]{}`. Lägg märke till hur vi kan använda `\includegraphics` direkt i Lua-koden. ```latex if (res) then local hbglyphs=hbbuffer:get_glyphs() % Glyftabellen, hbglyphs, är 1-baserad local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Minska storleken på våra importerade PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end ``` ### Den fullständiga koden som du kan öppna i Overleaf ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \directlua{ % Ladda luaharfbuzz-biblioteket från LuaHBTeX hblib=require("luaharfbuzz") % Leta upp Noto Color Emoji-typsnittet på Overleafs server pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Skapa HarfBuzz-face och HarfBuzz-typsnitt från Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Denna funktion accepterar ett typsnitt och ett glyf-ID: % den extraherar glyphernas PNG-data och skriver % ut den till en .png-fil function writePNGglyph(hbfontobject, glyphID) % Hämta glyfens PNG-data local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Konstruera ett filnamn för vår .png-fil local fname="Glyph"..glyphID..".png" % Skriv .png-filen och returnera filnamnet local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Returnera filnamnet som \includegraphics ska använda 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() % Glyph-tabellen, hbglyphs, är 1-baserad. local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Minska storleken på våra importerade PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} En anka: \codestoemoji{\Uchar"1F986} En flagga: \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} \end{document} ``` [Öppna detta luaharfbuzz-API-exempel i Overleaf.](/latex/sv/fordjupade-artiklar/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md) Det här exemplet ger följande utdata: ![Harfbuzzexample.png](/files/965888e8fb88a8e28883f01d4a7be9d0fb259e58) ## Bonusavsnitt: Kul med emoji-matte För att avsluta med en lättsam ton använde en medlem i Overleaf-teamet [`emoji` LaTeX-paketet](https://ctan.org/pkg/emoji?lang=en) för att skapa ett roligt exempel: ```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} ``` [Öppna detta roliga exempel i 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) Det här exemplet ger följande utdata: ![Emojimath2.png](/files/c84ef90364a20181b74e54e8be843c58b0bf6512) --- # 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/sv/fordjupade-artiklar/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.