SVG naar ICO omzetten

De meeste iconomzettingen beginnen bij iets dat al eens gerenderd is — een PNG-export, een schermafbeelding, een JPEG die iemand ergens vond. Elk daarvan draagt de resolutie en de artefacten van wat het produceerde, en het verkleinen naar iconformaat stapelt dat op. Een SVG draagt niets daarvan: het zijn instructies, dus de renderer tekent het beeldmerk vers op precies de grootte die het icoon nodig heeft.

Dat betekent dat de randen eenmaal geanti-aliased worden in plaats van twee keer, krommes worden berekend in plaats van herbemonsterd, en er is geen zachte gloed van een eerdere export. Heb je de vector, gebruik hem dan. Dit is een van de weinige omzettingen waar de keuze van de bron echt in het resultaat zichtbaar is.

Een ICO is een container gebouwd om hetzelfde beeldmerk op meerdere groottes te bevatten, zodat Windows een scherpe versie van 16 pixels in een taakbalk kan tonen en een scherpe versie van 256 pixels op het bureaublad, zonder een van beide te schalen. Dat is wat hier geschreven wordt: de instelling "Iconformaten" bepaalt de set, de standaard is 16, 32 en 48, en elk is een aparte PNG met zijn alfakanaal intact. Kies "Alle gangbare formaten" en 64, 128 en 256 sluiten aan; kies "Alleen 256 px" en je krijgt in plaats daarvan het ene grote item.

Tweehonderdzesenvijftig is het eigen plafond van het formaat, geen keuze die hier gemaakt wordt. Een item legt zijn breedte vast in één byte, wat bij 255 stopt, dus reserveert de specificatie de waarde nul om 256 te betekenen — en dat is de byte die voor een icoon op volle grootte geschreven wordt. Er is nergens een groter icoon. De items worden grootste eerst geschreven, want een decoder die de directory negeert neigt te nemen wat hij het eerst tegenkomt, en de grootste is het minst slechte om te geven.

Bij de standaardset schaalt er niets: hij leest de directory, vindt een item dat al 16 pixels is, en tekent dat. Dat is het verschil waarvoor de container is uitgevonden, en het is zichtbaar — een beeld van 256 pixels dat een browser onderweg met een algemeen filter verkleint, verliest elke uitlijning die het beeldmerk scherp maakte, terwijl een item van 16 pixels eenmaal verkleind is, in een gefilterde stap, voor het bestand werd geschreven. Kies "Alleen 256 px" en de browser doet het schalen weer zelf.

Wat geen van beide regelingen kan is het beeldmerk opnieuw tekenen. Het item van 16 pixels hier is de verkleinde render van 256, niet de SVG opnieuw gerenderd op 16 met de lijnen op het pixelraster geknipt, dus een lijn van één pixel wordt nog steeds zachter en een teller binnen een letter loopt nog steeds dicht. Voor een solide vorm, een dikke enkele letter of een sterke silhouet is dat prima. Voor fijn detail niet, en daarom bevatten serieuze iconensets nog steeds een met de hand getekende 16 — zowel GIMP als IcoFX laten je er een toevoegen aan het bestand dat deze pagina geeft.

De beperking is meedogenloos en de moeite waard om je ernaar te schikken in plaats van ertegen te vechten. Zestien bij zestien is 256 pixels in totaal, minder dan de tekens in deze zin. Alles wat meer dan ongeveer drie verschillende vormen nodig heeft om leesbaar te zijn, leest niet.

De gebruikelijke zetten: het woordmerk helemaal weglaten en het symbool houden, lijnen verdikken zodat ze op hele pixels landen, contrast verhogen tegen zowel licht als donker, en detail kleiner dan een tiende van de breedte verwijderen. Omdat je vanuit een vector start, is een vereenvoudigde variant maken een kwestie van een paar lagen verbergen en een tweede SVG exporteren.

