[webdesign] Font embedding op webpagina

[Dacide]

Ik ben bezig met een website voor een industriële onderneming. Hun huisstijl gebruikt te allen tijde het Frutiger font. Dit Font willen ze graag terugzien op de nieuwe website.

Nu weet ik ook wel dat dit niet gebruikelijk is en dat web-safe fonts de voorkeur geniet.

Maar ik heb ook diverse dingen gelezen over Font embedding technieken. Wie kan mij vertellen welke techniek anno 2010 de voorkeur heeft?

De technieken die ik gelezen/gezien heb zijn:

• WEFT
• @Font-Face
• Flash replacing

Wat raden jullie mij aan?

[noes]

@font-face.

Werkt echt perfect, check http://www.fontsquirrel.com/ eens voor tips en voor het omzetten van je otf of ttf bestand naar alle mogelijke formaten. Krijg je ook meteen een demo CSS en HTML mee teruggestuurd, die kan je ideaal copy/pasten.

Voordelen:

- écht font, dus resizable/copy+paste mogelijk/en compatible met screenreaders etc.
- goede fallback naar compatible font mocht je font downloadlink niet werken
- net als andere technieken obfuscatiemogelijkheid en je kan het zo instellen dat je font niet te installeren is op de desktop.
- makkelijk: geen afhankelijkheid van JS, flash whatever.
- forwards compatible, CSS standaard.

Nadelen:
- soms zie je eerst even het websafe font voor je font gedownload is (afhnakelijk per browser)
- sommige browsers laten niks geen text zien tot je font gedownload is (of een fout geeft, ook afhankelijk per browser).

Web-safe fonts zijn niet leuk voor headers etc. Wat ik meestal doe is voor de headers/menu's etc. een custom font en voor de text gewoon verdana/arial/helvetica gebruiken. Zo weet je zeker dat het voor iedereen goed leesbaar is en dat alle karakters die in het CMS worden ingevoerd beschikbaar zijn (denk aan trema's, umlaut, euro/currencie tekens en alle andere speciale karakters).

[Bosmonster]

WEFT hoort helemaal niet in dat rijtje thuis, dat is een Microsoft-tool om webfonts te converteren (of zoiets, nooit aan de praat gekregen ). Het is in ieder geval antiek.

Flash replacement (sifr) is vandaag de dag ook geen optie meer mijnsinziens. Als je al font-replacement wilt doen, gebruik dan iets als Cufon.

Font-embedding middels font-face is prima bruikbaar, maar probeer het aantal fonts en de complexiteit ervan zoveel mogelijk te beperken. Hoe complexer het font, hoe langer het duurt om te renderen, aangezien dit on-the-fly gebeurt.

Ander nadeel is overigens ook dat de kwaliteit van de rendering te wensen over laat in veel browsers.

En ook iets belangrijks om rekening mee te houden is de licentie: Je mag niet zomaar ieder font gebruiken voor embedding, je zult hier de juiste licenties voor moeten hebben.

[ Voor 12% gewijzigd door Bosmonster op 13-10-2010 12:34 ]

[Dacide]

Ok, duidelijk verhaal.

@font-face is dus de meest bruikbare oplossing.

Zit nu wel met het punt dat Frutiger (het font dat ze graag willen gebruiken) geen gratis font is. Wellicht dat ik in de knoop kom met copyright. Ik kan uiteraard wel uitkijken naar een free font dat sterk lijkt op frutiger.

[noes]

Cufon heeft een groot nadeel voor kleinere fonts: wordt vaag. Tevens is het met cufon lastig om bijv met een hoverstate (:hover) een andere kleur te definieren, dat moet je dan ook weer aangeven in Cufon. Ook is het niet compatible met IE9. Eerst gebruikte ik ook Cufón in mn projecten (ben professioneel front-end developer, dus dat zijn er nogal wat), maar heb dat allemaal vervangen voor @font-face.

