Så här fungerar Typekit med länkade typsnitt på webben

I och med lanseringen av Typekit ska man nu kunna länka typsnitt på webben från Typekits servrar, och typsnitten ska inte kunna laddas ned av kreti och pleti. Nog för att det kan uppfattas som ett lovvärt alternativ, men det är inget annat än ett lager av krångel. Dessutom går det utmärkt att ladda ner typsnitten. Här visar vi hur.

Jag vill börja med att påpeka att vi inte på något sätt uppmanar till piratkopiering, utan det här är istället en genomgång av hur tekniken hos Typekit fungerar. Det här är gjort i utbildningssyfte, och med målet att man ska använda den standardiserade metoden med @font-face istället. Tillsammans med en licens som tillåter länkning av typsnitt på webben.

Inbäddade typsnitt i Firefox.

Så länge webben funnits har formgivare gjort sitt bästa för att kunna använda valfria typsnitt i sina layouter. Från början genom att göra texten till bilder, med alla negativa konsekvenser det medför – inte möjligt att indexera för sökmotorer, inte skalbart, tungladdat, inte tillgänglighetsanpassat – och senare genom tekniker som Sifr där man använder flash och javascript.

Nu är det tekniskt möjligt

I och med Firefox 3.5 har faktiskt alla stora (och mindre) renderingsmotorer stöd för länkade typsnitt via @font-face. Internet Explorer har stöd för sitt specialformat embedded opentype (eot), Gecko-läsarna och Opera har stöd för truetype och opentype, och Webkit har stöd för truetype, opentype och svg-fonter.

Det enda hindret som finns kvar är att alla typsnittshus inte tillåter länkning av typsnitt i sina licenser. Det här är nog den mest omtvistade saken bland utvecklare, webbdesigners och typsnittsskärare när man diskuterat stöd för länkning. Naturligtvis finns det massor av typsnitt där det tillåts länkning, men så länge jag följt debatten har alltid fokus legat på de som inte tillåter och hur man ska tackla det.

För att skapa en ny sorts licens som tillåter länkade typsnitt har Small Batch Inc utvecklat något de kallar Typekit. Ambitionen har varit att lägga in ett kopieringsskydd, men utan att använda någon typ av DRM. När nu Andy ClarkeFor a beautiful web fått testa Typekit live har jag – nyfiken som jag är – grävt lite på hans sajt och kollat hur det hela är byggt. Det visar sig att man använda sig av webbläsarnas stöd för länkade typsnitt, men implementera länkningen via javascript byggt på Jquery och Sizzle. Ett extra lager av kod som tynger ner webbsidan (~60 KB extra javascript), slöar ner webbläsaren och inte tillför något skydd alls. För att förstå är det enklast att titta på den färdigrenderade sidan och alla filer länkade till den.

I Safari är det enklast att använda sig av den inbyggda webbgranskaren för utvecklare. Tryck bara kommando+alt+I för att visa den, och sedan på fliken Resurser för att se alla laddade filer. Sökvägen till filerna står under filnamnet, och det ska finnas en eller flera CSS-filer som laddas från code.typekit.com. Markera en sådan fil för att visa innehållet i den.

For a beautiful web

Det vi direkt ser är att det är CSS-filer med den vanliga syntaxen för @font-face, men med ett undantag. Istället för att peka på en font-fil under src så har man kodat binärfilen så att den kan läggas direkt i CSS:en.

base64-kodade typsnitt i CSS

