So we're going to talk about faster and more secure web fonts and really there are four elements to this talk So first we're going to go into a little bit of the the history of how we get from the earliest sort of web font technology to Today which we have waft and then like what comes next. We're going to talk about methods to To optimize and make your web fonts faster and to deploy your own web fonts We're going to talk about some problems that exist in some browsers and we're going to talk about what the future holds for web Fonts, which is pretty interesting. So let's begin by talking about history. So first of all people have been trying to use fonts on the web or unambitious device for a really really long time and In fact, you know 2000 and 2005 is sort of like the year that I put here But in fact the technology actually lasts way longer than that and this is probably the first one It's from bit stream, which is a company that resells and and make funds and they have a technology called chew dock That actually surprisingly enough the embed fonts to use on like TV set top boxes so this is the days when these were the days when You remember like internet TV, right?  So this because the TV doesn't have like embedded fonts like the set top box It is going to sort of provide that font, right? So bit stream has the technology to like To embed fonts into the set top boxes to be used on TV So that's sort of where the earliest sort of like fun emitting technology came from It's pretty advanced. It does multiple Language scripts that actually renders pretty well and it happens to renders very well in Browser as well because guess what if you have a an internet set top box You're going to have a browser because you need to browse the internet. So it's compatible with Netscape 4 and Netscape 6 and the browser Mozilla 1.0 so That was chewed up and next we come into Microsoft because Microsoft got interested in this idea and They call it something like embedded open type or EoT is the file format the extension is in fact EoT the development stopped in 2008, but it works in You know it worked all the way from IE 4. So if you're looking for Like browser compatibility, you can actually like generate an EoT file and use it in IE 4 5 and 6 and like you know like things that don't support WAF actually supports EoT So if you're looking for a solution that like skills back EoT is sort of like the way to go even though It's interesting. It's not sport anymore, but there you go So EoT is is basically use as a subset I'll talk about subset in a little while But it combines the fact that a font can be made smaller by splitting it into multiple parts and then Compressing those little multiple parts so they get downloaded faster saves more bandwidth loads faster, etc, etc of course the problem is There's the decryption method is not open in fact it's proprietary and it's a secret that sort of helped by Microsoft And this is the reason why Licensing became complex and the technology never got adoption Some of you might be familiar with this Right, so siffer is pretty simple where you load a page you designate some ID or some class or some div It's like hey look I want to replace this text with a Flash element and then replace that flush element and render render text on it right using a custom font create a flash movie You draw it with action script, etc, etc It was popular, but then it's abandoned because you know it doesn't work for a long text, right? So like if you try to implement a long body of text using siffer you can't select it You can copy and paste right because back then flushes is Is sort of not not not very good. So and plus the ad blocker issue The next solution is coupon some of you might might realize this right in 2009. So the way that coupon works, right? It's basically you have a true type or open type font format, right? That is converted to like SVG because browsers can you know like browsers actually supports SVG right from a pretty long time ago So there's it and it's an Adobe standard, but like browsers for it's a long time ago So they pass it they convert the font into SVG and then the SVG is rendered To like an HTML5 canvas element, right? So it's not like it, you know, so it's like SVG rendered into canvas elements And the drawing is then done into a separate rendering engine on JavaScript. So it's actually pretty sort of like it's pretty complicated It's not happy. You can actually select like a coupon block of text and copy and paste this pretty Simple so coupon was sort of going successful Except that it it requires due to its licensing it actually requires every font That is used with coupon to also have a generous distribution license and if you know type fondries They want a secure solution that won't leave their fonts in jeopardy Where somebody can just like go in download a font file install it in their computer and just rip off fonts on the web Right because I can do like what's stopping me from doing a Google search for like give me OpenSense.ttf right and then like oh Google finds it for me. I'll just download it, right? So coupons not secure that way because by design it's it has an open life It's sort of like a canoe license, right? It's like an open license But then I have to also the font has to be released like that. So we'll go over waft a little bit later Because that's sort of the solution that everybody adopts today But that's sort of the the the short history of how we got here today So next we're gonna talk about three methods to Make your to sort of like deploy your own fonts and make your web fonts faster as well So first we're gonna talk about sub settings. So what's upsetting? So sub setting means splitting one font file into multiple parts and just discarding the parts that you don't need We're gonna talk about embedding and embedding means I mean today these days It means converting the font into a base 64, you know and coding it into a base 64 thing Which actually the browser renders pretty, you know like faster than a than a than a TTF or an OTF file Versus just directly linking to the font file, right? So instead of like saying in the CSS Hey, give me the font TTF you say in the CSS. Well, here's the data file So you have a larger CSS rather than a larger font file and third we're gonna talk about waft and compressing using waft so I Did a presentation like this about two years ago when waft was sort of still You know, it's not sort of final that waft is going to be the standard or like what, you know, like different web font services Came about so my principle two years ago. It's that hey look if you're gonna embed a font on the web It should be just like a plain TTF or like a plain OTF because every browser supports it Let's not worry about any encryption or or decryption or any sort of proprietary stuff because it creates the best user experience So what do I mean by the best? Well? It's the fastest like two years ago browsers weren't sort of fast enough in in interpreting basicly for encoded data for instance, right? it's most compatible at that time with you know with like chrome with with the early chrome with Firefox and with Internet Explorer and It's also least complex, which means less bugs, right? Of course that principle is not true today because font foundries and font distribution channels and Web developers, you know, everybody has to sort of agree that hey look waft is the way to go So let's use that basics before embedding is also the way to go So let's use that so they've sort of agreed on some sort of a stack that everybody develops Everybody sort of does it the same way there might be Different optimization that comes from oh, I'm using like Amazon's AWS or I'm using my own server, you know, I split my fonts the same way I split my fonts different way, but really the method is sort of the same So you go to Google web fonts or you go to typekit you go to every font provider out there in this You know, they use the same sort of technology stack But this means that very few people are doing it themselves, right? But like I sort of do it myself in sort of my small experimental website But if I'm gonna deploy like a large website, I probably would rely on a third-party service, right? Because it's just simpler. It's just like one line of jazz So I think it helps to sort of know how to do it So you sort of know how it works and even then if you work or if you use a third-party service Then you know how it works, right? So let's talk about subsetting. So what does subsetting mean? Well, it's putting one font file into multiple parts Obviously But you can also split it logically, right? And this is what it means. So every font has a unicode For example, this is the unicode for the basic Latin character sets, which has fluctuations right uppercase lowercase numerical characters This is the Latin one supplement, right, which has, you know, all sort of like the diacritics additional punctuations And it has the currency symbol right the maths the number forms punctuations, you know all of that So all of this is the sort of the unicode center so a font has a big unicode table and Basically, we're going to split fonts into like logical parts and just load the parts that we need No surprise there most web fonts provider has this if you go to Google fonts It actually asks you hey, are you gonna be using Latin? Are you gonna be using Greek? Right, are you gonna be using whatever right? So the thinking goes that if you don't need to use Greek don't select Greek And so you can avoid downloading like a 500 kilobyte font file and just have the Latin if you just need Latin, right so This is where I get my unicode range which I insert into my CSS and This is how the code works. We are going to use a CSS unicode range property This is a standard CSS, right? It's just a standard CSS I'm just emitting the font in sort of a naked way just like linking to the font and here we go There's the special bit. So I'm going to specify that hey look For this font, I only you know like this font only contains the basic Latin character sets and nothing else Right, so this makes the font loads faster. That's this tells the website This tells the client machine which character is loaded In Google web fonts you use this which is you know, which is a more sort of like readable format Right, so in Google funds, you can say hey, I just want the Latin one, right? Also in unicode, you can just say look I just want so unicode. So that's unicode 41 right that's code for Capital letter a so this is the same if this is if you do it in font phase This is how you do it if you do it in Google you do it this way Right, so really the real benefit actually comes from the fact that a lot of documents are really just set in one language or Not a few languages means that hey look if you don't need to use You know like if you don't need your upset to be set in in in Greek or or Cyrillic characters or Vietnamese Then don't use that right and just make it smaller so just load what you use and Let me let me let me tell you what that means. So going to go to a demo now I use an open-source program called font forge and I have loaded a font. Let me see which I will pull here There you go. Minimize front forge All right All right, sweet You know, it's a fun for to sort of not designed to be to be pretty but You know, he's just got to work with what you got. So let me just move it There it is. Okay, so let me just let me just open a font right here Let me see library Stop droid sense. Ah, there we go. Right. So in this example, I'm just gonna open a font called droid sense, right? And let me just make the view. Let me just make this little smaller There you go. Right sweet Okay, so this is font forge and really sub setting is no more than this, right? Oh, I only need to use just the uppercase and the lower case I'm just gonna select this and I'm just gonna abandon the rest, right?  But it's upsetting is no more than that, right? Because uh, you know for example in this example Droid sense has multiple characters and yet I'm just selecting a Latin one, right? And you can do this yourself or you know what the third-party Sort of web fonts provider does is they essentially automate this Process for you so that what happens is then they create something like this, right? What happens is they create something like this You know like this is the droid sense, right? And then they split it. Oh, I just want droid sense with just symbols I want one with just numbers. I want one with lower case I want one with you know different character sets and then they put it behind checkbox, right? So really sort of this is sort of what they do and it's nothing more simple than that So you can do it yourself using open source tools and sort of just deploy your own web You know you deploy your own web fonts and it doesn't have to be slow, right? so that is Subsetting so really really simple and here's the result from a tech, you know from a test that I do for Droid sense so Droid sense has all of this characters The full size. This is the regular weight. It's 217 kilobyte So when I split it into just the Latin character that I need It's you know the size improvement is dramatic right 36 kilobyte 80 kilobyte Even if I just subset it to a serial a characters which also has a lot of characters again It's smaller than that 217 the Greek is also smaller the Vietnamese is smaller, right? So again just by splitting fonts into multiple parts and just not loading everything else that you don't need You're just gonna get a better performance So now what if we subset it further, right? So sure we only use Latin, but let's subset it again. So this is Latin This is the you know, this is the basic Latin character sets So why don't we split it into uppercase and lowercase numerals and punctuations, right? So, you know, what's stopping me from doing that? Well, in fact, it's pretty easy to do so again This is the CSS code So instead of doing just one font file, right now I want to do multiple ones, right? So I want gentium one I want gentium two and I want gentium three these are just file names that you can sort of just rename sort of arbitrarily And then in the CSS body you call it this way I want gentium one which contains the lowercase, right? And then if I type an uppercase and that uppercase is sort of not available in the gentium one font then change into gentium two. So it's just standard CSS font stack.  We're just splitting one font into different constituent and Here's one result. Here's my result because I because I actually split it into uppercase lowercase punctuation numerals So again, I'm just using the Latin and Latin extended character sets And this is my original size and then I split it this is you know as you can see now the fonts are super light and What's really interesting is that when you split it into many parts the more you split the less efficient it is, right? So suddenly it's a question of like well, how much do you want to split it and benefit from that parallel loading because you know if you Load like you know like ten or five different five kilobyte files. That's probably going to be faster than loading one 100 kilobyte files, right? So can you benefit from parallel loading while still keeping your sizes small and it turns out that the more you split the less efficient it is and I test at the time as well using the web inspector and If I just load one set with everything that's my timing 1.85 seconds And if I have the multiple subset that I load everything, it's actually faster, right? So that's interesting because it's like well, it is actually rendered faster It doesn't get downloaded faster, right? Which is very interesting So the benefit here is not only is it more secure But this time if somebody decides to sort of like grab a font off your site, right? He can grab an uppercase or a lowercase, right? And in order to reconstruct that uppercase and lowercase together and put it into like a usable font He has to download like five or ten different fonts and then open up font forge and then copy and paste the character into a New font file and then save it into new font file, which is not very efficient, right? So as you can imagine this makes it very sort of like it's harder to hack. It's possible, but it's harder so of course the aggregate size of the subset it files are larger and You can benefit from parallel loading, but it kind of still uses more bandwidth It's not a lot of bandwidth, but it's more bandwidth Which if you are operating on a mobile environment like a 2g 3g internet connection is going to be bad And also the additional benefit is there's the flash of Unstile text right which older Firefox versions used to have so if you're targeting older Firefox You're gonna have this problem, but probably not today It's also hard to generate and maintain because imagine for that droid sands, right? I mean I chose to split it into like five or six different parts, right? And what happens is that hey look it's it's really hard to do It takes a lot of time lots of manual work And so really what you want to do is just have enough subset files, right? Most web font services if you are wondering uses just to they just split the font in two and they just you know That way they benefit from parallel loading without making the sizes large. That's upsetting. All right The second one is embedding embedding is pretty simple. I have a font called gentium This is the URL and instead of the URL I Pass it through a base 64 encoder and then I have that right so it's pretty simple You can find base 64 encoder and decoder online It'll convert this for you just you know upload a font file to them and then it'll give you the The data in fact I have one right here That I that I pass by All right, let's see if this works. See so in this case. I just browse for a file All right, so this is the droid sands and it gives me the thing that I just copy and paste into my CSS pretty simple All right, okay, so again. I benchmarked everything so Here's linked. Here's just if I link to a TTF file. This is what it does and if I embed it Dramatically faster, right? So there's several benefits to embedding your font and this is why you should do it it reduces the amount of HTTP page request and It's better for page performance. The CSS can be cashed sometimes font files like load over and over again It's also harder to pirate because you have to decode it, you know Like in you know, you have to decode it back and that's embedding It's really simple a lot of font providers use this and so now let's combine this right sub setting plus embedding So what does that look like? well Here we go. So I'm comparing the performance of just one sub, you know one set versus splitting the font into multiple subset and then I'm also comparing the fact that I'm linking to one as a TTF file and In the other hand have multiple CSS files that are just embedded. So it's really large CSS files, right? So this is what it does. So on the upper bar. I have one set in multiple subsets and in there I've linked and embed it This is how if you embed your own fonts, this is probably what you're going to get This is just droid sense TTF link it in your CSS You're making two requests, right one request for the page the other request for the font That's the size and that's the loading time Multiple subset is what I talked about. It's like method number one, right? It's we're gonna split the font into multiple constituent parts This time we're making one HTML five requests, you know one HTML page request and five font requests, right? It's smaller requests, but it's a bunch of requests. It's a larger file size. That's the number I'm embedding this time, right? So if I embed it in the file, I just chose to embed it in in the HTML file Just to sort of be quick and dirty. I'm just making one request. I'm not calling any CSS. I just embed it there and It's much smaller and it's much faster and This time I choose to embed I choose to like split and then embed it into the, you know Like into my HTML file. This is what I get and this is the rendering Sorry, this is the page loading. So now let's compare it, right? And so what do we learn for this? Well, the more you split and the more you split embed The benefit again like the benefits diminish the more right the more you do it So don't split it into too many parts use to that's sort of my recommendation most services use to three at the maximum use to and Really that's sort of what would we learn, right? It's that number one if you embed a font using like a base 64 thing It's always going to be faster in most cases with modern browsers. It's always going to be faster than linking to the file and Thing number two that we learn is that when you split the files the more you split it the less efficient it is So don't split too much Right, so that's the second method. That's embedding. So method number three also makes sense, right? It's compressing. It's just by using WAF. So What is what is WAF right like people have been talking like oh like how is WAF different from other proprietary format? Well, what is nothing more than an open-type file that you pass through a Compressing algorithm that you add some metadata block So a foundry can add their metadata like their copyright information the font weight their license information They can add that to the WAF file, right and then a wall file is decoded not There's sort of like not service. It's recorded by the user agent Which means it cannot be installed on your desktop, right? You can double click on a wall file It doesn't do anything so it protects like font foundry from piracy a Wall file is kind of it's not impossible But it's kind of impossible to like convert a wall back to a TTF Well, it's possible to convert a TTF to a WAF, right? I mean yeah I mean you can do it sometimes it fails, right? So it's sort of not reliable and therefore it prevents piracy So font foundry is like it for this reason and the history of WAF actually WAF is not very new in sort of early to mid 2009 three guys came up with two sort of solutions to solve the web front problem they call it ZOT and dot web font file format and It turns out that those two formats gets a lot of traction again This is just mid 2009 those things get a lot of traction from a lot of fondries And this is really crucial right because before the WAF format came about all the solution That was talked about in the industry either comes from like a font foundry or like one font foundry And then the other font foundries don't want to implement it or it came from Microsoft And then it has like a licensing issue that like oh nobody wants it, right? So it always comes from that but this time a lot of font foundries does it so suddenly it's gotten sort of a lot of acceptance In mid 2009 it quickly got combined into a new thing called web OTF, right and Web OTF became off pretty simple and Again around mid 2009 Mozilla endorse it and implemented in the browser in Early 2010 it's endorsed from Microsoft and opera and keep in mind This has just been like six months, you know like since six months to a year since the specification first came about and In early 2010 it's it's you know It's submitted to W3C endorsed by Microsoft and opera and then between 2010 and 2011 it's supported in all Major browser IE support sort of came later, but it sort of supported in all major browser It's pretty easy converting a font from TTF to WAF. You can use these online tools font squirrel helps helps a lot I use the command line tool just because I like command line. You don't have to use it and Compressing is pretty easy So I use the tool called TTF to WAF that it just downloaded. I think I just downloaded it via github So let me just quit squarks Quit there you go All right, I Have this All right, sweet. So, you know, so it's just TTF to WAF. I'm just gonna give it a thing to verbose and Here's the font right here. So he's a good old TTF font and Yeah, I'm just going to convert it into WAF. Let's convert it into joint sans Waf There you go. It converts and as you can see the file size just reduces dramatically right from like 108 You know, it's like 108 kilobytes down to like 61. So that's a saving of 56.7 percent, right? I did nothing to the file right and then of course it then generates a wall file Which is right here and as you know a wall file Can open it can install it right because it's to go to it by user agent If I call it in the browser then the browser knows how to encode it. So sorry to decode it but my computer can't do it and that's the Conversion from TTF to WAF again, it's it's pretty simple right can use online tools to do it lots of tools through this So now Let's combine it right what if we combine Subsetting and embedding and and and compressing so we know this already. We did some tests to this and now let's compare TTF and WAF So as you know, this is our TTF data, right and this is the loading time for TTF and Now let's look at WAF right. What's the loading time for WAF? Well, here's the size Loading time is 0.99 seconds less than one seconds Right, so here's the numbers you can look at the presentation later and here it is Right, but let's see the numbers in context and see what we learned from them So the TTF is going to be the upper figure the WAF is going to be the lower figure and here we go That's the size comparison and as you can see WAF save space a lot right in different situations WAF save space a lot compared to TTF and It's also faster right what is also faster. So what do we learn? Well, there's no reason not to use WAF, right? It's pretty simple to do online tools can do it if you use a third party tool they automatically use WAF so why not do it and Here's something interesting if you use WAF It doesn't matter whether you do link to the file or embed to the file because WAF is already compressed, right? So base64 embedding you don't actually have to use that base64 embedding because hey a client computer can install a WAF file anyway So why put it into a another? What is it? Decoding or encoding and decoding method right base64. So it's already compressed So you don't need to do base64 if you use WAF interesting and Again when you embed right so again like rightly the the vertical one We're first like linked and embedded right so So embedding will generally be faster again this proofs and embedding is always faster than linking even though at this point the time and size difference is kind of it's kind of a little and Again when we look at WAF files that I split into multiple subsets The more subsets I do the worst performance it is All right, so that's WAF or at least that's waft 1 1.0 So later we're going to talk about waft 2.0 if we have some time No promises there. So that's the three methods that we talked about it's upsetting splitting one font file into multiple parts Just using the language or the characters that you need discarding the rest We have embedding which is sort of embedding a font file in base64 file format and coding it letting the user agent to code it Versus linking to the naked font file and lastly we have compressing by using WAF So that's sort of the method. Alright, so now we're going to talk about some problems Which I think any of us knows it's a flash of unstyled text, right? So what Firefox used to do really is that when it finishes loading the page It'll just load the page and like your default serif font or sans serif font So it'll just load the page in aerial Helvetica times New Roman Georgia, etc, etc and after the font is loaded Then it'll flash and it'll change the font the text will reflow and it creates a really sort of you know, really bad user experience So Mozilla fixed it in 2011 and now the behavior is the same across all modern browser It's the same with opera's now that opera uses blink. It's the same with with chrome as well, right? It's the same with IE. So now this is no longer a problem However, right now that you you don't have to flash of unstyled text This means that you don't see text until the font is fully loaded, right? So what happens is that until the font is fully loaded It's just going to be a blank page and you won't see anything until you know, you load that like 100 kilobytes worth of file So you don't see any text and therefore if you're in a mobile device You're just going to see like some image and like a blank page and you don't know You expect the site to be broken. You quit it. You don't use the site anymore Right. So how do you make loading time as fast as possible? Well, first of all, you separate the font css, right? So rather than have one css file that contains all the Embedded basic st4 format you separate it. You just separate, you know, you have like a separate css font file for Uh, the basic latin separate css font file for serific separate ones for greek, right? Whatever you use whatever substance you separate it into files so they can load parallely, right? So that makes sense Maximize expired headers if you have control over the cache obviously because css can be cash, right? So it makes sense to not download it over and over again Uh, this is an interesting idea is, uh, why don't we do, you know, deploy a java script that can load the page without the font, right? Because then it's faster, right?  So this is an interesting solution I'm not sure. I think it's worth trying. I haven't tried it, but that's an interesting solution And this thing is actually also interesting, right is just make it responsive if you do android Then don't you you know, like if you know that you're targeting a slow android device on a 2g connectivity Hey, don't use like your own web fonts just in your in your css file just specify Hey, I just want to use droid sans or open sans or whatever font file comes with android, right? So make the font responsive as well. There's no reason why A font can't be responsive, right? If the size is small again, like maybe if the size is small Maybe I won't load any fonts if the size gets bigger Maybe I'll just load one font if it's on the desktop then maybe I'll load all the fonts ever, right? So again, it's just responsive design with fonts And that's how you solve the problem of of that's this like flash of unstop text, right? It's been resolved and that's how you resolve that problem of not seeing content before the fonts load it The next one that we're going to talk about is the future It's going to be a really short section. I'm going to talk about two things I'm going to first the one of them we're going to talk is the network information api. This is a relatively new Proposal at the w3c you can see the you can see the proposals online And really it just allows you to target Different bandwidths and now I can say hey look if the connection bandwidth is more than two megabytes Then show the hd image if it's less show the you know show the lower quality image It's the same as uh, I suppose it's the same as like a retina sort of targeting thing, right? It's like oh if the display density is two Then show an at 2x otherwise you show a regular image So network information apis really helpful. I think it's going to be implemented in browsers I might be implemented in chrome canary. I'm not sure but it's something to try which is really interesting So it allows you to target just different bandwidths different connectivity The second one is waf 2.0, which is really interesting Because it saves space from waf 1.0 by about like 20 to 30 percent. So We sort of like don't care about this But if you care about the technicality you can ask them later But basically this means that the way that fonts are encoded in waf 1 you know 1.0 right now It contains a lot of redundant or duplicate information And what waf 2.0 does is it sort of sort of eliminates that redundancy eliminates that those empty blocks those empty unicode blocks It eliminates repeating information and just condense it even more Right it uses a new um Several different compression engines were tested This is the first if you remember microtap express from like page 9 or 10 that was back in like 1992 or whatever That got used again and that got tested, but apparently it's not royalty free The perform even though the compression is pretty good, right? It's like 24.96 percent the performance It only performs at one sixth the uh the performance right So if you're a type foundry and you want to implement this it's gonna take you're gonna have a bad time It's gonna take a long time to convert your whole library into waf 2.0 the second one that I think they're going to um implement is microtap express again, it's like the same thing But it's a new compression algorithm called broadly. I wouldn't go into detail But it's open source it's fairly well documented because it's actually based of A a compression algorithm that is also like back in the 90s called flay, but You can actually deploy it yourself if you want check it out. It's font dash compression dash reference You can actually test it by enabling these flags in chrome and just loading google fonts, right? And that's it for me and we talked about four things today, uh, which is the history We talked about methods, right? We talked about like subsetting embedding and and um Compressing we talked about some problems to alleviate That flash of unstyled text and not seeing content before and we talked about the waf 2.0 and the network information api that can like speed up loading fonts even more and That is how you make your web fonts faster and also more secure There's the back channel if we don't have time for questions. Otherwise, uh, there's my email and it's really dark But it's bram at mozilla. Send me questions Bram, thanks. That that was very comprehensive and uh, I have a lot of questions I even forgotten some of the questions by the time you finish. Um, the one thing I wanted to ask you quickly is You mentioned the bandwidth api that's in browsers Can't that be put into css? Sorry, uh, the bandwidth api that lets you ask browser what bandwidth it has Yeah, that would have been really nice if that was in css because then it becomes part of your responsive style sheets I know right. I know. Yeah, it should it should be now I mean, I mean I looked at the uh, I look at the I look at the spec sheet and it's It's like js. I'm like, I don't I don't understand either. I don't understand why I I hope though I hope they brought it into css because that will be nice because one of the One of the other feature that it can detect is can is it can also detect whether a connection is offline or not And that's really nice. So if we detect that in the css, you can say, oh, if it's offline then make it this way Yeah, the other thing is, um, you know chrome's been broken for a while You're not from chrome. You're not responsible for it, but Uh, essentially embedded fonts don't work in chrome as of today You know, they never worked in windows, but chrome for the last couple of months has been broken The fix is due in the first week of march Uh, but it's been broken for a while and essentially it's an idle time out. You know the chrome doesn't cash The current version of chrome does not cash web fonts So it it flushes them from the cash after they've been there for a few minutes And essentially any idle type loses its fonts. Um, how many of you guys have experienced this? That's it. You guys haven't noticed that chrome can't render fonts anymore So the other thing is that's curious is, you know, chrome can't render fonts on windows. Anyway, um, if you use windows And use embedded fonts, it looks really shitty with chrome. It looks great in internet explorer great in firefox, but bad in chrome. Um, and This is kind of side for the fonts industry I mean the leading browser chrome has more than 50% of the market share now and they just can't render fonts Yeah, and and unfortunately embedded has become Sort of the preferred way. I mean, that's the way that you make it secure, right? Because then you have to decode it as well. So I get it's like it's not going to change It's always going to be embedded and split. So it's going to be off. It's going to be embedded in base 64 It's going to be split into multiple parts. So I guess you can follow bug follow bug. I don't know The bug is well known. It's uh, it just believes I missed a couple of release cycles. So it's Due for much the bug is actually fixed in canary. It's just not in stable. Okay Maybe it's the switch from from blink, you know switch from what gets a blink maybe Well instantly now the other thing I mentioned I want to ask you about is that you said waf is secure because there's no app That can open it But the code to deal with the waf file is already in a browser It's not going to be that hard for someone to take it out and make it stand alone Oh, absolutely. Absolutely. And I think like all three compression methods works best when you um When you deploy them, you know, when you deploy when you deploy all three of them, right? Because if you just have waf then again, it's just really easy to decode just just use that command line tool and replace that DTF with waf right like it's done Sometimes it doesn't work, uh But I think it works if you first split it right and then you convert it to waf and then you Uh, what is it and then you like encode it into base 64 because then if I want to seal the fonts What I have to do is like first I have to decode it into You know to base 64 to a waf file I have to figure out a way to convert that waf file into ttf And then after that I have to open like a font program Because I only get the lower case or the upper case. So it's kind of like, oh, it's too much hassle But really like there's nothing spot. There's nothing stopping you. You can like you can actually do that. Um, yeah Ram Hi One question here instead of uh, serving our own fonts How does one take a decision on using something like typekit and google fonts because there is a good chance that other users Or other websites are also calling fonts from the same service and hence the browsers might have it cached So it's the cdn argument, right? Uh Yeah, yeah, absolutely. Absolutely. I think uh, yeah google fonts is sort of like, uh, google fonts is a fine alternative A lot of people use it and again, right as you said If somebody has the font and then somebody uses google font Um, it's all also going to be going to be cash So what's stopping you from using it? Well as it turns out at mozilla We couldn't use for example like mozilla we use sort of our own cdn Or you don't use google fonts even though we use open sense for instance, right and all our website So why can't we do that? Well because google's data policy I mean like google might might do something with the cash, right? Because it knows like which computer or like which types of browser opens and loads their web fonts And I don't know what google is going to do with that data, right? So that's why we deploy our own right? So that's sort of a concern sort of using google web fonts even though it is faster It is good. They're doing all this stuff to make it more performance So if privacy is and and privacy and data handling is your concern Then maybe using google web fonts sort of like not sort of like not such a good idea I think one like security Sort of center company or a security center website worried about this like oh we use google web fonts Like can we do this because it sends data to google are we okay with this? So that's one concern The second concern is that sometimes the font quality, you know other than the fonts that google has commissioned like open sense You know it's really good droid sense, right? It's good aside from those exceptions, right? You kind of get what you paid for which means that if you actually buy fonts And then you deploy the fonts that you buy using whatever a third party service or deploy it yourself It's probably going to be better because I mean somebody paid a lot of money To to do it and you actually licensed that font versus using a font that google Has which is free and not that open source is bad. It's actually very good But a lot of the stuff is just not sort of high quality in small sizes They don't render as well You open it in like a windows machine and it looks like anemic like it's about to fall apart and and stuff like that So so you get those issues with with google fonts and and stuff like that So that's sort of the argument against it. But hey, if you use open sense then use google fonts, right? It makes sense Thanks Hi, um, have you had experience subsetting um fonts with open type features? I'm using fonts.com as my fonts supplier I do get tons. I mean huge sizes of wharf and all those files I I use some of them especially for their open type features But of course they run into huge sizes. I mean run into maybe a megabytes When I consider all the italics and all the variants of the font So would I be would you know if I am in the clear if I subset those fonts that I get from fonts.com? And have you had any experience doing subsetting for open type features at all? Lastly, uh, what one are you using for your slides? Let's want to know curious. Okay, uh, yeah, so, um, Well, it's possible because in css again, not all Uh, modern browser not all modern browser supports this in different ways But in css as you know, you can you can specify whether you know, what which kind of ligatures you want to use which kind of Number case you want to use so no matter how you split it you can split it into 10 parts or 100 parts or two parts As long as you call it in the css. It's fine because it's based in in, you know It's doing character substitution via by a unicode. I'm guessing so As long as the unicode Unicode unicode sort of code is not being messed on during the splitting and conversion process then you're in the clear Um, so that's the simple question like you still have to deal with the size, right? But that's your problem, right because it's like, well, it's large. So, um, this font is uh, it's called dolly And it is from uh underwear W a r e Dot n l so good good fondry. So good guys. Thanks It's it does a subsetting change the license if I buy the font and then I subset it and Spute it myself. Is that allowed under the license that I normally buy it? Uh, well, that's an interesting question. I'm not an expert in in in font licensing, but I can tell you that Different fondries might have different Uh policies about this right like some fondries might allow their fonts to be downloaded And you know into your machine and then sort of float it up from your machine Other fondries actually don't give their fonts away At all as a downloadable wet fonts, right? Uh, so for example, I think like You know typography dot com like hopefully h and f j don't allow this We're like, oh, you either use our cloud service, but you can't use the wet fonts, right? So different fondries have different policies about this, but I don't I don't know enough But my guess is that you just check with the uh, uh, with the different fondries I'm on question. So Is there any command line to like font forge? So Like if I want to go through my database and find out what characters I'm using and then just upset that Is there a way to automate that and uh We'll run it as part of my build script Yes, absolutely there is That's the that's sort of the sure the short answer is that there is um And google has some some some tools in their uh in their google code side because when they built the google wet fonts, they're also building that um Subsetting tool right checkbox. They actually use I I think they use like a command line tool that you can download from google code Uh, I haven't done it I haven't done it the command line way because I sort of just needed to give demo right so it needs to be visual Absolutely, you can do it