Introducing Typekit
blog.typekit.com
blog.typekit.com
The question is what will make these foundries jump onboard if Typekit isn't introducing a new DRM or other protections? I think this is how it might work:
1.) Check the site referrer to ensure that fonts from Typekit are only delivered to websites that have purchased the font (or are signed up for the free fonts).
Of course since there aren't any drm protections, you can simply take the font file and put it on your own site, which leads to....
2.) They might have custom Typekit versions of well-known fonts, so that if any website is self-hosting a font file that is from Typekit, it's plainly obvious they're doing it illegally. Also, if a type foundry only licensed their font to Typekit for web embedding, then any hosting of their font on a site other than Typekit is forbidden.
This is different than how it would work now, because let's assume that a type foundry licensed fonts for embedding on websites. It becomes very hard for them to search the web finding their embedded fonts and then checking their records to make sure the person who created the site actually purchased a license. This would take a lot of time and effort that these type foundries don't have. However, if the font is only licensed to be hosted by Typekit, then Typekit can do the checking and accept reports of other sites infringing, etc. It just makes the whole effort easier because only one website will have the license to self-host that font.
So to me, the biggest downside is that you have to have your font files hosted on a 3rd party service. Also, they claim you'll embed the fonts via javascript, whereas if you were self-hosting your own fonts there's no need for javascript at all.
I wish the type foundries would just get over the fact that some people may commit copyright infringement on their fonts. Instead they should just provide all of us honest people the ability to purchase a license to embed fonts on our websites instead of constantly trying to find drm'ish ways of fighting it.
I can't imagine allowing custom fonts making this situation any better. I don't want the web to be pixel perfect, I want the end-user to have control over what they see, without sites breaking.
How, exactly, does this prevent that?
What current user mechanism for control over the web pages will this preempt?
What is the difference between saying "I don't want this page to be in Arial, I want it to be in Tahoma" and "I don't want this page to be ExoticTypeKitFont, I want it to be in Tahoma"?
More generally, the mentality expressed in the original post (that authors need more control over what the end-user will see) has been bad for end users who want control over what they see without delving into extremely complex details, e.g., the profusion of complexity that is Firefox's about:config.
I'm happy and scared at the same time.
At the end of the day, the web really is mostly type.
Also, someone has mentioned that this is really pandering to the type foundries who aren't willing to modify their business models and their licensing to accommodate web usage. Maybe this is a good first step or maybe it's a RIAA thing for the fonts.
I thought it was interesting, though.
Since they are using CSS font mechanisms (I think), it will depend on what the CSS engine does. If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there. The interesting question is what exactly the browsers do for such fonts, but my guess is that they would be treated exactly like a script tag in the header, adding something that would have to be downloaded before the page will even begin to render. But, further presumably, the JS they provide and the fonts will be properly labeled with cache control headers so they don't hit the host server on every page load.
See how Yahoo serves their YUI stuff: http://developer.yahoo.com/yui/articles/hosting/
The question is what defines "can't get a font completely". Is it a timeout? How long is this timeout? If I spend time and resources to optimize the loading time of my site and the JS script times out getting a font, isn't that lost time for me?
This all feels like a workaround for license issues as opposed to a true solution. Type foundries should let web developers purchase fonts that can be published on the web.
2. Render.
3. Is font available? If yes render, if not, use next font.
If that download is taking forever, I'd imagine the page would render in the secondary font until the Load font command is eventually successful.
I suppose it will really come down to pricing, but they're going to really need to cut into those expected royalties if this is going to fly. It'll be interesting to see if font designers are as pig headed as music labels, or if they can understand that a lessor percentage of a larger total is the better deal.
Using the standard @font-face css technique instead of a text replacement hack allows your custom fonts to have all the same benefits of standard browser text.
Unsurprisingly they don't go into details about how this all works, but if it can deliver standard font files to browsers that support @font-face then the font can be downloaded and used. It's on a par with javascript hacks to prevent right clicking on images.