Bosmonster heeft idd gelijk mbt WEFT, dat is een tool om fonts om te zetten naar EOT. Dat heb je nog wel nodig voor IE, maar dat laat ik fontsquirrel doen (zie mn vorige post in deze thread). WEFT is onnodig gecompliceerd.

@Bosmonster: Kwaliteit van de rendering is goed als je (zoals per default) cleartype aan hebt staan in Windows (of vergelijkbare font-smoothing in een ander OS). Zonder dat wordt het wel wat korrelig, maar dat is normaal en ook zo bij alle 'web-safe' fonts.

Tevens, wat je zegt over font-embedding mbhv @font-face geldt juist voor Cufon ipv @font-face: Cufon werkt dmv Javascript Canvas elementen invoegen en die in te tekenen, waar @font-face gebruik maakt van de in de browser gebruikte textrendering engine. Cufon belast de processor meer.

Kortom: of je helvetica.otf of 'jouwspecifiekefont.otf' er door heen trekt, maakt voor de browser niet uit. Enige verschil wat je hebt is dat het font apart moet worden gedownload, maar dat geldt ook voor de Cufon .js bestanden. Voor @font-face moet je browser dan wel een EOT inladen (IE), danwel SVGZ (mijn favoriet, niet te installeren door de gebruiker)/OTF/WOFF. Als voorbeeld heb ik hier het font Hermes FB Black:
EOT is 54k (IE only),
SVGZ is 19k (alle overige browsers),

Cufon font file is 46k,
cufon-yui.js is 18k,

(totaal is dus 46+18 = 64k vs dan wel 54 dan wel 19k).

Inserting van de techniek is ongeveer gelijk, ~5 regels JS vs ~5 regels CSS.

Natuurlijk moet je gebruiken wat je zelf het beste/makkelijkste vind en wat er in jouw ogen het beste uitziet.

PS: SIFR is in mijn ogen ook geen optie: is afhankelijk van flash en belast de CPU veel meer dan Cufón JS/@font-face CSS.

[alex3305]

Wel heeft Bosmonster gelijk dat er weleens problemen kunnen ontstaan met de rechten. Het is namelijk zo dat sommige fonts wel door middel van sIFR geëmbedt mogen worden, maar dat werkelijke insluiting van zo'n font niet toegestaan is.

[noes]

alex3305 schreef op woensdag 13 oktober 2010 @ 13:16:
Wel heeft Bosmonster gelijk dat er weleens problemen kunnen ontstaan met de rechten. Het is namelijk zo dat sommige fonts wel door middel van sIFR geëmbedt mogen worden, maar dat werkelijke insluiting van zo'n font niet toegestaan is.

Dat klopt, daarom gebruik ik alleen EOT en SVGZ: zodoende is het font wel te downloaden maar niet te installeren op de pc van de bezoeker, hangt af van de licentievoorwaarden of dat uitkomst biedt. Ook kan je in je CSS de call base64 encoden, maar het nut daarvan zie ik niet volledig in.

Nog een mogelijkheid: bij de producer van het font (of de foundry, zoals ze ze vaak noemen) een uitgebreide licentie kopen dat embedden middels een niet te installeren fontfile wel kan/mag, is meestal wel een stuk duurder (maar dat bereken je gewoon door aan de klant )

[ Voor 7% gewijzigd door noes op 13-10-2010 13:30 . Reden: extra info ]

[RobIII]

Kijk ook eens naar de Google Font API met bijbehorende fonts.

[Bosmonster]

http://webfonts.fonts.com/ is ook een redelijke resource voor webfonts. Nadeel blijft wel dat je vaak weinig controle hebt over de fonts en manier van implementeren (met name met Google Font API) en je ook de fonts van een externe resource haalt, wat soms wat performance issues op kan leveren.

Wat betreft rendering, zelfs met ClearType aan is de rendering niet al te best onder Windows Het lijkt alsof anti-aliasing maar zeer beperkt toegepast wordt soms.

