N
NewsBot
Hi! It’s Bill Hill here again, still fighting the good fight to make typography on the Web as good as we’re used to seeing in print. We made significant progress this week, when one of the USA’s most prestigious font companies announced its support for the Embedded OpenType format for font embedding on the Web, and launched a new website to promote other browsers to support it in addition to Internet Explorer (which has had EOT support built-in since 1996).
At the same time, Ascender Corporation and its collaborators in the typographic community also warned of the legal dangers of using the Font Linking mechanism currently supported by other browsers.
Read the announcement in full or visit the new Ascender site for further details.
Font Embedding with EOT
Embedded OpenType (EOT) is currently before the W3C in a submission to make it an open Web Standard. The format was previously proprietary to Microsoft. We created it to enable font embedding within Microsoft Word documents in the early 1990s, and it was later extended for use on the Web by Internet Explorer.
In its introduction to the technologies of font embedding on the Web, Ascender says, â€Fonts play a critical role in the display, printing and manipulation of text-based information and content. Font embedding is a broad and complex topic, and we hope this website becomes a valuable resource for everyone who creates or uses fonts to learn more about proper font usage and licensing.â€
The website has sections covering issues such as:
[*]Fonts and the Law[*]Document Font Embedding[*]Fonts and the Web (a comparison of the various embedding technologies)[*]Shipping Fonts with Applications, Digital Content, and Devices[/list]In the section on Fonts and the Web, Ascender compares EOT, sIFR and Font Linking, and welcomes the move by Microsoft and Monotype Imaging to propose EOT as a W3C standard (Monotype Imaging, another prestige font company, developed MicroType® Express compression to reduce the size of EOT files). The proposal has been with W3C for several months.
“EOT offers several advantages for type designers, and web designers. For type designers EOT creation tools must respect the embedding permissions built-into their fonts and EOTs are bound to a specific web page or site. For web designers an EOT can contain a subset of the glyphs, and it can be compressed – both of these features can shrink EOT file sizes to reduce download times and improve performance,†says Ascender.
Font Linking, in which raw font files are stored on a server and downloaded using the @font-face mechanism, falls outside the realm of fonts embedded in documents, Ascender warns. â€Web page designers should be very careful to avoid violating commercial font EULAs (end-user licensing agreements) by placing fonts on Web serversâ€. Ascender’s own EULA, for instance, prohibits installing fonts on servers without purchasing an extended license.
In concluding its comparison, the website continues, “Ascender believes that although not perfect, EOT represents the best current solution for type designers and font foundries to protect their Intellectual Property. It is the only web font embedding solution that respects font embedding permissions, uses an industry-proven subsetting and compression mechanism, and ties embedded fonts to specific web sites. Ascender hopes that other web browsers will make it a priority to support EOT once it becomes a W3C standard.â€
The site also has some free fonts to promote the technology, and the first Web-based EOT creation tool.
This endorsement prompted me to go back and start playing around with font embedding, since I hadn’t looked at it in some time. I started by downloading WEFT, the Windows Embedding Font Tool, from the Microsoft website.
Before you try to use the tool in earnest, it’s really worthwhile going through the tutorial on the same page, which has some code samples. There’s also more good information in the “Troubleshooting and Testing†section on the WEFT page.
Don’t expect the tool to do all the work, though. It’s great at creating EOT files and the CSS Font Declarations used to link your pages to them. But - depending on the complexity of the source files for your pages - you may have to do some manual coding to get them to work properly.
Give it a Try, with a Caveat
Here, I have to do a huge mea culpa.
Creating a set of pages using EOT allowed me to experiment with what a blog, for instance, might look like if it was designed for readability. But I’m a type and font guy – not a Web code jockey. I just wanted to see, quickly, what readable pages might look like. This was an experiment. I didn’t want to start hand-crafting pages. So I took the easy route, and used a publishing application with which I’m very familiar to generate the multicolumn pages.
This is “throwaway codeâ€. It’s verbose, arcane and in lots of places it’s proprietary. A real Web guru like Chris Wilson takes one look, and you just know he’s controlling the urge to scream. The W3C HTML Validator, though, doesn’t manage to control the urge to scream: “85 coding errors, you moron! Starting with no !â€
My pages offended Chris so much, he immediately made a start at re-coding them so they’ll validate and meet Web standards. If I was a sensitive soul I’d be offended, but like I said, I’m no coder. And what a great way to recruit a very busy guy to do some coding for you. My pages are like a crooked picture on a wall which Chris passes every day – if he doesn’t straighten it, it’ll drive him mad…
Just his first pass at making a “legitimate†version of the first page took its size down to only 25% of the original. And even I can tell the code’s a lot better. We’ll work to get “legitimate versions†of the pages posted. We’d have preferred to do this before this blog post, but Chris said something about wanting to spend the weekend with his family or something
, and I wanted to highlight the Ascender announcement while it was timely."
Anyway, if you’re going to blame anyone for the code, blame me.
With that huge caveat, you’ll find my pages at:
http://billhillsite.com
They’re definitely a work in progress, so expect the odd glitch. For example, one or two people have reported mild clipping issues on some displays. I’ll need to investigate.
They were designed to be viewed on a 1400 x 900 display, and should be viewed using the F11 key to make Internet Explorer go FullScreen, to get rid of menus, address bars and anything else that distracts from reading. I’ve got into the habit of toggling F11 to go from my personal “reading†mode to “browsing†mode – where I want all those menus and toolbars…
I had to manually tidy up and paste the @font-family declarations, which look like this:
@font-face {
font-family: Cambria
font-style: normal
font-weight: normal
src: url(CAMBRIA2.eot)
}
I’ve given feedback on these issues to the team, and we’re working out what can be done to reduce the need for manual tweaking.
Of course, since we’ve opened up the EOT format, we hope other tools will soon be generating EOTs as well, such as the Ascender site. Since the W3C submission includes sample code, it would be great if the tools you use to author pages would integrate EOT generation into the process. Then the code would be more tightly integrated as well.
The good news is that if you have to do some manual tweaking, once you’ve got it right for one page, the code can be easily copied and pasted into your other pages. Even better, you can put it in a Style Sheet, and have all the pages reference it.
Working with WEFT and EOT
One performance tip for embedding fonts in your pages is to use the subsetting capability available in the WEFT tool to generate the font objects with only the characters you need. They’ll be smaller, and faster to download.
For instance, if you write in English, then you’re unlikely to use the Cyrillic or Greek characters, and you could use “language-based†subsetting. There are seven subsetting options in the tool, including “per page†and “per siteâ€. Since my test site’s a blog which should be frequently updated, I opted at first for “no subsettingâ€, which creates the largest font objects - but means I’ll never need to update them whatever new content I create in future.
However, on reflection, I thought this might be overkill, and tried language-based subsetting, and got a huge performance improvement!
Calibri and Cambria, for instance, are big fonts with four true weights each, all of them painstakingly hinted for maximum readability at small sizes. The four weights ended up as font objects of ~175K each without subsetting. With language-based subsetting, they were only one-third the size of the original EOTs and the page rendered just the same – only a lot faster.
Nice thing is, as long as I made sure the names of the objects for each font and style remained the same, I was able to just swap out the objects in the root directory of my site, without having to change the code in any of my pages.
Another production tip from my experience which can save you a lot of time: WEFT will let you analyze pages on your Web server – but you can tell it to create the font objects on your local hard drive. Generating the objects on the Web can take a loooong time. Using your local machine it’s very quick, and you can then FTP them to your site.
Font embedding is critical not just to allow designers to make distinctive pages, but for readability. Building fonts that work for text at normal reading sizes of 11 and 12 points requires a lot of work. It could take a designer anywhere from a year to three or more years to develop a full character set, hint it properly to work at screen resolution, and so on.
However, anyone who has a copy of Windows Vista, Office 2007 or Mac Office 2008 already has a great set of fonts they can embed in Web pages. They’re called the C* fonts (because they were optimized for ClearType, and thus all given names which began with “C†J): Calibri, Candara, Consolas (a monospaced font for coding), Cambria (which also contains a set of 4000 Math characters), Constantia and Corbel.
I know personally how much effort went into creating them, because at the time I was managing the group which ran the project. Outside designers created the outlines from their winning entries for a competition we ran, and then the fonts were hinted by the best in the business.
The project took a long time and cost a lot of money – which is why we don’t just give these fonts away. They add a lot of value to the applications (and operating systems) which ship them. But they all have Embedding permissions set to “Editableâ€, which means you can freely embed them using EOT, as long as you bought one of the products in which they shipped – although you are not allowed to just copy the .TTF font files to a server.
My absolute favorites for reading on screen are Cambria and Calibri. I use them for body text at 12point because I sit a little farther away from the screen than I would read from paper (where the optimum size is 11point). The faces also all have true italics, bold, and bold italics – none of your ugly, synthetic, machine-generated rubbish! A true italic face has unique characters, which are not just a skewed regular or Roman…
The Future of EOT
Remember, these pages will work only in Internet Explorer right now, because it’s the only browser which supports EOT font embedding. EOT was a great idea for Word back in the 1990s, and it was a great idea for the Web in 1995. But because Netscape at that time adopted another standard, and we kept EOT proprietary, no-one used either.
That’s why, last year, I gathered a group of folks together and began a campaign to make EOT an open standard and put a full proposal in front of the W3C.
I really hope it will become a standard, and other browsers will also implement it, because it’s a much-needed solution to the problem of using fonts on the Web that meets the needs not only of end-users and Web designers (who get to use the commercial fonts they already know), but also commercial font creators, more of whom will start enabling embedding as a result.
We have to solve the issue of fonts on the Web in a way that’s fair to everyone in the ecosystem.
Try experimenting with EOT embedding. I’d love to see some samples from people who actually know what they’re doing…
Bill Hill
Program Manager
edit: added two additional headers for readibility
More...
At the same time, Ascender Corporation and its collaborators in the typographic community also warned of the legal dangers of using the Font Linking mechanism currently supported by other browsers.
Read the announcement in full or visit the new Ascender site for further details.
Font Embedding with EOT
Embedded OpenType (EOT) is currently before the W3C in a submission to make it an open Web Standard. The format was previously proprietary to Microsoft. We created it to enable font embedding within Microsoft Word documents in the early 1990s, and it was later extended for use on the Web by Internet Explorer.
In its introduction to the technologies of font embedding on the Web, Ascender says, â€Fonts play a critical role in the display, printing and manipulation of text-based information and content. Font embedding is a broad and complex topic, and we hope this website becomes a valuable resource for everyone who creates or uses fonts to learn more about proper font usage and licensing.â€
The website has sections covering issues such as:
[*]Fonts and the Law[*]Document Font Embedding[*]Fonts and the Web (a comparison of the various embedding technologies)[*]Shipping Fonts with Applications, Digital Content, and Devices[/list]In the section on Fonts and the Web, Ascender compares EOT, sIFR and Font Linking, and welcomes the move by Microsoft and Monotype Imaging to propose EOT as a W3C standard (Monotype Imaging, another prestige font company, developed MicroType® Express compression to reduce the size of EOT files). The proposal has been with W3C for several months.
“EOT offers several advantages for type designers, and web designers. For type designers EOT creation tools must respect the embedding permissions built-into their fonts and EOTs are bound to a specific web page or site. For web designers an EOT can contain a subset of the glyphs, and it can be compressed – both of these features can shrink EOT file sizes to reduce download times and improve performance,†says Ascender.
Font Linking, in which raw font files are stored on a server and downloaded using the @font-face mechanism, falls outside the realm of fonts embedded in documents, Ascender warns. â€Web page designers should be very careful to avoid violating commercial font EULAs (end-user licensing agreements) by placing fonts on Web serversâ€. Ascender’s own EULA, for instance, prohibits installing fonts on servers without purchasing an extended license.
In concluding its comparison, the website continues, “Ascender believes that although not perfect, EOT represents the best current solution for type designers and font foundries to protect their Intellectual Property. It is the only web font embedding solution that respects font embedding permissions, uses an industry-proven subsetting and compression mechanism, and ties embedded fonts to specific web sites. Ascender hopes that other web browsers will make it a priority to support EOT once it becomes a W3C standard.â€
The site also has some free fonts to promote the technology, and the first Web-based EOT creation tool.
This endorsement prompted me to go back and start playing around with font embedding, since I hadn’t looked at it in some time. I started by downloading WEFT, the Windows Embedding Font Tool, from the Microsoft website.
Before you try to use the tool in earnest, it’s really worthwhile going through the tutorial on the same page, which has some code samples. There’s also more good information in the “Troubleshooting and Testing†section on the WEFT page.
Don’t expect the tool to do all the work, though. It’s great at creating EOT files and the CSS Font Declarations used to link your pages to them. But - depending on the complexity of the source files for your pages - you may have to do some manual coding to get them to work properly.
Give it a Try, with a Caveat
Here, I have to do a huge mea culpa.
Creating a set of pages using EOT allowed me to experiment with what a blog, for instance, might look like if it was designed for readability. But I’m a type and font guy – not a Web code jockey. I just wanted to see, quickly, what readable pages might look like. This was an experiment. I didn’t want to start hand-crafting pages. So I took the easy route, and used a publishing application with which I’m very familiar to generate the multicolumn pages.
This is “throwaway codeâ€. It’s verbose, arcane and in lots of places it’s proprietary. A real Web guru like Chris Wilson takes one look, and you just know he’s controlling the urge to scream. The W3C HTML Validator, though, doesn’t manage to control the urge to scream: “85 coding errors, you moron! Starting with no !â€
My pages offended Chris so much, he immediately made a start at re-coding them so they’ll validate and meet Web standards. If I was a sensitive soul I’d be offended, but like I said, I’m no coder. And what a great way to recruit a very busy guy to do some coding for you. My pages are like a crooked picture on a wall which Chris passes every day – if he doesn’t straighten it, it’ll drive him mad…
Just his first pass at making a “legitimate†version of the first page took its size down to only 25% of the original. And even I can tell the code’s a lot better. We’ll work to get “legitimate versions†of the pages posted. We’d have preferred to do this before this blog post, but Chris said something about wanting to spend the weekend with his family or something
Anyway, if you’re going to blame anyone for the code, blame me.
With that huge caveat, you’ll find my pages at:
http://billhillsite.com
They’re definitely a work in progress, so expect the odd glitch. For example, one or two people have reported mild clipping issues on some displays. I’ll need to investigate.
They were designed to be viewed on a 1400 x 900 display, and should be viewed using the F11 key to make Internet Explorer go FullScreen, to get rid of menus, address bars and anything else that distracts from reading. I’ve got into the habit of toggling F11 to go from my personal “reading†mode to “browsing†mode – where I want all those menus and toolbars…
I had to manually tidy up and paste the @font-family declarations, which look like this:
@font-face {
font-family: Cambria
font-style: normal
font-weight: normal
src: url(CAMBRIA2.eot)
}
I’ve given feedback on these issues to the team, and we’re working out what can be done to reduce the need for manual tweaking.
Of course, since we’ve opened up the EOT format, we hope other tools will soon be generating EOTs as well, such as the Ascender site. Since the W3C submission includes sample code, it would be great if the tools you use to author pages would integrate EOT generation into the process. Then the code would be more tightly integrated as well.
The good news is that if you have to do some manual tweaking, once you’ve got it right for one page, the code can be easily copied and pasted into your other pages. Even better, you can put it in a Style Sheet, and have all the pages reference it.
Working with WEFT and EOT
One performance tip for embedding fonts in your pages is to use the subsetting capability available in the WEFT tool to generate the font objects with only the characters you need. They’ll be smaller, and faster to download.
For instance, if you write in English, then you’re unlikely to use the Cyrillic or Greek characters, and you could use “language-based†subsetting. There are seven subsetting options in the tool, including “per page†and “per siteâ€. Since my test site’s a blog which should be frequently updated, I opted at first for “no subsettingâ€, which creates the largest font objects - but means I’ll never need to update them whatever new content I create in future.
However, on reflection, I thought this might be overkill, and tried language-based subsetting, and got a huge performance improvement!
Calibri and Cambria, for instance, are big fonts with four true weights each, all of them painstakingly hinted for maximum readability at small sizes. The four weights ended up as font objects of ~175K each without subsetting. With language-based subsetting, they were only one-third the size of the original EOTs and the page rendered just the same – only a lot faster.
Nice thing is, as long as I made sure the names of the objects for each font and style remained the same, I was able to just swap out the objects in the root directory of my site, without having to change the code in any of my pages.
Another production tip from my experience which can save you a lot of time: WEFT will let you analyze pages on your Web server – but you can tell it to create the font objects on your local hard drive. Generating the objects on the Web can take a loooong time. Using your local machine it’s very quick, and you can then FTP them to your site.
Font embedding is critical not just to allow designers to make distinctive pages, but for readability. Building fonts that work for text at normal reading sizes of 11 and 12 points requires a lot of work. It could take a designer anywhere from a year to three or more years to develop a full character set, hint it properly to work at screen resolution, and so on.
However, anyone who has a copy of Windows Vista, Office 2007 or Mac Office 2008 already has a great set of fonts they can embed in Web pages. They’re called the C* fonts (because they were optimized for ClearType, and thus all given names which began with “C†J): Calibri, Candara, Consolas (a monospaced font for coding), Cambria (which also contains a set of 4000 Math characters), Constantia and Corbel.
I know personally how much effort went into creating them, because at the time I was managing the group which ran the project. Outside designers created the outlines from their winning entries for a competition we ran, and then the fonts were hinted by the best in the business.
The project took a long time and cost a lot of money – which is why we don’t just give these fonts away. They add a lot of value to the applications (and operating systems) which ship them. But they all have Embedding permissions set to “Editableâ€, which means you can freely embed them using EOT, as long as you bought one of the products in which they shipped – although you are not allowed to just copy the .TTF font files to a server.
My absolute favorites for reading on screen are Cambria and Calibri. I use them for body text at 12point because I sit a little farther away from the screen than I would read from paper (where the optimum size is 11point). The faces also all have true italics, bold, and bold italics – none of your ugly, synthetic, machine-generated rubbish! A true italic face has unique characters, which are not just a skewed regular or Roman…
The Future of EOT
Remember, these pages will work only in Internet Explorer right now, because it’s the only browser which supports EOT font embedding. EOT was a great idea for Word back in the 1990s, and it was a great idea for the Web in 1995. But because Netscape at that time adopted another standard, and we kept EOT proprietary, no-one used either.
That’s why, last year, I gathered a group of folks together and began a campaign to make EOT an open standard and put a full proposal in front of the W3C.
I really hope it will become a standard, and other browsers will also implement it, because it’s a much-needed solution to the problem of using fonts on the Web that meets the needs not only of end-users and Web designers (who get to use the commercial fonts they already know), but also commercial font creators, more of whom will start enabling embedding as a result.
We have to solve the issue of fonts on the Web in a way that’s fair to everyone in the ecosystem.
Try experimenting with EOT embedding. I’d love to see some samples from people who actually know what they’re doing…
Bill Hill
Program Manager
edit: added two additional headers for readibility
More...