Fonthantering
OpenType och xml
Carl-Johan Rosén, ITN, Linköpings universitet
Cecilia Björk, ITN, Linköpings universitet
Table of Contents
Sammanfattning .......................................................................................................... 1
Inledning ................................................................................................................... 1
Teckensnittsstandarder ................................................................................................. 2
OpenType-standarden .................................................................................................. 2
OpenType-specifikationen ............................................................................................ 2
Panose ...................................................................................................................... 3
XML och metadata ...................................................................................................... 4
Applikationen ............................................................................................................. 4
Beskrivning av transformationsprocessen ........................................................................ 4
Beskrivning av klasserna .............................................................................................. 5
Vidareutveckling ......................................................................................................... 5
Svg .......................................................................................................................... 5
Diskussion ................................................................................................................. 6
Referenser ................................................................................................................. 6
Sammanfattning
Stora luckor finns inom området fonthantering. I denna rapport redovisas en utredning kring att utnyttja
metadatan i OpenType-standarden för att möjliggöra sökning och sortering av teckensnitt baserat på utseende, snarare än namn. Här redogörs också för ett verktyg som omvandlar headerns information till
xml-format. Slutligen diskuteras fördelar och nackdelar med detta tillvägagångssätt.
Inledning
Det finns tusentals fonter att välja mellan, men inget bra sätt att hålla reda på alla. De sorteringsverktyg
som finns på marknaden, som Adobe Type Manager och FontBook, utgår ifrån att man själv ska sortera
sina typsnitt, till exempel efter stil, eller genom att man gör portföljer av de typsnitt man brukar använda
tillsammans. Programmet kommer sedan endast ihåg hur denna sortering såg ut. Om man inte använder
ett fonthanteringsverktyg sorteras fonterna helt enkelt i bokstavsordning. Detta leder rimligtvis till att
man använder en ganska begränsad mängd fonter, och innebär även en hel del merarbete för
användaren.
Även när det gäller försäljning av fonter finns stora luckor i sortering och sökning. Oftast förutsätts även
här att kunden själv vet vad fonten heter, eller så får man helt enkelt titta igenom en stor mängd thumbnails eller exempeltexter för att hitta ett typsnitt som passar. När kunden förutsätts veta exakt vad den
letar efter redan innan den kommit in på hemsidan är det rimligt att anta att antalet spontanköp minskar.
Detta borde kunna förbättras, och vi har tittat på hur man skulle kunna använda metadata i OpenTypefonter för att göra ett sökverktyg som söker på fontens utseende, och inte på namn. Vad gäller
försäljning av typsnitt borde detta kunna leda till ett system liknande Amazon.coms: ”Om du gillar detta
typsnitt borde du nog gilla dessa också!” Detta borde rimligtvis leda till nöjdare kunder och ökad
1
Fonthantering
försäljning.
Teckensnittsstandarder
Det finns huvudsakligen tre typer av fonter: TrueType, PostScript typ 1, och OpenType. Adobe utvecklade PostScript typ 1, och den var länge en väletablerad standard. För att undvika att licensavgifter och
annat ständigt var tvunget att betalas till Adobe slog Apple och Microsoft sina påsar ihop och utvecklade
TrueType. 1997 gjorde sedan Adobe och Microsoft gemensam affär av att utveckla en paraplystandard
som inbegriper de tidigare, plus lägger till en massa extra information - OpenType.
En annan typ av font som redan är historia är Multiple Master, utvecklad av Adobe. Det intressanta med
MM-fonter är att man genom relativt enkla handgrepp själv kan påverka typsnittets utseende. Utseendet
kan ändras enligt en rad fördefinierade axlar, som exempelvis vikt eller bredd. MM-fonter används
också för att ersätta enskilda tecken som saknas ur teckensnitt, eftersom man med den tekniken kan imitera originaltypsnittet tillräckligt bra för att skapa ett ersättningstecken (som åtminstone fungerar på
skärm). Eftersom Multiple Master slutade utvecklas redan 1999 kan man dock som sagt konstatera att
dess dagar är räknade.
OpenType-standarden
OpenType skapades 1997, och dess stora fördel är dess förmåga att hantera stora mängder information.
Detta leder exempelvis till bättre kompatibilitet mellan plattformar, och att en enda fontfil kan inrymma
alla världens språk och specialtecken (så länge de finns definierade). De stora uppsättningarna tecken
lagras, på samma sätt som i TrueType, i Unicode.
Att ordet open finns med i namnet indikerar ju att detta är en öppen standard, så är dock inte fallet. Det
är i allra högsta grad kommersiella intressen som ligger bakom. ”Open” syftar på att den täcker in de tidigare standarderna.
Eftersom OpenType täcker in både TrueType och PostScript typ 1, och därför kan ärva deras
egenskaper, finns ingen anledning att tro att man skulle överge OpenType för någon av de äldre modellerna igen. Däremot har standarden fått en del kritik för att enbart vara ett pr-stunt som egentligen inte
innebär några direkta fördelar för användaren. Det har också riktats kritik mot att upphovsmakarna ger
sken av att detta är en öppen standard.
En sak som verkligen talar till OpenTypes fördel är att det kommer att bli basen för ett nytt fontformat i
multimediastandarden MPEG4. Moving Picture Experts Group har godkänt en formell standardisering,
och detta kommer att leda fram till Open Font Format Specification, vilket är en ISO-variant av OpenType. Denna specifikation kommer att finnas allmänt tillgänglig för andra företag som vill utveckla
teckensnitt.
OpenType-specifikationen
OpenTypes specifikation finns att läsa på Microsofts hemsida. Den består av åtta obligatoriska tabeller,
samt 24 valfria. Vilka tabeller som finns med beror dels på vilken typ av teckensnitt det rör sig om (alla
OpenType-teckensnitt är TrueType eller PostScript i grunden) och dels på vilken information som finns
eller önskas göras tillgänglig. I varje tabell finns sedan en massa data, med fördefinierade datatyper och
storlekar.
De tabeller som är obligatoriska för alla teckensnitt är:
cmap - Character to glyph mapping
head - Font header
2
Fonthantering
hhea - Horizontal header
hmtx - Horizontal metrics
maxp - Maximum profile
name - Naming table
OS/2 - OS/2 and Windows specific metrics
post - PostScript information
Om vi exempelvis tittar närmare på hhea, Horizontal Header, visar sig följande information:
Här kan vi till exempel i andra positionen hitta information om teckensnittets underhäng, alltså avståndet
mellan baslinjen och nederkanten i exempelvis bokstaven j.
Panose
Panose är ett system för att i Windows kunna jämföra fonter efter utseende, som redan finns implementerat i OpenType-standarden (i tabellen OS/2). Upp till 65 olika mätvärden kan skickas med fontfilen,
3
Fonthantering
bland annat information om x-höjd, vikt, proportioner och variationer i strecken. Tanken med detta system verkar ligga i linje med vår idé, och en vidareutveckling av detta skulle kunna ge en god sök- och
sorterbarhet för teckensnittet.
XML och metadata
Xml, Extensible Markup Language, erbjuder ett mycket strukturerat och effektivt sätt att presentera den
information som finns lagrad i fontfilens header. Att lagra headern direkt i xml är knappast aktuellt
eftersom det uppskattningsvis skulle kräva omkring tio gånger mer plats än i nuläget. Att däremot, som i
våra försök, definiera tydliga transformer för hur man översätter headerdatan till xml, skulle göra att
man med en enkel applikation lätt skulle få ut ett xml-träd som vore både sök- och sorterbart.
Applikationen
Tanken med applikationen är att extrahera informationen från headerfilen som finns med i en OpenType-fontfil. Denna information lagras sedan i en xml-struktur som i sin tur gör det enkelt att få en
översikt över, samt att söka bland, teckensnittets egenskaper.
Det är uppenbart att denna xml-struktur är betydligt mer användbar än den information headern
ursprungligen består av. Vår ursprungliga tanke var dock att även skapa algoritmer och ett gränssnitt för
en sökfunktion. Då det inte funnits den typ av information vi förväntade oss, och den information som
funnits varit relativt svår att tyda, har vi valt att lägga detta åt sidan och fokusera på xml-strukturen och
teorin.
Beskrivning av transformationsprocessen
Transformationen av informationen i OpenType-dokumentet sker i två steg: inläsning från av OpenType-dokumentet och utmatning till xml-dokumentet. Det förra består av läsning från dokumentet i
block om fasta antal bytes. Med hjälp av specifikationen (på microsoft.com) vet man var i dokumentet
viss information finns, samt med vilken typ av komprimering den är skriven. Med komprimering menas
hur datan i dokumentet skall översättas från en rad binärkod till ett heltal, ett flyttal, en sträng eller något
annat.
Den andra delen, utmatning till xml-dokumentet, sker med hjälp av ett JDOM-träd. Trädet skapas när
programmet startas och fylls med den redan befintliga fontinformationen i dokumentet. Trädet fylls
sedan med den nya fontdatan. Skulle det vara så att det redan finns ett element för den font som just lästs
in raderas det gamla elementet till förmån för det nya. Trädet skrivs sedan till hårddisken.
För att veta vilken information som skall transformeras skapas en transformationsarray. Den innehåller
datans namn, vilken tabell den ligger under, samt på vilken plats den ligger från tabellens början. Programmets kärna löper sedan genom alla dessa transformer, läser in dem och lägger dem i JDOM-trädet.
För att förenkla inläsningsprocessen så läses varje tabell in först när den anropas i transformationsarrayen. Sedan sparas den i minnet och skulle ytterligare information från samma tabell efterfrågas behöver
OpenType-dokumentet inte läsas igen.
De flesta tabeller följer samma struktur. Det ligger oftast ett antal data i rak följd i filen. Men det finns
några undantag, där storleken på datan inte är bestämd i specifikationen. I dessa tabellers första data ges
information om vilken specifikationsversion eller tabellformat som avses, vilket leder till flera möjliga
filstrukturer. (Exempel på detta är cmap, name och post.) Om det är en viss version så står det sedan hur
många records som följer, där ett record är en slags undertabell, eller datastruktur bestående av flera
datatyper. Dessa datatyper måste då läsas in iterativt. (Exempel på detta är name.) Båda dessa nämnda
typer av undantag gör det problematiskt att generellt transformera OpenType-dokument. I prototypen
har problematiska tabeller prioriterats lägre än de med mer rak struktur.
4
Fonthantering
Beskrivning av klasserna
OTMain - Detta är den drivande klassen. Här initieras transformationsarrayen och här finns mainfunktionen som styr transformationsprocessen.
OTTableHeader - Datastruktur för headerinformationen.
OTHeaderReader - Sköter inläsningen av headerinformationen för tabellerna samt annan metainformation om fonten. Denna klass är gränssnittet för att läsa data från OpenType-dokumentet.
OTTableReader - Innehåller strukturbeskrivningarna för att läsa tabellerna från filen. Ett begränsat antal
tabeller är implementerade (post, head, OS/2, name, hhea, maxp), några av dessa ej fullständigt enligt
standarden.
OTRandomAccessReader - Detta är klassen som omvandlar binärdatan till användbara heltal, flyttal och
strängar. Klassen tillhandahåller enkla metoder för var datatyp.
XMLLoader - Läser in xml-dokumentet i ett JDOM-träd.
XMLDocument - Håller koll på att det inte blir några dubletter av fonter och skapar nya fonter till dokumentet.
XMLFont - Tillhandahåller funktioner för att lägga till element i fontelementet, samt en funktion för att
ersätta ogiltiga tecken.
XMLSaver - Skriver JDOM-trädet till hårddisken.
TransformInfo - Datastruktur för transformationsinformation.
Vidareutveckling
Det finns stora möjligheter att ta denna idé vidare. För att få tillräckligt bra information om teckensnittets karaktär kan man tänka sig att följande karaktäristika bör infogas i xml-trädet, antingen via headern,
eller i efterhand direkt i xml-trädet: Versalhöjd, x-höjd, underhäng, bredd, grundstreck, hårstreck (bredd
och orientering), storlek på inre form relativt hela bokstaven, växellinjens tjocklek relativt normalt
streck, växellinjens orientering, bredd och höjd på serifer samt även orientering på sneda serifer.
Hur denna information ska utvinnas från teckensnittet kan diskuteras. Det skulle kunna ske manuellt,
antingen vid skapandet av typsnittet, eller senare då headerinformationen läggs in. Ett annat intressant
alternativ är en intelligent lösning som själv läser av tecknens karaktär med hjälp av bildbehandling. Ett
exjobb som kombinerar bildbehandling och fonthantering pågår just nu på ITN, och det ska bli
spännande att se vad man kommer fram till för resultat.
Svg
Ett annat alternativ är att använda sig av svg. I specifikationen finns glyfdata med information om antal
kontrollpunkter för typsnittet. Detta är förmodligen vektordata som skulle kunna gå att läsa ut som svg
för att kunna visa upp typsnittet. Och om denna data skulle kunna vara tillräcklig för att visa typsnittet
måste det även innehålla tillräckligt mycket information för att kunna jämföra teckensnitt med varandra.
I dagsläget är dock korrekt fontrepresentation i svg-filer ett problem, eftersom svg jobbar med exakt positionering, vilket ställer oerhört stora krav på teckensnittet. Detta borde innebära att den data som finns
att tillgå är begränsad. Det är hur som helst ett intressant område och här borde stora
utvecklingsmöjligheter finnas.
5
Fonthantering
Diskussion
Det verkar finnas en stor lucka när det gäller vettiga sökverktyg för teckensnitt. Det finns en stor tillit till
att användaren ska besitta stora kunskaper, och ha tid att själv sortera sina typsnitt. Stora möjligheter till
ökad fontförsäljning och nöjdare användare borde rimligtvis ligga i en bättre lösning för sökning och
sortering. Varför detta inte redan finns är svårt att säga. Men det är tydligt att det inte är helt trivialt, då
flera lösningar figurerat i industrin men ingen blivit riktigt använd och effektiv. Vår lösning skulle
kunna ge ett hyfsat bra resultat utan större arbetsinsats, och skulle dessutom sedan lätt kunna förbättras.
Den stora omedelbara nyttan med en xml-struktur för specifikationen är givetvis överskådlighet.
Innan vi påbörjade projektet hade vi ganska höga förväntningar på vad vi skulle göra, och förväntade oss
att resultatet skulle bli en färdig applikation med tillhörande gränssnitt för sökning och sortering av teckensnitt. Det stod dock ganska snart klart att den information som finns i headern inte räcker till för att
åstadkomma detta - det är därför denna lösning inte redan finns. Det skulle även innebära betydligt mer
jobb än vad som var planerat för det här projektet. Sammanfattningsvis är vi ändå nöjda med det vi kommit fram till, vi har lärt oss massor om typsnitt, och arbetat vidare på en idé som vi tror har potential.
Referenser
Microsoft Typography - OpenType Specification: http://www.microsoft.com/OpenType/OTSpec/
Poznan
PR
(om
Open
Font
tp://www.chiariglione.org/mpeg/meetings/poznan05/poznan_pr.htm
Format):
ht-
050818MPEGOpenT.pdf (Pressmeddelande, ”OpenType blir teckensnittsstandard i MPEG4”): http://www.adobe.se/aboutadobe/pressroom/pr/aug2005/050818MPEGOpenT.pdf
Fonts - 1.1 - 20030114 (W3C Recommendations): http://www.w3.org/TR/SVG/fonts.html
Monotype Imaging: Panose Guide (Specifikation för och information om Panose-systemet): http://www.panose.com/ProductsServices/pan1.aspx
Kaj Johansson, Peter Lundberg, Robert Rydberg. Grafisk kokbok 2.0 - Guiden till grafisk produktion.
Arena/Kapero. 2001.
Christer Hellmark. Typografisk handbok. Ordfront Förlag. 2000.
6