[ Voor 8% gewijzigd door Bosmonster op 13-10-2010 14:02 ]

[noes]

RobIII schreef op woensdag 13 oktober 2010 @ 13:48:
Kijk ook eens naar de Google Font API met bijbehorende fonts.

Google font API is niks anders dan @font-face in een CSS bij google op de server dat refereert naar een daar verkrijgbaar font. Kan makkelijk zijn, maar liever heb ik alles in eigen beheer. (kijk maar: http://fonts.googleapis.c...ly=Cantarell&subset=latin). En met fontsquirrel wordt het wel makkelijk voor je klaargezet. Trouwens.. die googleAPI níet gebruiken bij een HTTPS pagina: je krijgt in sommige browsers dan de melding dat delen van de pagina niet veilig zijn ingeladen. Dat ziet er op zn minst slordig uit

Trouwens, bij fontsquirrel heb je de bulletproofing opties, kies daar voor de smileyhack, die werkt het beste crossbrowser (is mijn ervaring).

Bosmonster schreef op woensdag 13 oktober 2010 @ 14:01:
http://webfonts.fonts.com/ is ook een redelijke resource voor webfonts. Nadeel blijft wel dat je vaak weinig controle hebt over de fonts en manier van implementeren (met name met Google Font API) en je ook de fonts van een externe resource haalt, wat soms wat performance issues op kan leveren.

Wat betreft rendering, zelfs met ClearType aan is de rendering niet al te best onder Windows Het lijkt alsof anti-aliasing maar zeer beperkt toegepast wordt soms.

En true, het ene font rendert mooier dan het ander. Echter heb ik persoonlijk liever een font wat iets korrelig wordt weergegeven door te weinig antialias (wat kan gebeuren bij @fontface) dan een font wat wazig is (bij Cufón in kleine lettertypen). Mooi dat we allebei erg fervent voorstanders van een specifieke techniek zijn

[8088]

noes schreef op woensdag 13 oktober 2010 @ 14:37:
Trouwens.. die googleAPI níet gebruiken bij een HTTPS pagina: je krijgt in sommige browsers dan de melding dat delen van de pagina niet veilig zijn ingeladen. Dat ziet er op zn minst slordig uit

Dat is te ondervangen door een s aan http toe te voegen bij het linken naar de stylesheet, de link naar het font wordt aansluitend aangepast. Jouw voorbeeld wordt dan als volgt: https://fonts.googleapis....ly=Cantarell&subset=latin

[Bosmonster]

Ik ben uberhaupt geen voorstander van niet-webfonts. Het is uiteindelijk kiezen tussen 2 kwaden als je het mij vraagt vooralsnog.

Maar ja.. designers he..

[noes]

8088 schreef op woensdag 13 oktober 2010 @ 14:43:
[...]

Dat is te ondervangen door een s aan http toe te voegen bij het linken naar de stylesheet, de link naar het font wordt aansluitend aangepast. Jouw voorbeeld wordt dan als volgt: https://fonts.googleapis....ly=Cantarell&subset=latin

Handige tip, wist niet dat die API's ook op HTTPS bereikbaar zijn

Bosmonster schreef op woensdag 13 oktober 2010 @ 14:44:
Ik ben uberhaupt geen voorstander van niet-webfonts. Het is uiteindelijk kiezen tussen 2 kwaden als je het mij vraagt vooralsnog.

Maar ja.. designers he..

Hey het oog wil ook wat ik vind t een uitkomst vs plaatjes embedden met daarin de text of andere manieren om je huisstijl goed in de website te laten leven. Fonts zijn daar nou eenmaal belangrijk in..

[ Voor 35% gewijzigd door noes op 13-10-2010 14:53 ]

[Bosmonster]

Fonts zijn eigenlijk alleen belangrijk voor de designer. De gebruiker zal het aan zijn of haar anus oxideren. Die zien het verschil tussen fonts meestal niet eens.

[RobIII]

noes schreef op woensdag 13 oktober 2010 @ 14:37:
Google font API is niks anders dan @font-face in een CSS bij google op de server dat refereert naar een daar verkrijgbaar font.

Euh, nee.

quote: http://code.google.com/ap...nical_considerations.html

When a browser sends a request for a Font API stylesheet (as specified in a <link> tag in your web page), the Font API serves a stylesheet generated for the specific user agent making the request.

Als je het goed implementeert heb je ondersteuning voor:
[q=http://code.google.com/apis/webfonts/faq.html#Browsers_Supported]
• Google Chrome: version 4.249.4+
• Mozilla Firefox: version: 3.5+
• Apple Safari: version 3.1+
• Opera: version 10.5+
• Microsoft Internet Explorer: version 6+

noes schreef op woensdag 13 oktober 2010 @ 14:37:
Trouwens.. die googleAPI níet gebruiken bij een HTTPS pagina: je krijgt in sommige browsers dan de melding dat delen van de pagina niet veilig zijn ingeladen. Dat ziet er op zn minst slordig uit

Wat 8088 dus zegt; en datzelfde geldt overigens ook voor Google Analytics en zovele andere producten.

[ Voor 44% gewijzigd door RobIII op 13-10-2010 15:04 ]

[Dacide]

Nou, het gebruiken van een specifiek (niet standaard) font kan wel een gevoel van kwaliteit uitstralen. Maar je hebt natuurlijk gelijk dat font gebruik vooral voor de opdrachtgever en de designer van belang zijn.

Los hiervan... Wens van opdrachtgever is om frutiger als font te hanteren. Blijkt dat dit niet gemakkelijk gaat, dan stemmen ze ook wel in bij het gebruik van web-safe fonts.

Ik ga eens aan de slag met @font-face (evt in combi met het kopen van een extended font licentie)

[8088]

Bosmonster schreef op woensdag 13 oktober 2010 @ 14:56:
Fonts zijn eigenlijk alleen belangrijk voor de designer. De gebruiker zal het aan zijn of haar anus oxideren. Die zien het verschil tussen fonts meestal niet eens.

Vergeet de opdrachtgever niet ;-)
^{Of die wel of niet het verschil ziet laat ik in 't midden...}

[noes]

RobIII schreef op woensdag 13 oktober 2010 @ 15:01:
[...]

Euh, nee.

[...]

Als je het goed implementeert heb je ondersteuning voor:
[...]

Als je @font-face goed implementeert heb je ondersteuning voor dezelfde lijst, want de google API serveert gewoon @font-face in een CSSje, ook naar IE (maar dan met een andere URL ivm EOT ipv SVGZ/WOFF/OTF). Test het maar uit in IE en daarna in bijv. Firefox.

Een ander resultaat dan @font-face heb ik nog niet gezien. En de manier van implementeren houdt ook in dat er niks anders dan een CSS terug kan komen.

code:

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Tangerine">

En dan rest de vraag: waarom afhankelijk zijn van een externe partij als je het zelf even goed kan met nauwelijks meer moeite?

[8088]

noes schreef op woensdag 13 oktober 2010 @ 16:21:
En dan rest de vraag: waarom afhankelijk zijn van een externe partij als je het zelf even goed kan met nauwelijks meer moeite?

Een request minder en wellicht caching. Moet 't natuurlijk wel populair worden.

[RobIII]

noes schreef op woensdag 13 oktober 2010 @ 16:21:
Als je @font-face goed implementeert heb je ondersteuning voor dezelfde lijst, want de google API serveert gewoon @font-face in een CSSje, ook naar IE (maar dan met een andere URL ivm EOT ipv SVGZ/WOFF/OTF).

Dus er is wél een verschil Daarbij zijn EOT's ruk om te maken dus is 't fijn dat dat voor je gedaan wordt. En als je gebruik maakt van de Google Font API (dus een stukje JS) dan is de response weer anders; maar dat is even uit 't blote hoofd en ik kan me vergissen.

noes schreef op woensdag 13 oktober 2010 @ 16:21:
En de manier van implementeren houdt ook in dat er niks anders dan een CSS terug kan komen.

Nogmaals: even uit de blote bol, maar als ik me niet vergis sturen ze soms ook behaviours oid terug (ik meen voor IE6) mbv een @import in de CSS

noes schreef op woensdag 13 oktober 2010 @ 16:21:
En dan rest de vraag: waarom afhankelijk zijn van een externe partij als je het zelf even goed kan met nauwelijks meer moeite?

Maar dus meer moeite. Daarbij is 't niet 'zomaar' een externe partij net als een elcheapohosting.tld die met regelmaat down kan zijn ofzo. En daarbij gebruik je het dus meteen als CDN waardoor je pagina sneller kan laden wegens geografisch slim geplaatste servers van Google (dus de "beste" responsetijden afhankelijk van je locatie) en er zijn meer gelijktijdige HTTP requests mogelijk omdat ze van een apart domein geserveerd worden. En het scheelt je bandbreedte. En mogelijke caching omdat een bezoeker op een andere site mogelijk hetzelfde font al eens geladen heeft. En je bent er zeker van dat licentietechnisch alles in orde is (en anders kun je naar Google wijzen als ze komen aankloppen )

Lijkt me genoeg voordelen

[ Voor 8% gewijzigd door RobIII op 13-10-2010 17:19 ]

[Bosmonster]

Het voordeel van de externe partijen is dat zij de licenties en beveiliging van de fonts beheren. Vaak betaal je een vast tarief (of is het zelfs gratis) en verzorgen zij de licenties, aangezien zij het font aanbieden cq hosten.

RobIII schreef op woensdag 13 oktober 2010 @ 17:17:
[...]

Dus er is wél een verschil Daarbij zijn EOT's ruk om te maken dus is 't fijn dat dat voor je gedaan wordt. En als je gebruik maakt van de Google Font API (dus een stukje JS) dan is de response weer anders; maar dat is even uit 't blote hoofd en ik kan me vergissen.

Iets als fontsquirrel doet dat ook allemaal voor je in een seconde. Krijg je netjes al je fonts en een xbrowser css. Dat is geen reden om iets als de Google Font API te gebruiken.

Als er iets nadelig aan is zelfs is het dat die API alleen werkt met javascript, wat in dit geval helemaal niet nodig is. Daarnaast zit je met performance en het feit dat ze de useragent uitlezen die niet altijd even betrouwbaar is.

[ Voor 69% gewijzigd door Bosmonster op 13-10-2010 18:04 ]

[RobIII]

Bosmonster schreef op woensdag 13 oktober 2010 @ 18:01:
Als er iets nadelig aan is zelfs is het dat die API alleen werkt met javascript

De API is, AFAIK, alleen een aanvulling op wat anders enkel een stylesheet is.

Bosmonster schreef op woensdag 13 oktober 2010 @ 18:01:
Daarnaast zit je met performance en het feit dat ze de useragent uitlezen die niet altijd even betrouwbaar is.

Over welke performance hebben we het nu? En die useragent uitlezen is voor gewoon gebruik betrouwbaar genoeg (en ze hebben een fallback als er vage meuk in staat). Enkel lui die met hun useragent liggen klooien (en dat zijn er bar weinig) lopen kans een verkeerde stylesheet te krijgen. En het ergste dat je dan gebeurt is dat er een fallback font gebruikt wordt. Poehee

Ik ben echt geen enorm Google (Fonts) aanhanger ofzo, maar ik vind 't best aardig werken.

[ Voor 5% gewijzigd door RobIII op 13-10-2010 18:35 ]

[SpaceK33z]

De - naar mijn mening - beste oplossing is de oplossing die in het magazine Web Designer stond. Ik heb hem even kort voor je overgetypt, ik hoop dat je er iets aan hebt zodat ik 't niks voor niks over typ.

1. Lettertypes toevoegen
Ga naar http://fontsquirrel.com/fontface/generator en voeg een lettertype toe (in dit geval dus dat font wat je moest gebruiken). Kies de expert modus.

2. De instellingen
In die instellingen kun je aangeven in welke formaten het lettertype omgezet moet worden. Experimenteer met deze instellingen!

3. Kit downloaden
Klik op de Download Your Kit-link en open het zip-bestand.

4. Code in je CSS
Web Designer heeft de code een beetje aangepast, dus waarschijnlijk kun je deze beter gebruiken. Als voorbeeld heb ik de Museo Sans font gepakt.

Cascading Stylesheet:

@font-face {
   font-family: 'bodytekst';
   src: url('fonts/museosans_300-webfont.eot'), local('fonts/Museo Sans 300'), local('MuseoSans300'),
   url('fonts/museosans_300-webfont.woff' format('woff'),
   url('fonts/museosans_300-webfont.otf' format('opentype'),
   url('fonts/museosans_300-webfont.svg#webfontCBTSrJKn' format('svg');
}

Hopelijk heb je hier wat aan .

[Bosmonster]

Je mist het stukje over het aanschaffen van de juiste licentie

[noes]

RobIII schreef op woensdag 13 oktober 2010 @ 17:17:
[...]

Dus er is wél een verschil Daarbij zijn EOT's ruk om te maken dus is 't fijn dat dat voor je gedaan wordt. En als je gebruik maakt van de Google Font API (dus een stukje JS) dan is de response weer anders; maar dat is even uit 't blote hoofd en ik kan me vergissen.


[...]

Nogmaals: even uit de blote bol, maar als ik me niet vergis sturen ze soms ook behaviours oid terug (ik meen voor IE6) mbv een @import in de CSS


[...]

Maar dus meer moeite. Daarbij is 't niet 'zomaar' een externe partij net als een elcheapohosting.tld die met regelmaat down kan zijn ofzo. En daarbij gebruik je het dus meteen als CDN waardoor je pagina sneller kan laden wegens geografisch slim geplaatste servers van Google (dus de "beste" responsetijden afhankelijk van je locatie) en er zijn meer gelijktijdige HTTP requests mogelijk omdat ze van een apart domein geserveerd worden. En het scheelt je bandbreedte. En mogelijke caching omdat een bezoeker op een andere site mogelijk hetzelfde font al eens geladen heeft. En je bent er zeker van dat licentietechnisch alles in orde is (en anders kun je naar Google wijzen als ze komen aankloppen )

Lijkt me genoeg voordelen

Ok true, geen elcheapo's, maar wel een externe afhankelijkheid. Ik, maar dat is waarschijnlijk persoonlijk, haat afhankelijkheden. Als er een storing is bij Google doet je font het niet, terwijl als er een storing is op je eigen hosting/site, je site én font het niet doen

Behaviours zijn trouwens niet nodig voor font embedding, IE heeft vanaf 5.5 support hiervoor (met EOT dan, zoals nog immer).

Caching maak ik me geen zorgen over, zoals ik in een eerdere post al opsomde is het dataverbruik voor je font dusdanig klein dat dat geen punt is en wordt het font gecached zodra de eerste pagina van je site wordt geladen. Gezien de meeste sites best wat plaatjes hebben, maakt een fontje meer of minder ook niet uit. Tevens zet ik, wat ook een goede tip is, @font-face bovenaan de CSS die als eerste wordt ingeladen. Zodoende wordt deze vóór alle eerdere elementen ingeladen en vervolgens gecached.

Moeite vind ik eenmalig en, dmv alle hulp die bijv. fontsquirrel biedt, ook erg klein.

Licentietechnisch is het handig, dat klopt, maar als je je zaakjes goed regelt hoef je je daar ook geen zorgen meer over te maken En als je je fonts netjes aanschaft heb je een veel grotere keuze welk font je wil, itt de google font API, waar je een uit hun selectie moet kiezen.

Overigens, RobIII, ik vind het ook best aardig werken, maar te weinig meerwaarde bieden anders dan dat font embedding weer een sterke medestander heeft, dat is meer mijn punt.

Goede discussie wordt dit overigens

Kees Kluskens schreef op woensdag 13 oktober 2010 @ 20:03:
De - naar mijn mening - beste oplossing is de oplossing die in het magazine Web Designer stond. Ik heb hem even kort voor je overgetypt, ik hoop dat je er iets aan hebt zodat ik 't niks voor niks over typ.

1. Lettertypes toevoegen
Ga naar http://fontsquirrel.com/fontface/generator en voeg een lettertype toe (in dit geval dus dat font wat je moest gebruiken). Kies de expert modus.

2. De instellingen
In die instellingen kun je aangeven in welke formaten het lettertype omgezet moet worden. Experimenteer met deze instellingen!

3. Kit downloaden
Klik op de Download Your Kit-link en open het zip-bestand.

4. Code in je CSS
Web Designer heeft de code een beetje aangepast, dus waarschijnlijk kun je deze beter gebruiken. Als voorbeeld heb ik de Museo Sans font gepakt.

Cascading Stylesheet:

@font-face {
   font-family: 'bodytekst';
   src: url('fonts/museosans_300-webfont.eot'), local('fonts/Museo Sans 300'), local('MuseoSans300'),
   url('fonts/museosans_300-webfont.woff' format('woff'),
   url('fonts/museosans_300-webfont.otf' format('opentype'),
   url('fonts/museosans_300-webfont.svg#webfontCBTSrJKn' format('svg');
}

Hopelijk heb je hier wat aan .

Volgens bovenstaande stappen werk ik ook, maar dan, zoals Bosmonster al opmerkte, met stap 0: font + licentie aanschaffen.

[Dacide]

Heel erg bedankt voor alle input en reacties.

Ik heb vanmiddag een afspraak met de opdrachtgever en zal de mogelijkheden (+kosten ivm licenties) bespreken.

[Dacide]

http://www.smashingmagazi...-font-embedding-services/

[noes]

Dacide schreef op dinsdag 26 oktober 2010 @ 09:46:
http://www.smashingmagazi...-font-embedding-services/

Ook leuk. Let wel, dit zijn allemaal abonnementsdiensten. Een font aanschaffen en converteren+embedden (zelf) zal waarschijnlijk goedkoper zijn.

Maar, je hebt nu wel een hele hoop info om een keuze te maken

[Dacide]

das sowieso... Maar dit artikel was slechts ter info/aanvulling van hetgeen hier besproken werd.

Ik ben in afwachting van mijn opdrachtgever (licentie kopen ja/nee)

[deCube]

Welke licentie schaffen jullie aan?

Een standaard licentie van bijv. eenmalig € 30,- of bijv. een Web Server licentie speciaal voor het embedden van fonts? Wat kost zo'n licentie extra?

Leesvoer: http://www.fonts.com/FontServices/FontEmbedding.htm.

[alienfruit]

Je kan gewoon //mijnadres.nl gebruiken dan pakt ie de juiste protocol. Stukken makkelijker

[DiSiLLUSiON]

Iets om in het achterhoofd te houden: Hoewel SiFR outdated is en wat nadelen heeft (cacheing werkt vaak niet lekker, flash plugin benodigd etc), is het helaas de enige optie als je wat aparts moet doen met je headers zoals masking of het een kleurverloop geven. Al zal dit (als het goed is) zeer, zeer weinig voorkomen.

[ Voor 6% gewijzigd door DiSiLLUSiON op 17-11-2010 18:47 ]

[Bosmonster]

Als dat moet in html dan wordt het tijd dat je de designer eens om de oren slaat

[DiSiLLUSiON]

Tja, die wilde ideën van ze altijd, niet waar?

[ Voor 16% gewijzigd door DiSiLLUSiON op 18-11-2010 14:36 ]