

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

======
wysiwtf
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.

------
ori_b
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.

~~~
jerf
"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_b
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.

~~~
jerf
_Start_ breaking? This is still no change.

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

------
hellweaver666
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.

~~~
batasrki
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.

~~~
jerf
"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/>

~~~
batasrki
"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 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.

~~~
run4yourlives
Most likely it is: 1\. Load font.

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.

~~~
mishmash
Define forever? ;)

------
run4yourlives
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.

~~~
wysiwtf
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.

------
ZeroGravitas
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.

