Webbdesign och typografi – så här fungerar det
Om du är designer och har en liten gnutta intresse av typografi så har du nog märkt att webben inte är en speciellt tacksam plats att formge. Framför allt den typografiska kontrollen har mycket kvar att önska. Som grundläggande kerning till exempel. Här reder vi ut vad som händer med texten i webbläsaren egentligen.
Vi har tidigare skrivit om hur man länkar typsnitt så att det fungerar i alla webbläsare. Nu är det ett ganska stort kliv framåt när det gäller typografi på webben, men det är fortfarande tydligt att det är tekniker som bygger webbläsare, skapar standarder för reglerna i CSS och HTML och bestämmer vad man som formgivare kan och inte kan göra.
Foto: Macbloggen
En av de saker man bör känna till är hur renderingsmotorerna i webbläsarna egentligen fungerar. Speciellt i förhållande till andra program som visar och hanterar text.
Nu kan man ju tro att det bara finns ett enda sätt att visa typsnitt på skärmen, men så är det inte. Det är upp till varje program att antingen använda Core text eller att tillhandahålla en egen layout- och redigeringsmotor. Oftare än man kanske tror så är det en egen text- och layoutmotor som ligger bakom det som visas på skärmen. Av de program jag använder dagligen är det bara Textredigeraren som använder systemets API:er. Den har stöd för väldigt avancerade typografiska funktioner som man sällan hittar i andra program än professionella layoutprogram. En sådan sak är stöd för opentype-funktioner som ligaturer och alternativa tecken via Apple advanced typography (vilket Textredigeraren stöder) som är ett API just för typsnittsrendering.
Renderingsmotorer och layout
Webkit, Gecko och Trident är i princip helt fristående layoutrenderingsmotorer som aldrig eller sällan använder systemets funktioner. Det här avspeglar sig i på vilket sätt de klarar av att hantera allt som inte är elementärt i layoutsammanhang. Ett stort tillkortakommande är att ingen utom Gecko kan läsa någon extrainformation från typsnitten. Det innebär att bokstäverna egentligen bara staplas efter varandra utan hänsyn till kerningstabeller, ligaturer eller kontextberoende teckenersättning.
Ett bra exempel på kontextbaserad teckenersättning är när man med typsnittet Zapfino skriver just ”Zapfino”
Typsnittet Zapfino har avancerade opentype-funktioner. Här i Textredigeraren.
Det som händer är att typsnittet är programmerat att byta ut just tecknen Z, a, p, f, i, n och o om de står efter varandra till ett annat tecken, eller glyf, i fonten. Det här kräver stöd i textredigeringsverktyget, och gör man samma sak i Safari blir det inte riktigt samma resultat.
Safari och Webkit klarar inte mer än standardtecknen.
Firefox med sin Gecko-motor klarar lite mer, men fortfarande inte kontextuell teckenersättning. Den är begränsad till ligaturer och mjuka ligaturer, men har inte – vilket är det normala beteendet – de mjuka ligaturerna avslagna som standardinställning. Vi får ett lite annat utseende i Firefox av den anledningen.
Ligaturer i Firefox.
Trots att även mjuka ligaturer är igång i Firefox så har den ändå ett stort försprång jämfört med de övriga läsarna. Den klarar nämligen av att läsa kerningstabeller. Den sak i ett typsnitt – förutom själva bokstavsformerna – som skiljer ett kvalitetstypsnitt från ett dussintypsnitt. Det blir påtagligt när man tittar på ett typiskt bokstavspar som kräver tillriktning för att se bra ut. Nämligen versala ”A” och ”V”.
Det övre paret är webbläsarens standardrendering, och det undre är korrekt tillriktat. För att generera referenstecknen används Cufón som är byggt med javascript och använder HTML5-elementet canvas tillsammans med SVG och VML för att fungera i samtliga webbläsare. Cufón klarar att bevara kerningstabellerna från typsnitten, men kan inte läsa ligaturer och andra opentype-funktioner.
Safari misslyckas kapitalt med kerningen.
Även i Explorer ser det risigt ut.
Firefox däremot fixar biffen.
Samma sak gäller egentligen alla funktioner i opentype och då även vanligt förekommande ligaturer som ”fi”, ”ffi”, ”fl” och liknande. Tittar man på dem i de olika läsarna så framträder samma sak där. Dessutom blir det tydligt vilka begränsningar Cufón har, eftersom det inte klarar kontextuella matchningar för att placera ut ligaturer.
Teckenpar som ska visas som ligaturer i Safari.
Samma sak med Explorer. Inga ligaturer genereras.
Firefox klarar ligaturer, men Cufón misslyckas.
Vad kan man lära sig av det här?
Det är inte mycket man kan göra åt renderingsmotorerna mer än att vara medveten om vad det är som sker bakom kulisserna. Oavsett om man vill använda länkade typsnitt eller systemtypsnitt hos besökaren så är begränsningarna i renderingsmotorerna desamma. Den enda vettiga lösningen för att få till kerningen är att använda Cufón, och i så fall är det smartast att begränsa den användningen till rubriker. Att generera all text på sajten med Cufón riskerar att slöa ner layoutrenderingen avsevärt.
Som alltid är det en avvägning mellan fördelar och nackdelar när man väljer teknik.