De afbeelding in het icoon is een PNG, dus het alfakanaal komt door de hele keten heen: resvg rendert de tekening op niets, de pixels houden hun transparantie, en de PNG slaat het op. Een afgerond beeldmerk houdt zijn afgeronde hoeken in plaats van een wit vierkant te krijgen.

Dat doet er meer toe dan vroeger. Browsers renderen tabbladenbalken nu in een lichte of donkere thema afhankelijk van het besturingssysteem, en een favicon met een ingebakken witte achtergrond verraadt zichzelf op een donker thema. Laat de achtergrond uit de tekening en laat de alfa zijn werk doen.

Moderne browsers accepteren een SVG-favicon rechtstreeks, en dat is strikt beter waar het ondersteund wordt: één klein bestand, scherp op elke grootte, en het kan reageren op een donker kleurenschema met een media query binnen de tekening zelf. De gebruikelijke opstelling is nu een SVG gedeclareerd in de markup en een ICO aan de root voor al het andere.

Dat is geen reden om het icoon over te slaan. Het verzoek om /favicon.ico wordt door browsers gedaan ongeacht wat de HTML zegt, en door een lange staart feedreaders, linkvoorvertoners en crawlers die geen HTML parsen. Beide bestanden, samen een paar kilobyte, en de vraag komt nooit meer terug.

Zet het bestand aan de root als favicon.ico. Die ene plaatsing voldoet aan het automatische verzoek en vereist helemaal geen markup — waarom het dertig jaar veranderingen op het web heeft overleefd.

Declareer dan de rest expliciet: een link-element met rel="icon" en type="image/svg+xml" voor de SVG, en een apple-touch-icon PNG op 180 pixels voor iOS, dat de andere twee negeert. Drie bestanden dekken elke huidige client, en het icoon is degene die geen declaratie nodig heeft.

Favicons worden met ongewone hardnekkigheid gecachet, in een aparte opslag los van de gewone paginacache, en een harde herlaad wist dat vaak niet. Dat levert een betrouwbaar paar minuten op waarin je denkt dat de omzetting mislukt is terwijl het bestand op de server perfect klopt.

Controleer het bestand rechtstreeks door zijn URL in een tabblad te openen, wat de iconcache volledig omzeilt. Verschijnt daar de juiste afbeelding, dan werkte de deploy. Om het tabblad te dwingen te vernieuwen, open de site in een privévenster, of voeg een querystring toe aan het link-element voor één deploy.

Niets in deze omzetting snijdt bij. De tekening wordt op zijn eigen verhoudingen gerenderd, en elk iconitem wordt daarna gemaakt door hem te centreren op een vierkant canvas op de grootste schaal die past — een brede viewBox krijgt dus transparante ruimte boven en onder in plaats van uitgerekt te worden. Het icoon wordt nooit vervormd, wat de juiste standaard is, maar een beeldmerk dat drie keer breder is dan hoog eindigt met een derde van het vierkant en oogt als een klein logo dat in een groot tabblad zweeft.

Los het op in de SVG. Zet de viewBox vierkant en plaats het beeldmerk erin met wat marge die goed oogt, in de wetenschap dat iconen meestal rand-aan-rand getoond worden zonder eigen padding. Een symbool dat zo’n negentig procent van het vierkant vult, leest goed op elke grootte, en op 16 pixels is het verschil tussen het kader vullen en een derde ervan vullen het verschil tussen vier leesbare pixels lijndikte en één.

Sleep de hele set erin. Elke tekening wordt apart gerenderd en verpakt en de resultaten komen terug als ZIP, wat de gebruikelijke vorm van deze klus is voor iedereen die meerdere sites of producten vanuit één merksysteem runt — één beeldmerk per eigenschap, allemaal dezelfde behandeling nodig op dezelfde middag.

Wat niet consistent is, is hoeveel van elk vierkant het beeldmerk vult: een tekening met een brede viewBox wordt gecentreerd met transparante ruimte ernaast, en naast een correct vierkant gemaakte buurman oogt hij een maat kleiner. De viewBoxen eenmalig vierkant maken in de bron is de moeite waard in plaats van het achteraf over een dozijn sites te merken.