Fonthantering OpenType och xml

Transkript

1 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

2 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 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 Open- Type. 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

3 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: Panose 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 ä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

4 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 Open- Type-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 Open- Type-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

5 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. Svg 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. 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

6 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: Poznan PR (om Open Font Format): MPEGOpenT.pdf (Pressmeddelande, OpenType blir teckensnittsstandard i MPEG4 ): Fonts (W3C Recommendations): Monotype Imaging: Panose Guide (Specifikation för och information om Panose-systemet): Kaj Johansson, Peter Lundberg, Robert Rydberg. Grafisk kokbok Guiden till grafisk produktion. Arena/Kapero Christer Hellmark. Typografisk handbok. Ordfront Förlag