Den första delen av koden är det intressanta, där det står src: url(data:font/otf;base64 i början på den långa strängen. Det är alltså data med MIME font/otf, vilket betyder att det är en opentype-font. Base64 är en kodning där man tar binärdata och kodar det med enbart bokstäverna a-z och 0-9. Den kodningen har en gång i tiden utvecklats som ett tillägg till e-post för att man ska kunna skicka bifogade filer inuti rena textdokument (vilket ett mejl är).

Lämpligt nog kan även webbläsare klara av att läsa den här typen av inbakad data i CSS eller HTML-dokument.

Avkoda fonten

Det vi behöver göra här är att kopiera den kodade fonten, formatera koden och avkoda den tillbaka till binärdata. Det här kräver lite handpåläggning, men är inte speciellt svårt.

Till att börja med kopierar vi hela kodsträngen, det vill säga allt efter src: url(data:font/otf;base64, (observera kommat) och fram till den avslutande parentesen. Klistra in hela rasket i ett nytt dokument i Subethaedit och se till att radbrytningarna är inställda på LF i dokumentet (längst ned till vänster).

Radbrytningar

Webbläsarna kräver att hela strängen ligger på en enda rad, precis som det vi kopierat, för att kunna avkoda datat. Men för att kunna avkoda i terminalen så måste textsjoket delas upp i rader om 64 tecken. Att göra det manuellt är inte speciellt roligt, så därför kan vi ta hjälp av den inbyggda motorn för sök och ersätt i Subethaedit. Den klarar av att hantera regular expressions, vilket är ett enkelt sätt att få den här typen av redigeringar gjorda automatiskt.

Subethaedit regex

Börja med att ta fram sök och ersättrutan (kommando+F) och se till att kryssa i RegEx. I formuläret så ska vi söka efter .{64} vilket betyder att vi matchar alla tecken (punkten) och vi upprepar matchningen 64 gånger i stöten. I ersättrutan skriver vi \0\n vilket betyder att allt vi matchade när vi letade ska behållas (omvänt snedstreck och noll) och följas av en radbrytning (omvänt snedstreck och n). Klicka på Replace All för att genomföra formateringen.

Base64 med radbrytningar

Efter det här ska filen sparas och läggas på lämpligt ställe. Förslagsvis på skrivbordet och döpt till (i det här fallet) Skolar.otf.b64 för att indikera typsnittsnamnet (Skolar) och att det är en opentype (otf) som är kodad som base64 (b64).

In i terminalen

För att avkoda filen kan vi använda Openssl i terminalen med kommandot
openssl base64 -d -in ~/Desktop/Skolar.otf.b64 -out ~/Desktop/Skolar.otf

Decoding

Nu är filen avkodad och ligger snällt på skrivbordet som en opentype vilken som helst. Dubbelklick på den så öppnas den i förhandsvisningsläge i Typsnittsboken.

Förhandsvisning

Visserligen gör Typekit att det blir ett par extra steg man måste gå igenom för att få ner fonten till datorn, men är man så pass bevandrad i webbdesign och -utveckling att man skulle klara av att plocka ner en font länkad på normalt sätt, så klarar man det här lika gärna. Att därför Typekit skulle lämna något extra skydd för kopiering av typsnitten är helt enkelt inte sant.

Vilket i och för sig är ganska logiskt eftersom webbläsaren kan läsa och visa typsnittet, och naturligtvis innebär att det även kan sparas till hårddisken.

Det verkar dessutom som att det inte är exakt samma font som levereras till olika webbläsare. Det är väldigt stor skillnad i vikt mellan Safari, Firefox och Opera i Clarkes tester.

Type does not look the same in every browser

Är det på det viset så är det oroväckande dåligt implementerat från Typekits sida, och vi får hoppas att de ser till att använda samma fonter till alla läsarna i framtiden. För att det skulle vara skillnad på hur läsarna renderar typsnitten, som Clarke antyder, verkar inte troligt och är inte något som jag själv märkt av när jag arbetat med länkade typsnitt.

Använd standarder som de var tänkta från början

Förutom Typekit och Microsofts EOT-format så finns det helt uppenbart massor av folk som gör sitt bästa för att lägga någon typ av DRM på fonter. Det senaste initiativet kommer från typsnittsskärarna Erik van Blokland och Tai Leming som lämnat förslag till W3C på ytterligare en paketering av opentype som de kallar webfont. I praktiken är det en zip med en XML-fil och binärdata sida vid sida, och som fungerar i princip likadant som en EOT.

Förhoppningen från min sida är att det här krånglet inte kommer att få något genomslag. Mycket bättre är det att använda sig av typsnitt där licensen tillåter länkning på webben, och att då använda sig av den korrekta metoden via @font-face och med vanliga fonter. På det viset kan man garantera likformighet mellan webbläsarna, och man har själv kontroll på hur implementeringen görs.

Att det skulle vara någon skillnad på att köpa ett foto av en fotograf och publicera på nätet, eller en font av en formgivare kan jag inte förstå. Det finns inte något krav eller någon debatt idag att man ska implementera kopieringsskydd för foton och illustrationer, och varför man då ska göra det för typsnitt verkar helt befängt. Allt handlar om att man är överens med den man köper fonten (eller bilden) av om hur man får använda den.

Enklare än så kan det knappast bli för någon av parterna.

Vad kommer det att sluta?

Eftersom alla läsare utom Internet Explorer har stöd för vanliga opentype, och ingen har stöd för DRM i någon annan form än Explorers EOT så kommer resultatet bli att opentype är det som kommer att användas. Typsnittsskärare och typsnittshus kommer att få finna sig i att formgivare och webbdesigners kommer att kräva en licens som tillåter länkning av normala fonter.

Det är dessutom superenkelt att framställa en EOT-variant av fonten som kan levereras separat via conditional comments till Internet Explorer. Framtiden för länkade typsnitt är äntligen här, och den är här på riktigt.

Hoppa högst upp på sidan