Introducing Typekit

http://blog.typekit.com/2009/05/27/introducing-typekit/

by batasrki • 17 years ago

38 18 17 years ago

blog.typekit.com

This will be great for talented web designers who want to use non-standard fonts, but I know that it'll result in us seeing websites covered in 'grunge' fonts and other illegible crap just because the 'designer' thought it looked cool.

I'm happy and scared at the same time.

lallysingh• 17 years ago

We might see a little font-equivalent of the animated GIF, but for the most part, I think we'll see much better looking webpages.

At the end of the day, the web really is mostly type.

batasrki2• 17 years ago

Even though I posted this link, I don't fully agree with the premise. Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me.

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.

jerf3• 17 years ago

"Not only will there be an explosion of "This looks cool" font usage, I'm worried what happens when their servers or their network fails. What about when it slows down due to unforeseen spike in traffic? They haven't talked about the backup options, which scares me."

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/

run4yourlives3• 17 years ago

CSS would pick that up and just use the next specified font, presumably. The same way that if I specifed: font-family: {fancy font, Arial} your browser would automatically render Arial.

ori_b2• 17 years ago

Thanks, but no thanks. Web pages already assume too much about the way that they'll be rendered -- I have pages looking funny when I force a minimum font size so I can actually read them. I know, it's a crazy idea wanting to read web pages. What can I say? I'm weird that way.

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.

jerf3• 17 years ago

"I want the end-user to have control over what they see."

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"?

ori_b2• 17 years ago

Read the first paragraph again -- The problem is that pages start breaking when designers make the assumption that things will be pixel perfect. Allowing them to perfectly specify a font, complete with external references, further supports this [incorrect] assumption.

hollerith• 17 years ago

A user who would prefer to see the page's text as quickly as possible rather than to see the text in the font the page author prefers might have trouble expressing that preference with pages that use Typekit's solution. In other words, if the user would prefer to see the text rendered with a font available on the local machine rather than wait for a font to download for Typekit's servers, . . .

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.

wysiwtf2• 17 years ago

You can already embed fonts easily without using a service such as this site will provide. The problem is of course the license to do so. There are a lot of fonts out there that are free and allow website embedding, but the majority of fonts from major type foundries are not included. So assuming Typekit gets more of the type foundries onboard that would be useful.

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.

run4yourlives3• 17 years ago

This is interesting, but I'm not sure how well it will work when there is already a method (SFIR http://www.mikeindustries.com/blog/sifr/) that works around this licensing issue completely.

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.

wysiwtf2• 17 years ago

Those text replacement techniques (sIFR/cufon) have downsides though. You can't manipulate the replaced text as you would normally, you lose some functionality because you've replaced text with flash/canvas/image etc., and you won't see anyone replace entire body text using those techniques.

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.

halo• 17 years ago

Sorry, but a "solution" that involves embedded JavaScript from a 3rd party site is not a solution people will actually want to use.

ZeroGravitas• 17 years ago

It amuses me that there is still good money to be made from lying to paranoid rightsholders about how great your DRM scheme is. Not only do we get middlemen, we get middlement that either don't understand their own technology or are happy to lie about it.

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.

Introducing Typekit

Related Stories