> 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/no/dybdeartikler/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md). # En oversikt over teknologier som støtter bruk av farge-emoji-fonter i LaTeX ## Innledning Denne artikkelen gir en oversikt over ulike [bakgrunnstemaer](#which-topics-do-we-cover) knyttet til bruk av OpenType-fargefonter for å sette fargeemoji i LaTeX. Vi har forsøkt å tilby et bredt spekter av materiale, tilpasset et stort spenn av interesser og ekspertise. For å holde artikkelen håndterlig utelater vår dekning av enkelte temaer mye teknisk detalj, men vi håper det finnes nok materiale til å gi deg retning i utforskningen av å sette fargeemoji i LaTeX. **Oppdatering (juli 2023)**: Denne artikkelen ble først publisert i august 2021 og revidert i juli 2023 for å oppdatere delen om [Bruk av SVG-baserte OpenType-fargefonter med LuaHBTeX](#using-svg-based-opentype-color-fonts-with-luahbtex). ### Hvilke temaer dekker vi? Denne artikkelen dekker følgende generelle temaer: * Unicode: standarden som koder emoji som tegn og fastsetter deres forventede oppførsel i tekstbehandlings- og typografiapplikasjoner. * OpenType-fargefonter: spesialiserte fonter som gir fargerike representasjoner av emoji-tegn som vises i LaTeX-dokumentet ditt. * Tekstforming: å introdusere en sentral komponent i typografering av komplekse skriftspråk og emoji. * HarfBuzz: komponenten i LuaHBTeX som muliggjør avansert flerspråklig typografering og bruk av OpenType-fargefonter for å sette emoji i LaTeX. * Ulike TeX-motorer: utforske støtten deres for OpenType-fargefonter og velge hvilken TeX-motor som skal brukes. * LuaHBTeX sin HarfBuzz-API: en introduksjon til «magien» bak [tekstforming](#the-concept-of-text-shaping) i LuaHBTeX. ### Tre måter å sette fargeemoji på Fargeemoji kan settes med LaTeX ved hjelp av tre hovedmetoder: 1. Bruke vanlige LaTeX-grafikkverktøy som TikZ, MetaPost eller Asymptote til å tegne emojien. 2. Sette inn emoji ved hjelp av forhåndsforberedte emoji-grafikker lagret i eksterne filer. 3. Behandle emoji som Unicode-kodet tekst og bruke [tekstforming](#the-concept-of-text-shaping) med [OpenType-fargefonter](#opentype-color-fonts) for å sette dem. De praktiske alternativene for å inkludere fargeemoji i LaTeX-dokumentet ditt avhenger av hvilken TeX-motor som brukes til å kompilere dokumentet: dvs. om du bruker: * pdfLaTeX: pdfTeX-motor + LaTeX; * XeLaTeX: XeTeX-motor + LaTeX; * LuaLaTeX: LuaHBTeX-motor (fra TeX Live 2020 og oppover) + LaTeX. Alle disse tre TeX-motorene kan bruke LaTeX-verktøy eller pakker til å tegne emoji eller bruke `\includegraphics{...}` for å sette inn emoji som er lagret i eksterne grafikkfiler. Å tegne eller importere grafikk er ideelle teknikker for å sette emoji når du trenger en løsning som ikke er avhengig av TeX-motoren som brukes til å kompilere LaTeX-dokumentet. Men hvis arbeidsflyten din gir fleksibilitet til å velge en bestemt TeX-motor, og du foretrekker å bruke OpenType-fargefonter og Unicode-basert tekstbehandling, er den nyeste versjonen av LuaTeX, kalt LuaHBTeX, det du trenger. Fra og med TeX Live 2020 brukes LuaHBTeX til å kompilere LaTeX-dokumenter basert på LuaLaTeX-formatet. ## Bakgrunn om Unicode og emoji-tegn ### Tegnkodinger Datamaskiner lagrer, overfører og behandler tekst ved hjelp av en sekvens av numeriske (heltalls-)verdier som representerer tekstens bestanddeler *tegn*. Pålitelig tekstbehandling krever at produsenter og forbrukere av tekst blir enige om hvilke heltallsverdier som skal brukes til å representere enkelttegn i tekststrømmen. Med andre ord, hva er tekstens *tegnet* *koding?* En koding er settet av avtalte heltallsverdier som er tildelt for å representere et bestemt sett med tegn: hvert tegn representeres av en heltallsverdi innenfor kodingen som brukes. ### Så kom Unicode Historisk sett, i den 8-bits tekstens tidsalder, ble mange ulike tegnkodinger brukt, noe som stadig skapte spøkelset av *kodingsmismatch*: produsenter og forbrukere av tekst som feilaktig antar ulike kodinger, noe som fører til feil i tekstbehandlingen. Alle som har jobbet med TeX/LaTeX i noen år, har sannsynligvis opplevd kodingsmismatch mellom inndatateksten og fontene som brukes til å sette et dokument. Hvis dokumentfontene er konfigurert til å bruke en annen koding enn teksten, fører det sannsynligvis til manglende eller feil tegn i den typograferte PDF-en. Disse historiske kodingsproblemene kan løses ved hjelp av en internasjonal standard som koder alle verdens tegn: Unicode. Unicode-standarden er ikke statisk, men oppdateres jevnlig for å inkludere flere tegn og skriftsystemer innenfor kodingsskjemaet. Det finnes en [formell gjennomgangsprosess for å foreslå nye tegn](http://www.unicode.org/pending/proposals.html) med et spesifikt [skjema for nye emoji-tegn](https://www.unicode.org/emoji/proposals.html). ### Hvor mange Unicode-tegn? Unicode koder et teoretisk maksimum på 1 114 112 tegn. Hver av de 1 114 112 heltallsverdiene kalles et *kodepunkt*: heltallsverdien som er tildelt for å identifisere hvert tegn. Men av ulike tekniske grunner kan bare [1 112 064 kodepunkter](https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology) tildeles faktiske tegn: 2048 kodepunkter kan ikke tildeles og er forbudt til bruk i Unicode-kompatibel tekst. Da denne artikkelen ble skrevet (den første versjonen), hadde versjon 13 av Unicode-standarden tildelt totalt 143 859 kodepunkter til faktiske tegn, inkludert [3304 tegn som nå er kodet som emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (se side 2 i det dokumentet). Veksten i antallet tegn som er kodet av Unicode er godt dokumentert i artikkelen [Hvor mange Unicode-tegn finnes det?](https://www.babelstone.co.uk/Unicode/HowMany.html) og i en [Wikipedia-artikkel](https://en.wikipedia.org/wiki/Unicode#Versions). ### Unicode-plan Hele samlingen av 1 114 112 Unicode-kodepunkter er gruppert i 17 såkalte plan: Plan 0 til Plan 16, hver med 65 536 kodepunktverdier, noe som gir et totalt antall på $$17\times2^{16} = 1,114,112$$ tegn. Plan 0, kalt det grunnleggende flerspråklige planet, koder de mest brukte tegnene. Planene 1–16 kalles [det grunnleggende flerspråklige planet](https://en.wikipedia.org/wiki/Plane_\(Unicode\)#Basic_Multilingual_Plane), koder de mest brukte tegnene. Planene 1–16 kalles [Tilleggsplanene](http://unicode.org/glossary/#supplementary_planes). ### Fremveksten av emoji Nye tegn oppstår gjennom endrede former for menneskelig kommunikasjon, og mobiltelefonteknologi ga opphav til ett slikt sett av tegn: emoji, som utviklet seg i Japan på slutten av 1990-tallet. Det er ikke overraskende at [Unicode FAQ om Emoji](https://unicode.org/faq/emoji_dingbats.html) bemerker > «Ordet emoji kommer fra det japanske [絵](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E7%B5%B5) (e ≅ bilde) + [文字](http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%E6%96%87) (moji ≅ skrevet tegn).» Lesere som er interessert i bakgrunnen og den historiske utviklingen til emoji kan ha interesse av denne [Unicode-introduksjonen](https://unicode.org/reports/tr51/#Introduction) eller artikkelen [I second that emoji: The standards, structures, and social production of emoji](https://firstmonday.org/ojs/index.php/fm/article/view/9381). Det var ikke før i 2010, med utgivelsen av [versjon 6.0 av Unicode-standarden](https://www.unicode.org/versions/Unicode6.0.0/), at mange emoji formelt ble anerkjent som *tegn* i sin egen rett. Unicode 13.0 kodet [3304 tegn som emoji](https://www.unicode.org/L2/L2020/20114r-family-emoji-explor.pdf) (se side 2 i det dokumentet), mens Unicode 13.1 [lister 3521 emoji](https://unicode.org/emoji/charts/emoji-counts.html). ### Emoji lever på et høyere plan Unicode tildelte mange emoji-tegn kodepunkter utenfor det grunnleggende flerspråklige planet (BMP), kodet [i Plan 1](https://en.wikibooks.org/wiki/Unicode/Character_reference/1F000-1FFFF) med kodepunkter i området 1F000–1FFFF — noe som har en viktig konsekvens for alle som ønsker å *kopiere og lime inn* emoji-tegn i Overleaf-redigererne (Code Editor eller Visual Editor). Overleafs tekstredigerere kan bare håndtere tegn innenfor det grunnleggende flerspråklige planet, selv om vi håper fremtidige oppgraderinger vil introdusere støtte for tegn utenfor BMP. Merk at denne begrensningen bare påvirker ikke-BMP-tegn i tekst som limes inn i filer som skal redigeres via Overleaf-redigererne. Det finnes andre måter å få tilgang til emoji-tegn på: * Bruke de primitive kommandoene `\char"` eller `\Uchar"` (se [denne delen](#optional-detail-luatexluahbtex-char-vs-uchar) av artikkelen). * Bruke inndata-tekstfiler som inneholder emoji-tegn i UTF-8-format. * Bruke LaTeX-kommandoer (makroer) som setter inn emoji-tegn. #### Å lime inn emoji og andre tegn utenfor BMP i Overleaf Hvis du limer inn et emoji-tegn, for eksempel 😀, i Overleaf Code Editor, vil det for øyeblikket bli konvertert til tegnene ��. ![Feil på grunn av kopier + lim inn av tegn utenfor BMP i Overleaf-redigererne](/files/dbea85a0878cc47c54bf4fce847189318844120e) Tegnet � har Unicode-kodepunkt FFFD og dets offisielle navn er REPLACEMENT CHARACTER og brukes til å «erstatte et ukjent, uidentifisert eller urepresenterbart tegn»[erstatte et ukjent, uidentifisert eller urepresenterbart tegn](https://en.wikipedia.org/wiki/Specials_\(Unicode_block\))». ### Bruke Unicode-kodepunkter (U+) i LuaLaTeX Unicode-dokumentasjonen representerer kodepunktverdier ved hjelp av notasjonen `U+`—som `U+1F600`, hvor `1F600` er `` av Unicode-kodepunktet for 😀-emoji-tegnet. For å bruke disse kodepunktverdiene i LuaLaTeX, sletter du `U+` og skriver `\char"` eller `\Uchar"`. `"` anførselstegnet forteller en TeX-motor at tallet som oppgis er spesifisert i heksadesimal. For eksempel, for å bruke 😀-emoji, ville du skrive `\char"1F600` eller `\Uchar"1F600`—ved å bruke en font som kan sette det. Et minimalt LuaLaTeX-eksempel som bruker `\char` og `\Uchar` for å sette 😀-emoji-tegnet kan være: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz]{NotoColorEmoji.ttf} %Bruk \emojifont i en gruppe for å holde virkningene lokale {\emojifont \Uchar"1F600 \char"1F600} \end{document} ``` [Åpne dette LuaLaTeX-eksempelet 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) **(valgfri detalj) LuaTeX/LuaHBTeX: \char kontra \Uchar** I tillegg til den konvensjonelle `\char` -kommandoen for å sette en bestemt ``, ved bruk av gjeldende font, tilbyr LuaTeX-, LuaHBTeX- og XeTeX-motorene også `\Uchar` -kommandoen. Fra et brukerperspektiv ser resultatet likt ut, men det er en subtil forskjell i hvordan disse kommandoene fungerer, som vi bemerker nedenfor. `\char` og `\Uchar` Fra et brukerperspektiv ser resultatene like ut, men det er en subtil forskjell i hvordan disse kommandoene fungerer, som vi bemerker nedenfor. **Den viktigste forskjellen: utvidelse** `\Uchar` er en såkalt [utvidbar kommando](/latex/no/dybdeartikler/22-how-does-expandafter-work-the-meaning-of-expansion.md#expansion-a-general-term-for-a-set-of-operations) mens `\char` ikke er utvidbar. Når en `\char` eller `\Uchar` kommando blir «utført» — dvs. at kommandoen ikke blir lagret som en del av en makro eller annen tokenliste — skjer følgende handlinger inne i TeX-motoren: * **`\char`** instruerer TeX-motoren til umiddelbart å sette inn et tegntoken som representerer ``, i det innholdet den for øyeblikket setter. * I motsetning til dette, **`\Uchar`** har to distinkte behandlingstrinn: 1. Den `\Uchar` kommandoen *ekspandert*blir `` og [tegn-token](/latex/no/dybdeartikler/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md#tex-tokens-101-28and-notions-of-expansion29) blir konvertert til en midlertidig tokenliste som inneholder ett enkelt ``. 2. som representerer *Denne ett-tegns tokenlisten er nå* gjort tilgjengelig `\char` kommandoen. **for TeX-motoren som kilden til neste inndata. I praksis «flytter» TeX-motoren midlertidig blikket sitt for å bruke den enkelt-token-listen som plasseringen for neste inndataelement (token). Som standard går TeX-motoren ganske enkelt tilbake for å lese (mate inn) det tokenet og sette det tilsvarende tegnet, og gjenskaper dermed oppførselen til**Likevel `` , fordi det *lagret* ikke ble satt umiddelbart, men midlertidig I praksis, `\char` sier «sett dette `` nå», mens `\Uchar` har en form for «utsatt handling» ved å opprette et lagret tegntoken og gjøre det tilgjengelig som neste inndataelement (et token). Det tokenet kan enten brukes (absorberes) av TeX-kommandoer og makroer eller leses inn på nytt av TeX-motoren og settes. ### Unicode (koding) er ikke hele historien Muligheten til å bruke emoji-tegn i Unicode-kodet tekst er bare en del av suksesshistorien til emoji. Økningen i bruk av emoji ble også muliggjort av utviklinger innen [OpenType-fonteknologi](https://learn.microsoft.com/en-us/typography/opentype/)—fonter hvis glyfdata (tegndesign) kan inneholde [fargedata](https://learn.microsoft.com/en-us/typography/opentype/spec/colr): såkalte [OpenType-fargefonter](#opentype-color-fonts). Foruten egnede fonter krever bruk av fargeemoji også flere programvarekomponenter hvis oppgaver omfatter: * forbehandling («[forming](#the-concept-of-text-shaping)») av Unicode-kodet tekst, *klargjøring* av den for visning med en bestemt font; * *gjengivelse og visning* av en fonts fargerike emoji *glyfer* på skjermen til en enhet. #### Glyf vs. tegn: er de ikke det samme? Begrepene «glyf» og «tegn» brukes ofte som om de var utskiftbare — som om de refererte til det samme grunnleggende konseptet — men det er en subtil, men viktig, forskjell i betydningen deres. Unicode [definerer begrepet «tegn»](http://www.unicode.org/glossary/#character) som: > «Den minste komponenten i skriftspråket som har semantisk verdi; refererer til den abstrakte betydningen og/eller formen, snarere enn en spesifikk form… » I motsetning til dette er en «glyf» en *spesifikk* *form* (design) for den *visuelle representasjonen* av et bestemt *tegnet*. Problemet med tegn kontra glyf blir lett observert når tekst med emoji sees på ulike programvaresystemer/plattformer, som når du leser samme tekst på iOS- eller Android-baserte mobiltelefoner eller en Windows-stasjonær datamaskin. Uansett hvilken enhet eller plattform som brukes, vil den underliggende teksten (sekvensen av tegn) inneholde de samme Unicode-kodede *emoji* *tegn*. Det er enhets-spesifikke egenskaper involvert i *forbehandlingen* av denne teksten, deretter *gjengivelsen* og *visnings* av resultatene, kanskje ved bruk av enhetsspesifikke fonter, som gir forskjellige glyfer (tegndesign) for å representere de samme emoji-tegnene. Unicode sin [Full emoji-liste](https://unicode.org/emoji/charts/full-emoji-list.html) gir eksempelbilder som representerer hvert Unicode-emoji-tegn — og viser de ulike glyfene som brukes av forskjellige teknologileverandører. Ikke bare tar fontdesignere i bruk sine egne særegne design (glyfer) for å representere emoji-tegn, men enkeltfonter varierer også i antallet emoji-tegn de støtter (har glyfer for), og kan ha eller ikke ha de mer avanserte funksjonene for emoji-tekstbehandling som er inkludert i Unicode-emoji-spesifikasjonene. Forestillingene og konseptene om tegn, deres semantikk og koding, danner grunnlaget for Unicode-verdenen: den handler om tegn. Design og visuell representasjon av individuelle tegn, som glyfer, hører til fontteknologier og fontdesignhåndverket. #### Unicode-emoji: mye mer enn tekstkoding Unicode sin kjerneoppgave er å tilby en global kodingsstandard som definerer hvilken heltallsverdi, kalt et *kodepunkt,* som skal brukes til å representere hvert tegn, inkludert emoji, i en strøm av Unicode-kodet tekst. Unicode-spesifikasjonen for emoji definerer også *behandlingsatferd* for visse *sekvenser* av emoji-tegn som forekommer i en strøm av Unicode-kodet tekst. Definerte sekvenser av emoji-tegn kan «slås sammen» gjennom en prosess kalt [tekstforming](#the-concept-of-text-shaping) for å produsere en enkelt resulterende («sammensatt») emoji-glyf — den ene glyfen ville bli brukt av enhetens operativsystem til å representere den opprinnelige tegnsekvensen som finnes i teksten. Unicode sitt tekniske rapport om [Unicode Emoji](https://unicode.org/reports/tr51/) dokumenterer det rike settet med funksjoner som er tilgjengelig for programvare som ønsker å tilby Unicode-kompatibel behandling av emoji-tegn. Som et eksempel definerer (koder) Unicode tegn kalt [emoji-modifikatorer](http://www.unicode.org/reports/tr51/#Emoji_Modifiers_Table) som kan brukes til å generere *variasjoner* av «basis»-emoji-tegn, som variasjoner i [hudtone basert på Fitzpatrick-skalaen](http://www.unicode.org/reports/tr51/#Diversity). Merk at settet av basis-emoji-tegn og de gjeldende modifikatorene er definert som en del av den samlede [Unicode-emoji-standarden](http://www.unicode.org/reports/tr51). Unicode-siden [Emoji Sequences](http://unicode.org/emoji/charts/emoji-sequences.html) gir et diagram over sekvensene som for tiden er spesifisert av Unicode. Plasser musepekeren over et hvilket som helst av emoji-glyfbildene for å se en liten verktøytips-popup som forteller deg den underliggende Unicode-emoji-tegnsekvensen som produserer den glyfen: ![EmojiSequenceChart.png](/files/b2f3f1fd10677cc846cc87ba224eb35b41abb7ea) For eksempel er emoji-glyfen: ![HandMediumSkinTone.png](/files/ce33095fc4ca179d4cba6ad0ffb8cb1ab6d9f1b4) oppført i [delen for modifikatorkombinasjoner](http://unicode.org/emoji/charts/emoji-sequences.html#modifier_sequences) og produseres av den to-tegns sekvensen U+1F44B U+1F3FD. Disse komponenttegnene er: U+1F44B:![UnicodeWavingHandDefault.png](/files/38d1d75ba8465b99621bd870b97149a9c6188a5f) (VINKENDE HÅND) U+1F3FD:![FitzPatrick3.png](/files/973967e7b8912bd7db0022778c475091d3df6f33) (EMOJI-MODIFIKATOR FITZPATRICK TYPE-4) **Bruk av hudtonemodifikatorer i LuaHBTeX** Det følgende eksemplet bruker LuaHBTeX til å demonstrere bruken av emoji-modifikatorer: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont[Renderer=HarfBuzz,SizeFeatures={Size=20}]{NotoColorEmoji.ttf} Isolert vinkende hånd: {\emojifont\Uchar"1F44B}\par Isolert modifikator: {\emojifont\Uchar"1F3FD}\par Kombinert resultat: {\emojifont\Uchar"1F44B\Uchar"1F3FD} \end{document} ``` [Åpne dette LuaLaTeX-eksempelet med emoji-modifikatorer 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) Dette eksemplet gir følgende resultat: ![ModifiersInLuaHBTeX.png](/files/93521abf27f53dbd89c7a161d0f3a1cacb901cd9) #### UTF-8: rollen i lagring av Unicode-tekst All tekst eller kode du skriver eller limer inn i Overleafs Code Editor (eller Visual Editor) vil bli lagret i UTF-8-format, så vi skal kort gjennomgå hva UTF-8 faktisk betyr. UTF står for Unicode Transformation Format, og UTF-8s rolle i lagring eller overføring av Unicode-kodet tekst angis av uttrykket «Transformation *Format*». Unicode sine kodepunktverdier spenner fra 0 til maksimalt 1 114 111, så det er umulig å representere alle Unicode-tegnverdier ved hjelp av én enkelt 8-bits byte, som bare kan lagre opptil 256 ulike verdier: 0 til 255. Det er imidlertid mulig å representere ethvert Unicode-kodepunkt heltall ved hjelp av en *sammenhengende sekvens* av bytestørrelse verdier — det er prinsippet bak UTF-8. UFT-8 gir en «oppskrift» for å *transformere* (dvs. å «kode» eller «konvertere») en Unicode-heltalls-kodepunktverdi til en unik sekvens av 1 til 4 påfølgende bytestørrelse heltall: antallet påfølgende byte som kreves, avhenger av verdien til kodepunktet. Følgelig kan du lese om UTF-8 som lagring av Unicode-tegn som *flerbyte-sekvenser* fordi et enkelt Unicode-tegn (kodepunktheltall) er representert i UTF-8 som en sekvens av 1 til 4 påfølgende byte. Naturligvis kan tekst lagret i UTF-8 konverteres tilbake til den opprinnelige sekvensen av heltallsverdier for Unicode-kodepunkter — det er det XeTeX eller LuaTeX/LuaHBTeX må gjøre når de leser en LaTeX-inndatafil lagret i UTF-8-format. Disse TeX-motorene må kjenne de innkommende Unicode-kodepunkt- (tegn-)verdiene før de kan sette teksten i tekst. Merk at pdfTeX ikke har innebygd støtte for UTF-8-dekoding, så den må stole på TeX-makroer for å behandle (dekode) inndataformatert tekst i UTF-8. **Noen UTF-8-eksempler** * Det arabiske tegnet ش («sheen») har Unicode-kodepunkt 0634 i heksadesimal (grunntall 16) eller 1588 i desimal (grunntall 10). I UTF-8 er ش representert som 2 (heksadesimale) verdier D8 og B4, så tegnet ش ville bli lagret som de to påfølgende bytene D8B4 i UTF-8-kodet tekst. * Emoji-tegnet 😀 har Unicode-kodepunkt 1F600 i heksadesimal (grunntall 16) eller 128512 i desimal (grunntall 10). I UTF-8 er 😀 representert som 4 (heksadesimale) verdier F0, 9F, 98 og 80, så tegnet 😀 ville bli lagret som de 4 påfølgende bytene F09F9880 i en UTF-8-tekstfil. #### Spesialtegn brukt i Unicode-basert emoji-tekstbehandling Ikke alle tegn som er kodet i Unicode er ment for visuell presentasjon via glyfene i en font: noen kodede tegn er utpekt som *ikke-utskrivbare tegn* hvis formål er å hjelpe spesialiserte tekstbehandlingsfunksjoner (i støttende programvare). Ulike programvareapplikasjoner gir varierende nivåer av støtte for de ikke-utskrivbare tegnene som er kodet inn i Unicode, så resultatet vil avhenge av programvaremiljøet — applikasjonene og fontene — som brukes. **To ikke-utskrivbare tegn det er nyttig å kjenne til** * **Nullbredde-sammenføyer (ZWJ)**, kodepunkt 200D (heksadesimal), er, som navnet tilsier, utformet for å utløse «sammenføyningsatferden» til inntastede tegn — men bare hvis disse inntastede tegnene *har* en definert sammenføyningsatferd. * **Nullbredde-ikke-sammenføyer (ZWNJ)**, kodepunkt 200C (heksadesimal), er utformet for å *forhindre* den «sammenføyningsatferden» som inntastede tegn ellers kunne vise. Du kan for eksempel bruke ZWNJ for å forhindre sammenføyningsatferden til påfølgende arabiske tegn som normalt ville blitt behandlet (formet) til sine sammenføyningsformer. Unicode har publisert en liste over [anbefalte emoji-ZWJ-sekvenser](https://unicode.org/emoji/charts/emoji-zwj-sequences.html) som bruker en U+200D ZERO WIDTH JOINER (ZWJ) for å kombinere emoji-tegnsekvenser til en enkelt sammensatt emoji-glyf — hvis den er tilgjengelig i fonten(e) som brukes. **Eksempel på bruk av nullbredde-ikke-sammenføyer** Det følgende minimale kodefragmentet bruker Scheherazade OpenType-fonten, inkludert i TeX Live, til å definere en LaTeX-font kalt `\arabicfont` som vi kan bruke til å sette noe arabisk tekst. Linjen ```latex {\arabicfont Ikke-sammenføyning:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} ``` bruker et nullbredde-ikke-sammenføyer-tegn, via `\Uchar"200C`, for å forhindre den normale sammenføyningsatferden til de to arabiske bokstavene ل (lam) og ا (alef). Merk bruken av `\textdir TRT` for å sette tekstretningen som høyre-til-venstre: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\arabicfont[Script=Arabic,Renderer=Harfbuzz,SizeFeatures={Size=40}]{Scheherazade} {\arabicfont Sammenføyning:\textdir TRT\Uchar"0644\Uchar"0627}\par {\arabicfont Ikke-sammenføyning:\textdir TRT\Uchar"0644\Uchar"200C\Uchar"0627} \end{document} ``` [Åpne dette LuaLaTeX-eksempelet 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) Dette eksemplet gir følgende resultat: ![NonJoiner.png](/files/25664111957a44356bc490677b248fabc13240f2) ## Konseptet «tekstforming» La oss starte med et visuelt eksempel ved hjelp av en urdu-oversettelse av ordet «educational». Teksten i den urdu-oversettelsen kan skrives på et tastatur eller en berøringsskjermenhet, og vil bli laget som en enkel lineær sekvens av Unicode-arabiske tegn. Men når den teksten settes i tekst, eller vises på skjermen til en enhet i [Nastaliq-stilen](https://en.wikipedia.org/wiki/Nastaliq), blir resultatet en kompleks todimensjonal ordning av glyfer. Ved å bruke vårt urdu-eksempel sammenligner den følgende grafikken den lineære inndatateksten av Unicode-arabisk *tegn* med utdataene satt i Nastaliq-stil, som består av en todimensjonal ordning av *glyfer* som finnes i den (gratis) fonten [Awami Nastaliq](https://software.sil.org/awami/download/): ![](/files/3f90195aa06030a69e31525864873c745b12a27c) Prosessen med å «oversette» inntastede tegn til et sett med korrekt plasserte utdata-glyfer kalles *tekstforming*og er en avgjørende komponent i behandling av tekst før den vises eller settes i tekst. Eksemplet vårt brukte tekst på urdu (arabisk skrift) fordi resultatet av forming er tydelig synlig, i motsetning til språk som bruker latinsk skrift, slik som engelsk der forming er langt mindre fremtredende — for eksempel produksjon av enkle ligaturer. Tekstforming er essensiell når man bruker skriftsystemer (skrivesystemer) som [Arabisk](https://en.wikipedia.org/wiki/Arabic), [Hebraisk](https://en.wikipedia.org/wiki/Hebrew_language), [Devanagari](https://en.wikipedia.org/wiki/Devanagari) eller [Malayalam](https://en.wikipedia.org/wiki/Malayalam), bare fire eksempler på såkalte *komplekse skriftsystemer*. For å sikre korrekt presentasjon av tekst i disse skriftsystemene, og språkene som bruker dem, må formingsprosessen nøye ta hensyn til alle formingsregler og nyanser som finnes i den aktuelle kombinasjonen av skriftsystem og språk. For eksempel krever noen språk flere inndata-tegn for å generere en bestemt utdata-glyf, eller det kan være komplekse krav til nøye plassering av diakritiske tegn og omorganisering mellom glyfer for å sikre at individuelle glyfer er plassert korrekt (i forhold til hverandre). Generelt krever forming av en tekstbit flere opplysninger: * Skriftsystemet eller *skriftsystemet* språket teksten er skrevet i. * Den spesifikke *språket* som brukes. Enkelte skriftsystemer kan brukes for flere språk, og hver skriftsystem–språk-kombinasjon har sine egne nyanser/subtiliteter i formingen. * Skrive *retningen* for teksten – for eksempel høyre-til-venstre eller venstre-til-høyre. * Et *font* som gir glyfene som trengs for å representere den formede teksten og eventuelt inneholder ekstra «formingsregler» som styrer tekstformingsprosessen. Kravene til tekstforming, særlig for komplekse skriftsystemer og de tilhørende språkene, kan være ekstremt detaljerte og nyanserte, noe som viser behovet for spesialisert programvare som kan anvende potensielt svært komplekse regler for tekstforming. Ikke overraskende finnes slik programvare, og den omtales som en *tekstformingsmotor*; den vi skal diskutere, kalles [Harfbuzz](https://en.wikipedia.org/wiki/HarfBuzz), og dokumentasjonen er verdt å lese – for eksempel [Hvorfor trenger jeg en formingsmotor?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html). **Videre lesning om tekstforming** Disse korte introduksjonene anbefales sterkt: * [Hva er tekstforming?](https://harfbuzz.github.io/what-is-harfbuzz.html#what-is-text-shaping) * [Hvorfor trenger jeg en formingsmotor?](https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html) **Teknisk notat: flere formings-teknologier (modeller)** Tekstformingsmotoren HarfBuzz støtter flere «formings-teknologier» som skiller seg i hvordan de implementerer formingsprosessen – hver implementasjon omtales som en *former*, blant annet i `luaotfload` dokumentasjonen. Hovedfokuset i denne artikkelen er OpenType-forming, men en alternativ teknologi som er gratis å bruke, er [Graphite](https://scripts.sil.org/cms/scripts/page.php?site_id=projects\&item_id=graphite_aboutOT), utviklet av [SIL International](https://www.sil.org/). En annen formingsmodell som støttes av HarfBuzz, er [Apple Advanced Typography (AAT)](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6AATIntro.html)– skrifttyper som støtter AAT brukes vanligvis på Apples teknologiplattformer. **Eksempel med Graphite-formeren** Det følgende eksemplet setter noe urdu-tekst med en font kalt [Awami Nastaliq](https://software.sil.org/awami/download/), som støtter Graphite-forming og er tilgjengelig på Overleaf. Awami Nastaliq er laget av [SIL International](https://www.sil.org/), organisasjonen som er ansvarlig for utviklingen av Graphite-teknologien. Det følgende eksemplet demonstrerer den avanserte formingsevnen til Graphite-baserte fonter – legg merke til hvordan `luaotfload` fontdeklarasjonen velger Graphite-forming ved hjelp av `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 % Utdanning \pardir TRT\textdir TRT \urdutest تعلیمی \end{document} ``` [Åpne dette eksemplet 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) Dette eksemplet gir følgende resultat: ![](/files/fecc20fef5fee4ec7648fdfc89f58af0470152a4) #### Emojier og tekstforming Tekstforming har blitt introdusert ved hjelp av eksempler fra et språk med komplekst skriftsystem, urdu. Det kan imidlertid komme som en overraskelse at gjengivelse av de riktige emojiglyfene krever at tekstforming anvendes på Unicode-tekst som inneholder sekvenser av emojitegn –[som påpekt av hovedutvikleren av HarfBuzz](https://github.com/harfbuzz/harfbuzz/issues/2428#issuecomment-639108677): > ... å forme emojier med HarfBuzz er helt innenfor og faktisk nødvendig for å få familieemoji, hudfarge osv. Vi skal se på eksempler på dette. ### Ansvarsdeling: tekstformingsmotor + OpenType-fonter I praksis er tekstforming en «felles operasjon», eller arbeidsdeling, mellom logikken og reglene innebygd i tekstformingsmotoren og ekstra formingsregler og data innebygd i fonten(e) som brukes – fra nå av dekker vi OpenType-basert forming *kun*. For å utføre forming får tekstformingsmotoren typisk tilført litt Unicode-tekst, et angitt skriftsystem og språk, eventuelt en skriveretning, og, aller viktigst, en OpenType-font som skal brukes under formingsprosessen – fonten vil levere resultatet: et sett glyfer og posisjonsdata. Hvis det ønskes, kan formingsmotoren anvende ekstra regler ([OpenType-funksjoner](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features)) som finnes i OpenType-fonten som brukes – hvilke regler som skal anvendes, kan vanligvis velges av brukeren fra listen over funksjoner som fonten støtter. Resultatet av formingsprosessen er en *liste over glyfer* som finnes i OpenType-fonten, sammen med *mellomglyf-* posisjonsdata. Disse posisjonsdataene gjelder *relativ plassering av de formede glyfene*; det refererer ikke til absolutt plassering på den ferdig satte siden eller i annet medium/innhold, som en nettside, en tweet osv. Gjengivelsesprogramvaren (settemotor, nettleser osv.) bruker mellomglyf-posisjonsinformasjonen for å sikre at glyfene er riktig plassert i forhold til hverandre etter at de er satt sammen og innlemmet i sluttresultatet. #### Hva er en liste over glyfer? Internt tildeles hver glyf i en OpenType-font en numerisk identifikator, en heltallsverdi kalt glyfindeksen – også kalt glyfidentifikatoren eller GID. Etter å ha fullført formingsoppgaven sin vil tekstformingsmotoren returnere resultatene som en *liste over glyfidentifikatorer* pluss *posisjonsdata* for disse glyfene. Enkelte glyfer i OpenType-fonter tildeles indekser (identifikatorer) av fontens skaper, noe som gjør det til en svært fontspesifikk og vilkårlig verdi – den kan også variere mellom versjoner av en bestemt font. Du bør aldri anta at den samme GID-verdien vil gjelde for «like» glyfer i ulike fonter; det gjør den nesten helt sikkert ikke. Hvis du har en liste over glyfidentifikatorer som er levert av en formingsmotor, kan du bare bruke dem til å få tilgang til glyfer i fonten de ble hentet fra. #### Hva er OpenType-fonter? Nettet er *fullt av* forklaringer og detaljer om OpenType-fonter, så vi begrenser oss til en kort beskrivelse. Den [OpenType-spesifikasjonen](https://docs.microsoft.com/en-us/typography/opentype/spec/) er et komplekst dokument utformet for utviklere, men i hovedsak definerer det et filformat, eller en beholder, for fontdata. En OpenType-font inneholder data som beskriver glyf-formene, sammen med informasjon om hvilke skriftsystem(er) og språk(er) som støttes, metadata om fonten og ulike «tabeller» som definerer [typografiske funksjoner](https://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features) som støttes av fonten. En tekstformingsmotor kan vanligvis instrueres til selektivt å anvende (bruke) fontens funksjoner under formingsprosessen, og på den måten bruke bestemte typografiske effekter («regler») som velger riktig sett glyfer som finnes i fonten. Fonten som velges må støtte, og levere glyfene for, de funksjonene tekstformingsmotoren blir bedt om å bruke. #### Kodede og ukodede «glyfer» OpenType-fonter inkluderer en datatabell kalt [cmap](https://docs.microsoft.com/en-us/typography/opentype/spec/cmap) (Character to Glyph Index Mapping) som mapper mengden Unicode-tegn som støttes av fonten, til den tilsvarende glyfindeksen i den fonten. Følgende video gir et kort innblikk i cmap-tabellen i en font kalt `lmmono10-regiular.otf` (inkludert i TeX Live). {% embed url="" %} Fonter inneholder imidlertid vanligvis mange glyfer som ikke representerer et bestemt Unicode-tegn og som ikke er inkludert i cmap-tabellen. Derfor kan mengden glyfer i en OpenType-font deles inn i to hovedmengder: * kodede glyfer som representerer Unicode-tegn; * ukodede glyfer som ikke representerer Unicode-tegn. Kodede glyfer kan nås ved å inkludere det passende Unicode-tegnet i teksten – men hva med ukodede glyfer, hvordan brukes/tilgås de? Disse glyfene brukes vanligvis til å levere resultatet av tekstformingsoperasjoner, inkludert anvendelse av fontfunksjoner for å produsere bestemte visuelle/typografiske effekter. ### OpenType-fargefonter Emojitegn forventes å vises/gjengis i full farge – svart-hvite emojier gir ikke helt den «fulle emojiopplevelsen». Men da Unicode først kodet emojier, hadde [OpenType-fontspesifikasjonen](https://docs.microsoft.com/en-us/typography/opentype/spec/) den ikke noen egnet mekanisme for å bygge inn *colorful*-glyfdata i OpenType-fonter. Dette «hullet» i OpenType fikk ledende teknologi-/plattformleverandører til å lete etter løsninger, og det påfølgende «kappløpet» resulterte i [ulike forslag om å utvide OpenType](https://www.fontlab.com/news/color-font-format-proposals/) for å støtte OpenType-fargefonter – ikke bare for å vise fargeemojitegn (glyfer), men for å gjengi enhver glyf i farge. #### Fire varianter av OpenType-fargefont [Adobe, Microsoft, Google og Apple leverte hver sine forslag](https://www.fontlab.com/news/color-font-format-proposals/) for å utvide OpenType slik at det støtter fullfarge OpenType-fonter, og til slutt ble fire forslag vedtatt og inkludert i den formelle OpenType-spesifikasjonen. For enkelhets skyld kan vi grovt gruppere disse fire variantene i vektorbaserte og rasterbaserte – men, som vist i denne [GitHub-repositoriet](https://github.com/simoncozens/test-fonts), er OpenType-spesifikasjonen fleksibel nok til å støtte OpenType-fargefontfiler som kombinerer disse fire grunnteknologiene. * **Vektorbaserte OpenType-fonter:** * **Microsoft**: glyfformene beskrives ved hjelp av en form for lagdelte fargevektorer ([COLR](https://docs.microsoft.com/en-us/typography/opentype/spec/colr) og [CPAL](https://docs.microsoft.com/en-us/typography/opentype/spec/cpal) tabeller). * [**Adobe og Mozilla**](https://www.w3.org/2013/10/SVG_in_OpenType/) ([SVG-tabellen](https://docs.microsoft.com/en-us/typography/opentype/spec/svg)): glyfformer tegnes ved hjelp av SVG, som støtter glyfer konstruert fra vektorer *og rasterbilder*. Se også [Adobes brukerveiledning om SVG-fonter](https://helpx.adobe.com/fonts/user-guide.html/fonts/using/ot-svg-color-fonts.ug.html). * **Rasterbaserte OpenType-fonter:** * **Google**: glyfer representeres av farge-PNG-bilder innebygd i fonten ([CBDT](https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt) og [CBLC](https://docs.microsoft.com/en-us/typography/opentype/spec/cblc) tabeller). * **Apple**: glyfer representeres også av fargebilder innebygd i fonten. I tillegg til PNG støtter Apples mekanisme ([sbix-tabellen](https://docs.microsoft.com/en-us/typography/opentype/spec/colr)) også JPEG og TIFF. Som en konsekvens må operativsystemer og applikasjonsprogramvare som støtter OpenType-fargefonter, håndtere dagens landskap med blandet teknologi. Videre bør du være oppmerksom på at enkelte OpenType-fargefonter – og *versjoner* av samme font – vil: * ha ulik dekning av hele settet med [Unicode-emojitegn](https://unicode.org/emoji/charts/emoji-list.html)– dvs. hvor mange emojitegn fonten har glyfer for; * bruke ulike glyfdesign for å representere enkeltstående emojitegn; * variere i funksjonene de tilbyr for å støtte mer avanserte bruksområder av Unicode-standardene, for eksempel [emoji-modifikatorer](https://unicode.org/reports/tr51/#Emoji_Modifiers_Table), og andre emoji-tekstbehandlingsfunksjoner beskrevet i [Unicode Technical Standard #51: Unicode Emoji](https://unicode.org/reports/tr51/). #### Oppstyret rundt HarfBuzz Vi har vært inne på behovet for en *tekstformingsmotor*: programvare som tar inn Unicode-tekst, skrevet med en bestemt kombinasjon av skriftsystem og språk, og som ved hjelp av en bestemt font former teksten til en sekvens av glyfer, sammen med posisjonsdata, som kan brukes til å sette originalteksten. [HarfBuzz](https://harfbuzz.github.io/) er en slik tekstformingsmotor: den er [et åpen kildekode-bibliotek](https://github.com/harfbuzz/harfbuzz) og resultatet av mer enn et tiår med forskning og utvikling – og utvikles og tas fremdeles aktivt i bruk som en del av mange programvareprodukter. HarfBuzz i seg selv utfører ikke «setting», men tilbyr «tekstformingstjenester» til programvare som velger å integrere det, inkludert XeTeX, LuaHBTeX, [Adobe Photoshop og Adobe InDesign](https://en.wikipedia.org/wiki/HarfBuzz). Ved å integrere HarfBuzz kan TeX-motorer dra nytte av de avanserte tekstformingsmulighetene for å gi svært sofistikert flerspråklig setting, særlig for komplekse skriftsystemer som arabisk, hebraisk, devanagari og mange andre. Merk også at HarfBuzz brukes til å behandle og forme Unicode-emojitegn, noe vi skal utforske nærmere. Den følgende grafikken oppsummerer rollen HarfBuzz spiller når det er integrert med programvare som XeTeX eller LuaHBTeX, ved setting av tekst i et komplekst skriftsystem som arabisk: ![En oversikt over arabisk tekstforming med HarfBuzz](/files/190dee4179e9b4bc65c929940330d34653964d7e) **Utforsk HarfBuzz** Alle som vil lære mer om HarfBuzz og OpenType-formingstjenestene det tilbyr til XeTeX og LuaHBTeX, kan [laste ned en binær distribusjon av HarfBuzz](https://github.com/harfbuzz/harfbuzz/releases) som inneholder HarfBuzz-biblioteket (for programmerere) og kommandolinjeverktøy `hb-view` og `hb-shape`. **Eksempel: hvordan bruke hb-view** Opprett en ny fil i din foretrukne tekstredigerer med UTF-8-støtte og kopier/lim inn de følgende seks emojitegnene 👋👋🏻👋🏼👋🏽👋🏾👋🏿 i den tekstfilen, og lagre den deretter i UTF-8-format som en fil kalt for eksempel `emoji.txt`. Merk at teksteditoren din kan vise (reserve) svart-hvite versjoner av emojiene fordi den ikke er i stand til (programmert til) å gjengi fargeglyfer. Når disse 6 emojiene er lagret, bør filen `emoji.txt` inneholde UTF-8-data for den følgende sekvensen av Unicode-emojitegn – vi har skilt emojimodifikatorene med komma bare for *enklere lesing*: * `1F44B` for å produsere 👋 * `1F44B`, `1F3FB` for å produsere 👋🏻 * `1F44B`, `1F3FC` for å produsere 👋🏼 * `1F44B`, `1F3FD` for å produsere 👋🏽 * `1F44B`, `1F3FE` for å produsere 👋🏾 * `1F44B`, `1F3FF` for å produsere 👋🏿 Det bør være totalt **11** Unicode-tegn, som hver genererer 4 bytes med UTF-8-data, så den resulterende `emoji.txt` filen bør være 44 bytes lang, eksklusive eventuelle linjesluttmarkører brukt på slutten av linjen som inneholder emojien. Den `hb-view` verktøyet kan bruke filen `emoji.txt`, sammen med en passende OpenType-fargefont etter eget valg, for eksempel `NotoColorEmoji.ttf`, for å generere en SVG-fil av HarfBuzz’ formede utdata. Det følgende kommandolinjeeksemplet, som må **skrives på én linje** i terminalen din, vil generere 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 ``` Ved vellykket kjøring vil filen `emoji.svg`, generert av `hb-view`, kunne åpnes i Inkscape og bør se omtrent slik ut: ![Hbvieemoji.png](/files/7d0d36c17c76898990c7f3b51e67b366c2791903) `hb-view` kan brukes til å utforske HarfBuzz-forming for enhver passende Unicode-tekstfil og OpenType-font – det er absolutt ikke begrenset til bruk med emojier! Skriv ```latex hb-view --help-all ``` for å se det store utvalget av kommandolinjevalg for dette kraftige og nyttige verktøyet. God forming! ## Tekstforming og TeX-motorer Her skal vi gjennomgå tekstformingsmulighetene i XeTeX og LuaTeX-familien av TeX-motorer. ### XeTeX XeTeX ble utviklet tidlig på 2000-tallet og var en pioner for flere innovasjoner innen TeX-basert setting, særlig *innebygd* støtte for: * lesing av Unicode-tekst i UTF-8-format; * bruk av OpenType-fonter; * tekstforming for flerspråklig setting; * OpenType-basert matematisk setting. XeTeXs evne til enkelt og praktisk å sette språk med komplekst skriftsystem skyldes de innebygde tekstformingsmulighetene – opprinnelig basert på den nå avlagte [ICU LayoutEngine](http://userguide.icu-project.org/layoutengine). Takket være arbeidet til Khaled Hosny gikk XeTeX over til å bruke HarfBuzz for tekstforming, som nevnt i en kunngjøring fra [mars 2013](https://tug.org/pipermail/xetex/2013-March/024118.html). For alle som ønsker å sette flerspråklig tekst, omtales XeTeX vanligvis som den foretrukne TeX-motoren – men nå finnes det et annet alternativ, LuaHBTeX, som vi skal utforske. ### LuaTeX og LuaHBTeX Utviklingen av LuaTeX startet rundt 2005, men fulgte en designfilosofi som var ganske annerledes enn XeTeXs, som innlemmet nye funksjoner *direkte i* XeTeX-programvaren. I motsetning til XeTeX valgte LuaTeX-utviklerne å «...tilby et minimalt sett med verktøy og ingen løsninger.» (se [Reference Manual for LuaTeX](https://www.pragma-ade.com/general/manuals/luatex.pdf)). I stedet for å tilby en pakke med ekstra funksjoner *innebygd i* LuaTeX-baserte motorer, blir de interne mekanismene i LuaTeX-motorene åpnet opp slik at utviklere og avanserte brukere kan utnytte det integrerte skriptspråket Lua til å bygge sine egne løsninger. For eksempel kan ikke LuaTeX-motoren, i motsetning til XeTeX, *direkte* bruke OpenType-fonter; i stedet må OpenType-fonter lastes inn og «gjøres klare til bruk» gjennom fontinnlastingsfunksjoner skrevet i Lua-kode. Disse fontinnlastingsfunksjonene omtales som *callback* funksjoner: Lua-kode som LuaTeX vil kalle («utføre») når det kommer en forespørsel om å laste inn en font. I tillegg tilbyr ikke LuaTeX-motoren noen *innebygd* tekstformingsmuligheter – også disse må leveres av ekstern kode som LuaTeX-motoren kan kalle på for å få tekstformingstjenester. Også her står dette i kontrast til XeTeX-motoren, som innlemmet tekstformingsmuligheter i kjernprogramvaren. #### luaotfload: essensielt for å bruke OpenType-fonter i LuaTeX/LuaHBTeX LuaTeXs callback-mekanisme for fontinnlasting gir stor fleksibilitet, men til «prisen» av ekstra programmering. Heldigvis har TeX-miljøet for brukere av LuaLaTeX utviklet en pakke kalt `luaotfload`, som er en del av [den årlige utgaven av TeX Live](https://www.tug.org/texlive/) og er selvfølgelig tilgjengelig for Overleaf-brukere. `luaotfload` er [tilgjengelig på CTAN](https://ctan.org/pkg/luaotfload?lang=en) og har et [utviklingsarkiv på GitHub](https://github.com/latex3/luaotfload) der du kan følge de nyeste utviklingene og [nye utgivelser](https://github.com/latex3/luaotfload/releases). `luaotfload` kan lastes direkte inn i preamblen til et LaTeX-dokument via ```latex \usepackage{luaotfload} ``` Merk at `luaotfload` er navnet på et LaTeX- *pakken*, noe som betyr at det har filnavnet `luaotfload.sty`. Hvis du ønsket å bruke `luaotfload` med plain TeX, kan du gjøre det ved å legge til linjen ```latex \input luaotfload.sty ``` i plain TeX-dokumentet ditt. Vanligvis trenger ikke brukere av LuaLaTeX – dvs. de som setter LaTeX med LuaTeX/LuaHBTeX – å forholde seg direkte til `luaotfload` fordi [`fontspec` pakken](https://ctan.org/pkg/fontspec) vil laste inn `luaotfload` pakken for deg og ta hånd om mange lavnivådetaljer gjennom brukernivå-kommandoer levert av `fontspec` pakken. ### LuaHBTeX: nye alternativer for tekstforming `luaotfload` er et modent og kraftig Lua-bibliotek som sørger for LuaTeXs håndtering av OpenType-fonter – sammen med levering av tekstformingstjenester for en rekke språk og skriftsystemer. Opprinnelig var tekstformingsfunksjonene i `luaotfload` implementert i ren Lua-kode, men utgivelsen av TeX Live 2020 introduserte et nytt hovedstrømsalternativ for tekstforming – en ny LuaTeX-basert motor kalt LuaHBTeX. «HB» i LuaHBTeX står for HarfBuzz – i praksis er LuaHBTeX den opprinnelige LuaTeX-motoren *pluss* med en integrert HarfBuzz-tekstformingsmotor. I tråd med designfilosofien til LuaTeX betyr tilgjengeligheten av HarfBuzz ikke *automatisk* at teksten formes av LuaHBTeX: HarfBuzz er et annet verktøy som kan brukes til å bygge tekstformingsløsninger. LuaHBTeXs integrering av HarfBuzz er [programmerbar via Lua-kode](#introduction-to-the-luahbtex-harfbuzz-api), noe som har gjort det mulig for `luaotfload`s utviklere å legge til HarfBuzz-baserte tekstformingsløsninger. Følgelig, [fra og med versjon 3.1, utgitt 5. november 2019](https://github.com/latex3/luaotfload/releases/tag/v3.1), `luaotfload` ble den forbedret for å dra nytte av HarfBuzz – noe som gjør HarfBuzzs tekstformingsmuligheter lett tilgjengelige for vanlige brukere. Lesere som er interessert i de tekniske detaljene rundt integreringen av HarfBuzz med LuaTeX, kan lese denne [artikkelen av Khaled Hosny](https://www.tug.org/TUGboat/tb40-1/tb124hosny-harfbuzz.pdf). ### luaotfload: to alternativer for tekstforming (når bør HarfBuzz brukes?) Brukere av LuaLaTeX har nå to alternativer for tekstforming: * `luaotfload`s opprinnelige (nodebaserte) implementering av tekstforming, skrevet utelukkende i Lua; * `luaotfload`HarfBuzz-baserte forming – tilgjengelig via Lua-kode som kaller HarfBuzzs tekstformingsfunksjoner. `luaotfload` gir tilgang til disse to formingssystemene via sitt «`modus`»-parameteret – selv om de fleste brukerne vil bruke det tilsvarende `fontspec` “`Renderer`»-alternativet i stedet for direkte å bruke lavnivåfunksjoner i `luaotfload`. Hver av `luaotfload`s tekstformingsløsninger har sine styrker og (nåværende) svakheter, men hvilken bør du bruke, og når? Her er noen punkter å vurdere: * `luaotfload`s egen nodebaserte behandling kan være minnekrevende, særlig for store CJK OpenType-fonter. Å bruke HarfBuzz til forming av CJK-tekst kan gi bedre hastighet og redusert minnebruk. * Bruk HarfBuzz for komplekse skriftsystemer fordi det «...forbedrer gjengivelsen av indiske og arabiske skriftsystemer betydelig og anbefales sterkt for slike skriftsystemer.» (se `luaotfload` manualen). * HarfBuzzs integrering i `luaotfload` er fortsatt relativt ny og under videre utvikling. Da dette ble skrevet (juli 2021), anbefales det å bruke luaotfloads innebygde forming (ved å sette `mode=node`) for hovedfontene i dokumentet, særlig hvis dokumentet ditt bruker det latinske skriftsystemet. Se denne [GitHub-saken](https://github.com/latex3/luaotfload/issues/175#issue-801120377), som oppsummerer problemene og diskusjonene. Hvis du vil eksperimentere, kan du bruke `luaotfload` for å laste inn en fontfil og opprette to LaTeX-fonter: én som bruker HarfBuzz-basert forming og den andre som bruker Lua-basert forming. Overleaf laget et [eksempelprosjekt](#sample-project-arabic-shaping), som demonstrerer dette. * Ikke bruk HarfBuzz til håndtering av matematiske fonter. Som diskutert av utviklere på tex.stackexchange, er HarfBuzz [ikke utformet for å håndtere fonter for matematisk setting](https://tex.stackexchange.com/questions/544881/does-luahbtex-with-harfbuzz-renderer-completely-supports-math-formating) så ikke bruk det til det formålet. **Eksempelprosjekt: arabisk forming** Her er et Overleaf-prosjekt som bruker flere arabiske skrifter av høy kvalitet for å sammenligne `luaotfload`s nodebaserte tekstformingstjenester (`mode=node`) med dem til HarfBuzz (`mode=harf`): * Dette prosjektet inkluderer utdata vist i følgende bilde: ![Sette arabisk tekst](/files/f64c1b8c655928028f73be5f5998f7e90c9da4cd) ### Velge «Renderer» i fontspec Som nevnt i dokumentasjonen [dokumentasjonen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), `fontspec` «...lar brukere av enten XeTeX eller LuaTeX laste inn OpenType-fonter i et LaTeX-dokument». Hvis du bruker LuaTeX- eller LuaHBTeX-motorene, `fontspec` vil laste inn `luaotfload` biblioteket for deg og i tillegg tilby en rekke praktiske kommandoer på brukernivå som reduserer behovet for å forholde seg til `luaotfload`s lavnivåfunksjonalitet. Så hvordan velger du mellom HarfBuzzs forming eller den innebygde formingen som tilbys av `luaotfload`? Svaret finnes i den utmerkede [`fontspec` dokumentasjonen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf), nærmere bestemt del VI: LuaTeX-spesifikke fontfunksjoner. `fontspec` tilbyr en innstilling kalt `Renderer` som kan settes når fonten defineres via `fontspec`. `Renderer` styrer fontens lavnivåbehandling. De to aktuelle alternativene er * `Renderer = Node`: standard«modus» for setting av OpenType-fonter – dette bruker `luaotfload`s tekstformingsfunksjoner implementert utelukkende i Lua. * `Renderer = Harfbuzz`: denne «modusen» definerer/laster inn fonten for bruk med HarfBuzz-tekstformingsmotoren. `luaotfload` bruker LuaHBTeXs API til å kalle funksjoner i HarfBuzz. For mer informasjon, se [`fontspec` dokumentasjonen](https://mirror.ox.ac.uk/sites/ctan.org/macros/unicodetex/latex/fontspec/fontspec.pdf). ## TeX-motorer, HarfBuzz og fargeemojier Selv om både XeTeX og LuaHBTeX integrerer HarfBuzz, gir de ulik grad av støtte for noen av HarfBuzzs mer avanserte funksjoner – særlig innlasting og bruk av OpenType-fargefonter. ### XeTeX og OpenType-fargefonter Som nevnt finnes det to kategorier av OpenType-fargefonter basert på dataformatet som brukes til å lagre fontglyfene: vektorbaserte og rasterbaserte. #### XeTeX og rasterbaserte OpenType-fargefonter XeTeX kan ikke laste rasterbaserte OpenType-fargefonter – som Googles [Noto Color Emoji](https://www.google.com/get/noto/help/emoji/) som følger med TeX Live 2020. Hvis du for eksempel prøver å laste Noto Color Emoji (NotoColorEmoji.ttf), vil XeLaTeX feile med en potensielt misvisende feil som påstår at Noto Color Emoji «ikke kan finnes». Følgende LaTeX-kode, satt med XeLaTeX, *fungerer ikke*: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{NotoColorEmoji.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} \smiley \end{document} ``` [Åpne denne XeLaTeX-koden i Overleaf (den ***ikke*** fungerer).](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 feiler med feilen: ``` ! Pakke fontspec-feil: Skriften "NotoColorEmoji" kan ikke finnes. ``` På samme måte mislykkes også et enkelt Plain TeX-eksempel behandlet av XeTeX ```latex \font\emojifont="[NotoColorEmoji.ttf]" at 12pt \emojifont \char"1F600 \bye ``` [Åpne dette Plain TeX-(XeTeX)-eksemplet i Overleaf (det ***ikke*** fungerer).](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-eksemplet rapporterer en lignende, men annerledes, feilmelding: ``` ! Font \emojifont=[NotoColorEmoji.ttf] at 12.0pt not loadable: Metric (TFM) fil e eller installert skrift ikke funnet. l.1 \font\emojifont="[NotoColorEmoji.ttf]" at 12pt Jeg klarte ikke å lese størrelsesdataene for denne skriften, så jeg vil ignorere skrifttilordningen. [Eksperter kan fikse TFM-filer ved hjelp av TFtoPL/PLtoTF.] Du kan prøve å sette inn en annen skrifttilordning; f.eks. skriv `I\font='. ``` **Enkelt LuaHBTeX-eksempel** Til sammenligning er her et minimalt Plain TeX-eksempel kompilert med LuaHBTeX ```latex \input luaotfload.sty \font\emojifont=NotoColorEmoji.ttf:mode=harf at 12pt \emojifont \Uchar"1F600 \bye ``` [Åpne dette Plain TeX-(LuaHBTeX)-eksemplet i Overleaf (det kompileres vellykket).](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 egentlige årsaken til XeTeX-feilen Feilmeldingene fra XeTeX skjuler delvis den faktiske årsaken til problemet: OpenType-fargefonter, særlig rasterbaserte varianter, er *inneholder* støttet av XeTeX. I virkeligheten kan XeTeX (Kpathsea) *finne* Noto Color Emoji-skriften, men XeTeX kan ikke fullstendig *laste* den skriften og klarer ikke å initialisere interne tabeller med skriftdata som kreves for å bruke den skriften til sats. Internt sett, XeTeX *starter* prosessen med å laste skriften og tester den for «skalerbarhet» (ved å bruke FreeTypes «definisjon» av «skalerbarhet»), men testen mislykkes, og XeTeX gir en standard, og kanskje misvisende, feilmelding fra TeX-motoren. **Teknisk note** XeTeXs behandling av NotoColorEmoji.ttf ble undersøkt ved å kompilere en debug-versjon av XeTeX-kjørbarfilen. Eclipse IDE ble brukt til å sette et brytpunkt på XeTeX-funksjonen `creatFontFromFile(filename, index, pointsize)`, og deretter trinnvis gjennom koden for å observere den videre behandlingen. #### XeTeX og vektorbaserte OpenType-fargefonter XeTeX kan *laste* vektorbaserte OpenType-fargefonter, men vil ikke produsere fargeemoji i den resulterende PDF-en – hvis XeTeX i det hele tatt lager en. I motsetning til LuaTeX, LuaHBTeX og pdfTeX, gjør ikke XeTeX *direkte* ut satsede dokumenter i PDF-format. I stedet skriver XeTeX ut en mellomliggende `.xdv` (e**x**utvidet **dv**i) filformat som konverteres til PDF av et verktøy kalt `xdvipdfmx`. På tidspunktet for skrivingen, `xdvipdfmx` klarer ikke å bygge inn de riktige fargeemoji-glyffdataene i PDF-en, så du vil i beste fall se monokrome emoji – «fallback»-resultatet – i PDF-en, eller kanskje ingenting i det hele tatt, avhengig av skriften som brukes. Her er et XeLaTeX-eksempel som bruker OpenType-fargefonten [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr), tilgjengelig i TeX Live. TwemojiMozilla.ttf bruker Microsofts COLR/CPAL-vektorformat for å lagre fargeglyffer og følger med TeX Live 2020. I dette eksemplet klarer XeTeX å laste skriften, generere en `.xdv` og PDF-fil, men emoji-glyffen finnes ikke i den satte PDF-en: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf} \newcommand{\smiley}{{\emojifont\char"1F600}} Her er en smiley: \smiley \end{document} ``` [Åpne denne XeLaTeX-koden i Overleaf (den FUNGERER IKKE).](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) Derimot fungerer koden ovenfor med LuaLaTeX hvis du definerer `\emojifont` ved å bruke `fontspec` innstillingen `[Renderer=HarfBuzz]`: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emojifont{TwemojiMozilla.ttf}[Renderer=HarfBuzz] \newcommand{\smiley}{{\emojifont\char"1F600}} Her er en smiley: \smiley \end{document} ``` [Åpne denne LuaLaTeX-koden i Overleaf (den fungerer).](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 og OpenType-fargefonter Gjennom sin integrerte HarfBuzz-formingsmotor og `luaoftload` biblioteket tilbyr LuaHBTeX støtte for alle fire varianter av OpenType-fargefont. Brukere av LuaLaTeX kan dra full nytte av Unicode-basert behandling av tekst som inneholder emoji-tegn, eller ganske enkelt pynte dokumentene sine med svært fargerik tekst ved hjelp av OpenType-fargefonter. Som nevnt tidligere kan de fire variantene av OpenType-fargefont klassifiseres i to grupper: * de som inneholder glyffer i rasterbildeformater, som PNG; * andre som bruker vektorbaserte formater som SVG eller Microsofts COLR/CPAL-mekanisme. Vektorbaserte glyffformater har fordelen av skalerbarhet: de produserer skarpe glyffgrafikker ved enhver skriftstørrelse. **Bruke Microsoft COLR/CPAL-fargefonter med LuaHBTeX** Hvis du vil bruke et vektorformat for OpenType-farge-emoji-fontene dine, kan du se på fonten [TwemojiMozilla.ttf](https://ctan.org/tex-archive/fonts/twemoji-colr?lang=en), som er basert på Microsofts COLR/CPAL-format. TwemojiMozilla.ttf følger med TeX Live, men du kan hente den nyeste versjonen fra [GitHub-repositoriet](https://github.com/mozilla/twemoji-colr/releases) og laste den opp i Overleaf-prosjektet ditt. Her er et lite, `fontspec`-basert eksempel som bruker `Renderer=Harfbuzz`, som setter opp en stor (vektor-)emojiand: ```latex \documentclass{article} \usepackage{fontspec} \title{Duck demo} \begin{document} \newfontfamily\emojifont[Renderer=Harfbuzz,SizeFeatures={Size=400}]{TwemojiMozilla.ttf} \emojifont\Uchar"1F986 \end{document} ``` [Åpne dette LuaLaTeX-eksemplet for å sette en vektorand.](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) Her er (vektoranden) som ble produsert av eksemplet over: ![](/files/3baa8c45b68679b49c079a69459a548c30362d56) #### Bruk av SVG-baserte OpenType-fargefonter med LuaHBTeX På tidspunktet for denne artikkeloppdateringen (juli 2023) finnes det lite formell dokumentasjon om bruk av SVG-OpenType-fargefonter med LuaLaTeX. Noen [kommentarer i nettbaserte diskusjoner](https://github.com/latex3/luaotfload/issues/96) foreslår å bruke `fontspec`s `RawFeature`, som vist i pseudokoden nedenfor. Erstatt `*navnet på SVG-skriftfilen din her*` med navnet på en SVG-basert skriftfil som er tilgjengelig for LaTeX-koden din: ```latex \documentclass{article} \usepackage{fontspec} \begin{document} \newfontfamily\emoji[RawFeature={+svg},SizeFeatures={Size=20}]{navnet på SVG-skriftfilen din her} \emoji Din emoji her... \end{document} ``` Hvis du utelater `fontspec` og laster `luaotfload` direkte, kan det hende du må deklarere og spesifisere en skrift på følgende måte – våre eksperimenter indikerer at du må utelate `mode=harf` alternativet for at dette skal fungere: ```latex \font\emoji=[navnet på SVG-skriftfilen din her]:+svg; ``` **Noen forsiktighetsnotater** Lesere som er interessert i å bruke SVG-fargede OpenType-fonter bør merke seg: * SVG-OpenType-fonter som inneholder et stort antall glyffer kan være [beregningsmessig kostbare for LuaLaTeX](#processing-svg-glyph-data) å behandle, og kan potensielt føre til [Overleaf-tidsavbrudd](/latex/no/kunnskapsbase/038-fixing-and-preventing-compile-timeouts.md). * LuaLaTeX-støtten for disse skriftene kan [anses som eksperimentell](https://github.com/latex3/luaotfload/issues/96#issuecomment-530317399): resultatene kan variere avhengig av TeX Live-utgivelsen brukt av prosjektet ditt; derfor er det lurt å eksperimentere og gå frem med forsiktighet. **Behandling av SVG-glyffdata** SVG lar designere lage komplekse og fargerike design som representerer en skriftens glyffer – underlagt noen SVG-begrensninger [dokumentert i OpenType-spesifikasjonen](https://docs.microsoft.com/en-us/typography/opentype/spec/svg). TeX-motorer, inkludert LuaHBTeX, kan imidlertid ikke direkte importere (bruke) SVG-filer eller -data – som SVG-data brukt til å beskrive glyffformer i SVG-fargede OpenType-fonter. En glyffs SVG-data må konverteres til PDF-format fordi LuaHBTeX kan bruke det til å sette glyffen og produsere det endelige PDF-dokumentet. Denne SVG-til-PDF-konverteringen håndteres av Lua-kode i `luaoftload`: hver glyffs SVG-data hentes ut fra skriftfilen, lagres til en midlertidig `.svg` -fil og konverteres til PDF ved hjelp av Inkscape via kommandolinjen. Uthenting av SVG-data og konvertering til PDF medfører noe behandlingskostnad, noe som kan gi lange dokumentkompileringstider – særlig for dokumenter som bruker store SVG-fonter med tusenvis av emoji-glyffer. #### Rasterbaserte OpenType-fargefonter **Bruke Googles CBDT/CBLC OpenType-fargefontformat med LuaHBTeX** [Noto Color Emoji](https://fonts.google.com/noto/specimen/Noto+Color+Emoji) er en OpenType-fargefont inkludert med TeX Live, noe som gjør den enkel å bruke i et Overleaf-prosjekt. Fordi Noto Color Emoji bruker PNG-grafikk til å representere emoji-glyffer, kan vi bruke den til å sette en stor (raster) andemoji – som demonstrert av følgende eksempel. Merk igjen at `fontspec` skriftdeklarasjonen (`\emojifont`) bruker `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} ``` [Åpne dette LuaLaTeX-eksemplet for å sette en rasterand.](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) Her er rasteranden som ble produsert av eksemplet over: ![En raster andemoji satt med LaTeX](/files/ff8662af4214e3b40f61129ceb6f68d41da8f277) Hvis du prøver å bruke `NotoColorEmoji.ttf` men utelater `[Renderer=Harfbuzz]` fra `fontspec` deklarasjonen, vil LuaHBTeX feile og gi en feilmelding når den prøver å skrive ut PDF-filen: ```latex ! feil: (fil /usr/local/texlive/2020/texmf-dist/fonts/truetype/google/noto-em oji/NotoColorEmoji.ttf) (ttf): loca-tabell ikke funnet ``` Årsaken til denne feilen i [loca-tabellen](https://docs.microsoft.com/en-us/typography/opentype/spec/loca) er [forklart på GitHub](https://github.com/latex3/luaotfload/issues/98#issuecomment-531610153). **Bruke Apples sbix OpenType-fargefontformat med LuaHBTeX** Frakoblede tester viser at LuaHBTeX støtter `sbix` varianten av OpenType-fargefont, men per tidspunktet for skrivingen av denne artikkelen har vi ikke klart å finne en passende lisensiert `sbix`-variant fargeemoji-font for å demonstrere sats av en and. Vennligst [ta kontakt med oss](https://www.overleaf.com/contact) si ifra hvis du kjenner til en, så oppdaterer vi raskt denne artikkelen til å bruke den. ## Introduksjon til LuaHBTeX HarfBuzz-API-et ![Db.gif](/files/6cc6645c0963d05882adf327d29ed93d8a12c838) ![Db.gif](/files/6cc6645c0963d05882adf327d29ed93d8a12c838) Tekstforming, særlig for språk med komplekse skriftsystemer, og til og med emoji, er en iboende vanskelig oppgave, så det er ikke overraskende at HarfBuzz er et avansert bibliotek som kan være vanskelig å arbeide med – med mindre du allerede er kjent med tekstformingsoperasjoner. I denne siste delen ser vi på LuaHBTeXs integrasjon av HarfBuzz og hvordan du får tilgang til den via Lua-kode i `\directlua`. Eksemplet vårt bruker ganske grunnleggende kode for å demonstrere LuaHBTeX HarfBuzz-API-et. Det er noe konstruert, ikke av produksjonskvalitet, og heller ikke særlig praktisk fordi det eneste formålet er å introdusere noen kjerneideer. Vi har delt Lua-koden inn i to `\directlua` biter: den første laster `luaharfbuzz` biblioteket og oppretter noen globale variabler som vi skal bruke i vår andre `\directlua` bit, der vi definerer en makro kalt `\codestoemoji`. Det føles passende å gjenskape Knuths bruk av doble fare-svingsymboler (bilde med tillatelse fra [dette nettstedet](http://www.truetex.com/db.htm)) fordi innholdet er noe lavnivå og «ser under panseret» – selv om vi håper det kan være av interesse for den mer vågale leseren. LuaHBTeXs integrasjon av HarfBuzz er avledet fra [luaharfbuzz-prosjektet på GitHub](https://github.com/ufyTeX/luaharfbuzz/wiki#projects-using-luaharfbuzz) hvor du finner en [introduksjon til prosjektet](https://github.com/ufyTeX/luaharfbuzz/wiki) sammen med en [oversikt over luaharfbuzz-API-et](http://ufytex.github.io/luaharfbuzz/). ### Første steg: last inn luaharfbuzz-biblioteket og finn en skrift For å bruke LuaHBTeXs HarfBuzz-API må vi først laste biblioteket (modulen) kalt `luaharfbuzz`, innebygd i LuaHBTeX, og lagre den returnerte tabellen i en (global) variabel vi skal kalle `hblib`: ```latex hblib=require("luaharfbuzz") ``` Deretter må vi finne en passende OpenType-fargefont for emoji: vi skal bruke Noto Color Emoji – merk at vi er veldig late og ikke gjør noen feilsjekk i tilfelle vi ikke finner den! For å finne den bruker vi `kpse` (Kpathsea)-biblioteket, som også er en del av LuaTeX/LuaHBTeX: ```latex pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") ``` Nå som vi har tilgang til HarfBuzz-biblioteket, via variabelen vår `hblib`, og banen til en passende skrift (`pathtofontfile`), kan vi begynne å bruke `hblib`. Til å begynne med skal vi opprette en HarfBuzz-font og HarfBuzz-face for bruk i den andre `\directlua` kodebiten der vi definerer makroen vår. ```latex %Opprett HarfBuzz-face og HarfBuzz-font fra Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) ``` #### HarfBuzz-font og HarfBuzz-face: hva er det? Et [HarfBuzz-faceobjekt](https://harfbuzz.github.io/fonts-and-faces.html) representerer en skrifttype lastet fra en skriftfil, men uten at spesifikke parametere (som størrelse) er satt. En [HarfBuzz-fontobjekt](https://harfbuzz.github.io/fonts-and-faces.html) representerer en *spesifikk instans* av en HarfBuzz-face; derfor kan ulike HarfBuzz-fontobjekter avledes fra én enkelt HarfBuzz-face: hver HarfBuzz-font kan ha sine egenskaper, som størrelse, satt til ulike verdier. En HarfBuzz-face er et høyere abstraksjonsnivå enn en HarfBuzz-font. ### Bruke skrifteglyffer til å lage PNG-filer Den siste delen av vår første `\directlua` kodebit er en funksjon kalt `writePNGglyph(hbfontobject, glyphID)` som vi bruker for å demonstrere at noen OpenType-fargefonter, som Noto Color Emoji, bruker PNG-grafikk til å representere emoji-glyffene de inneholder. Denne funksjonen bruker LuaHBTeXs HarfBuzz-API til å trekke ut PNG-data fra glyffer og skrive disse dataene til en `.png` filen med navnet `Graphics.png`. Navnet på denne `.png` filen returneres for bruk av `\includegraphics` for å bygge inn PNG-glyffbilder i vår satte PDF. Med `writePNGglyph(hbfontobject, glyphID)` på plass er vår første `\directlua` kodebit slik: ```latex \directlua{ % Last inn luaharfbuzz-biblioteket fra LuaHBTeX hblib=require("luaharfbuzz") % Finn Noto Color Emoji-skriften på Overleaf-serveren pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Opprett HarfBuzz-face og HarfBuzz-font fra Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Denne funksjonen tar en skrift og en glyff-ID som argument: % den henter ut glyffens PNG-data og skriver % den til en .png-fil function writePNGglyph(hbfontobject, glyphID) % Hent PNG-data for glyffen local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Konstruer et filnavn for .png-filen vår local fname="Glyph"..glyphID..".png" % Skriv .png-filen og returner filnavnet local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Returner filnavnet for bruk av \includegraphics return fname end } ``` ### Andre \directlua-biten: opprett makroen \codestoemoji Målet er å definere en makro `\codestoemoji` som vi kan kalle med et tekststykke som inneholder emoji-tegnkoder vi ønsker at HarfBuzz skal forme. Mer spesifikt skal vi bruke `\Uchar` for å representere hvert emoji-tegn; for eksempel: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` Det skjer mye i definisjonen av `\codestoemoji` som vi skal forklare nedenfor, men definisjonen ser slik ut: ```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() % Glyff-tabellen, hbglyphs, er 1-basert local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduser størrelsen på våre importerte PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} ``` #### Forstå definisjonen av makroen \codestoemoji Den `\codestoemoji` makroen er for det meste Lua-kode inne i `\directlua`, så hvis du vil vite mer om *hvordan* `\directlua` virker, kan du sjekke Overleaf-artikkelen [Forstå `\directlua`](/latex/no/dybdeartikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md). Den forklarer hvordan LuaTeX og LuaHBTeX behandler `\directlua` når TeX/LaTeX-kommandoer er inkludert i Lua-koden og, særlig, behovet for å bruke `\noexpand` og `\unexpanded`. **Håndtering av makroparameteren: "#1"** Makroen starter med disse tre linjene: ```latex local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) ``` som utfører følgende oppgaver: * `local str="#1"`: dette lager en Lua-streng fra inndata sendt inn av makroen; * `local hbbuffer = hblib.Buffer.new()`: dette bruker HarfBuzz-API-et til å opprette en buffer som holder teksten vi vil at HarfBuzz skal forme; * `hbbuffer:add_utf8(str)`: dette legger til en streng i UTF-8-format, laget fra makroens inndata, i HarfBuzz-bufferen. Den første kodelinjen ```latex local str="#1" ``` ser ganske enkel ut, men funksjonen innebærer en god del kompleksitet, som er verdt å utforske litt nærmere. Hvis vi ser på den tredje kodelinjen ```latex hbbuffer:add_utf8(str) ``` ser vi at den bruker vår `str` variabel til å gi HarfBuzz-bufferen en Unicode-streng formatert i UTF-8. For at det skal fungere, må variabelen `str` selv inneholde Unicode-tekst formatert som UTF-8; så spørsmålet oppstår: *hvordan* «konverterte» LuaHBTeX makroargumentet `"#1"`, som inneholder `\Uchar` kommandoer, til Lua-strengvariabelen `str` som inneholder UTF-8-tekst for HarfBuzz? Hvis vi ser på vår tiltenkte bruk av `\codestoemoji` makroen: ```latex \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` inndataen, som for eksempel `\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065...`, ser ikke i det hele tatt ut som en sekvens av emoji-tegn kodet i UTF-8. Dessuten vet ikke HarfBuzz noe om TeX-kommandoer. På en eller annen måte blir den rå TeX-inndataen som består av `\Uchar` kommandoer transformert til Unicode-tegn kodet i UTF-8 som HarfBuzz kan bruke, men *hvordan*? Svaret ligger i oppførselen til `\Uchar` kommandoen: å forsøke å kalle `\codestoemoji` ved å bruke `\char` i stedet for `\Uchar` vil mislykkes, men *hvorfor*? **\Uchar: ekspansjon i \directlua** Når `\codestoemoji` makroen kalles, må `\directlua` kommandoen, lagret i makroens definisjon, forberede Lua-kode som skal sendes til LuaHBTeXs innebygde Lua-tolker. En del av denne kodeforberedelsesprosessen er ekspansjonen av alle TeX/LaTeX-kommandoer som finnes i den opprinnelige Lua-koden i makroens definisjon, sammen med ekspansjonen av eventuelle makroargumenter som brukeren har oppgitt. Denne ekspansjonsprosessen gir en tokenliste som deretter konverteres tilbake til tekst, og danner Lua-koden som sendes til Lua-tolken. For enkelhets skyld gjengir vi et diagram fra Overleaf-artikkelen [Forstå `\directlua`](/latex/no/dybdeartikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md): ![Mekanismen bak \directlua](/files/ba8ac47b13bf18855f6f58c0d8c2a6ce15a29a8a) Makroen `\codestoemoji` er ment å kalles med `\Uchar` kommandoer og, [som nevnt tidligere i artikkelen](#the-key-difference-expansion), `\Uchar` er en ekspanderbar kommando hvis ekspansjon genererer et tegntoken. Innen behandlingsaktivitetene til `\directlua`, utvider LuaHBTeX hver `\Uchar` kommando der den *fjerner* hver `\Uchar` fra inndataene og *erstatter* den med den tilsvarende ekspansjonsverdien: et tegntoken som representerer ``. I den siste behandlingsfasen blir den opprinnelige tokenlisten generert av `\directlua` konvertert *tilbake til tekst* for å bli Lua-koden som skal til Lua-tolken (se diagrammet ovenfor). Alle tegntokens produsert av ekspansjonen av `\Uchar` blir også *konvertert tilbake til tekst*: denne konverteringen av tegntokens til tekst genererer UTF-8-representasjonene av de opprinnelige `` verdiene. I vårt eksempel, når Lua-koden er generert og klar for Lua-tolken, har makroinndataen for "#1" blitt konvertert til en sekvens av UTF-8-tekst: den `str` variabelen er nå en UTF-8-tekststreng som trygt kan legges til HarfBuzz-bufferen. **Hvorfor fungerer ikke \char?** Det korte svaret er fordi `\char` er *inneholder* en utvidbar kommando. I motsetning til `\Uchar` kommandoer, `\char` kommandoer *fjernes ikke* fra inputen under `\directlua`sin innledende prosessering for å generere en tokenliste, «passerer de gjennom» og blir dermed innlemmet i tokenlisten som konstrueres av `\directlua`. For eksempel, hvis argumentet til `\codestoemoji` inneholdt `\char"1F3F4` LuaHBTeX ville konvertere det til en sekvens av tokener og lagre dem som en del av den totale tokenlisten som genereres. I neste trinn av prosesseringen, der tokenene konverteres tilbake til tekst, ville den resulterende Lua-koden inneholde *den bokstavelige strengen* `\char"1F3F4` i teksten som brukes til å definere variabelen vår `str`. Når innholdet i `str` legges til HarfBuzz-bufferen, vil det ikke inneholde en UTF-8-kodet sekvens som representerer emoji-tegnet "1F3F4, det vil inneholde den bokstavelige strengen `\char"1F3F4`, som HarfBuzz vil prøve å forme og, for våre formål, ikke ville produsere en emoji-glyf. For øvrig vil strengen `\char"1F3F4` ville også generere Lua-syntaksfeil med mindre den ble opprettet som en «long-bracket string»—se [Hva er Lua-escape-sekvenser](/latex/no/dybdeartikler/09-an-introduction-to-luatex-part-2-understanding-directlua.md#what-are-e2809clua-escape-sequencese2809d3f) for bakgrunn om dette problemet. Hvis vi prøver å bruke `\codestoemoji` med en `\char` kommandoen, slik som dette: ```latex \codestoemoji{\char"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} ``` LuaHBTeX vil feile og rapportere en syntaksfeil omtrent slik: ```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å et problem, så resten av denne Lua-blokken vil bli ignorert. ``` #### Kaller HarfBuzz-formingsfunksjonen **Setter bufferparametere** HarfBuzz krever noen ganger tilleggsinformasjon om teksten den blir bedt om å forme. Du kan gi den informasjonen ved å konfigurere din `` ved å bruke *buffer-metoder*, for eksempel: * `:set_direction(*HarfBuzz direction*)`; * `:set_language(*HarfBuzz language*)`; * `:set_script(*HarfBuzz script*)`. For eksempel må vi informere HarfBuzz om at retningen til emojiteksten vår skal være fra venstre mot høyre. For å gjøre det bruker vi `set_direction()` metoden på vår `` (kalt `hbbuffer`) ved å skrive: ```latex hbbuffer:set_direction(hblib.Direction.new("ltr")) ``` der `hblib.Direction.new("ltr")` oppretter et «retning-objekt» som er egnet for å sendes til HarfBuzz-motoren via Lua. **Utfør forming** Etter at bufferen er tilstrekkelig initialisert, kan vi be HarfBuzz om å utføre selve formingen via funksjonen `shape_full()`. I vårt eksempel skriver vi: ```latex local res = hblib.shape_full(hbfont, hbbuffer, {},{}) ``` Det 3. og 4. parameteret til `shape_full()` funksjonen må være Lua-tabeller — vi har brukt tomme tabeller «`{}`» for begge parametrene. Den generelle formen til `shape_full()` er: ```latex shape_full(Harfbuzz font, Harfbuzz buffer, {font features}, {"shaper"} ``` * **`{"shaper"}`**: Trenger vanligvis ikke å settes, men alternativene er `{"ot"}` eller `{"graphite2"}`. Mer informasjon om konseptet «shaper» finnes i [HarfBuzz-dokumentasjonen](https://harfbuzz.github.io/shaping-and-shape-plans.html)—merk at dette dokumenterer C-API-et på lavt nivå, ikke den Lua-baserte `luaharfbuzz` bindingen (implementasjonen). * **`{font features}`**: Dette er en tabell som viser [OpenType-funksjoner](https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist)—støttet av fonten—som du vil at HarfBuzz skal bruke under forming. Enhver fontfunksjon du vil bruke må opprettes ved hjelp av en `luaharfbuzz` biblioteksfunksjon ```latex library_instance.Feature.new(feature_string) ``` der * `library_instance` er din `luaharfbuzz` bibliotekinstansvariabel (`hblib` i vårt eksempel); * `feature_string` bruker en [syntaks for å definere funksjoner](https://github.com/ufytex/luaharfbuzz/wiki/Feature-Strings). Eksempler på dette er `+smcp` for å aktivere kapitéler eller `-kern` for å deaktivere kerning. For eksempel: ```latex local dosmcp = hblib.Feature.new("+smcp") local nokern = hblib.Feature.new("-kern") % Bruk fontfunksjonene dine slik local res = hblib.shape_full(hbfont, hbbuffer, {dosmcp,nokern},{}) ``` #### Tilgang til resultatet: hente glyfene Og til slutt, hvis formingsoperasjonen lykkes, returneres de formede glyfene i buffer-variabelen `hbbuffer` som vi opprettet tidligere i koden. Vi får tilgang til glyfene via buffer-metoden `get_glyphs()` og bruker en løkke for å hente hver enkelt glyf. Merk at Lua-tabellen som inneholder glyfene, `hbglyphs` i vårt eksempel er indeksert fra 1, ikke 0. Hver glyfs *glyfidentifikator* (forvirrende nok kalt `kodepunkt`), og HarfBuzz-fonten (`hbfont`), sendes til `writePNGglyph()` funksjonen som oppretter en PNG-fil ved å bruke fontens rasterbilde-representasjon av den glyfen. `writePNGglyph()` skriver ut en PNG-fil og returnerer navnet på PNG-filen, som brukes til å importere den (skalerte) PNG-filen inn i LaTeX-dokumentet vårt via `\includegraphics[scale=0.75]{}`. Legg merke til hvordan vi kan bruke `\includegraphics` direkte i Lua-koden. ```latex if (res) then local hbglyphs=hbbuffer:get_glyphs() % Glyff-tabellen, hbglyphs, er 1-basert local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduser størrelsen på våre importerte PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end ``` ### Den komplette koden som du kan åpne i Overleaf ```latex \documentclass{article} \usepackage{graphicx} \begin{document} \directlua{ % Last inn luaharfbuzz-biblioteket fra LuaHBTeX hblib=require("luaharfbuzz") % Finn Noto Color Emoji-fonten på Overleafs server pathtofontfile=kpse.find_file("NotoColorEmoji.ttf","truetype fonts") % Opprett HarfBuzz-face og HarfBuzz-font fra Noto Color Emoji hbface = hblib.Face.new(pathtofontfile) hbfont = hblib.Font.new(hbface) % Denne funksjonen tar en skrift og en glyff-ID som argument: % den trekker ut glyfenes PNG-data og skriver % den til en .png-fil function writePNGglyph(hbfontobject, glyphID) % Hent PNG-data for glyffen local pngblob=hbfontobject:ot_color_glyph_get_png(glyphID) local pngdata=pngblob:get_data() % Konstruer et filnavn for .png-filen vår local fname="Glyph"..glyphID..".png" % Skriv .png-filen og returner filnavnet local output = assert(io.open(fname, "wb")) output:write(pngdata) output:close() % Returner filnavnet for bruk av \includegraphics return fname end } \newcommand{\codestoemoji}[1]{% \directlua{ local str="#1" local hbbuffer = hblib.Buffer.new() hbbuffer:add_utf8(str) hbbuffer:set_direction(hblib.Direction.new("ltr")) local res = hblib.shape_full(hbfont, hbbuffer, {},{}) if (res) then local hbglyphs=hbbuffer:get_glyphs() % Glyf-tabellen, hbglyphs, er 1-basert. local i = 1 while hbglyphs[i] \noexpand~= nil do local glyph = hbglyphs[i] i = i + 1 local fname=writePNGglyph(hbfont, glyph.codepoint) % Reduser størrelsen på våre importerte PNG-bilder local s = 0.75 local scal="[scale="..tostring(s).."]" tex.print([[\noexpand\includegraphics]]..scal..[[{]]..fname..[[}]]) end end }} En and: \codestoemoji{\Uchar"1F986} Et flagg: \codestoemoji{\Uchar"1F3F4\Uchar"E0067\Uchar"E0062\Uchar"E0065\Uchar"E006E\Uchar"E0067\Uchar"E007F} \end{document} ``` [Åpne dette luaharfbuzz-API-eksemplet i Overleaf.](/latex/no/dybdeartikler/10-an-overview-of-technologies-supporting-the-use-of-colour-emoji-fonts-in-latex.md) Dette eksemplet gir følgende resultat: ![Harfbuzzexample.png](/files/48321e796aeced21ff03371bfa8791fd51478665) ## Bonuseseksjon: Moro med emoji-matematikk For å avslutte med en lettbeint tone brukte et medlem av Overleaf-teamet [`emoji` LaTeX-pakken](https://ctan.org/pkg/emoji?lang=en) for å lage et morsomt eksempel: ```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} ``` [Åpne dette morsomme eksemplet 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) Dette eksemplet gir følgende resultat: ![Emojimath2.png](/files/dfe48b9c668e4fa6373e675ae3dcfdaf34c82bf3) --- # 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/no/dybdeartikler/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.