Web fonts - foundries allowing sIFR, FLIR, cufón, @font-face, etc.

Hi,

is anywhere a table showing which foundry supports and allows which webfont technology? I couldn't really find anything close to what I mean, so I put together quickly this draft: http://en.wikipedia.org/wiki/User:Pepa007/Foundries_allowing_web_fonts

Is there something like this already? Or should I publish it and kindly ask you to help me with adding more foundries?

Thank you

Josef

dberlow's picture

The reason this and other posts like it show up here on Typophile, is because of the false impression given by the actual slow-foots, to the general public and including the web designing public, that it is "The Foundries" resisting this, that or the other thing regarding web fonts, and that, hilariously, this Foundry resistance, is why web fonts are taking so long to be perfect, plentiful and free. As things become rendered more clearly on this issue, I hope these posts go away.

Cheers!

apankrat's picture

..and free. As things become rendered more clearly on this issue, I hope these posts go away.

You lost me at "free".

Tomi from Suomi's picture

Me too. In fact that sounds like legal forms embedded in a poem. It do not think that is so cool. But here you go.

Tomi from Suomi's picture

We should not fight these people, but find a common ground.

Hey, I'm happy with you, even though you never took any of my fonts. And my fonts eat your earnings as well.

Ray Larabie's picture

The only reason you were able to download these fonts is because you already knew they existed (and knew the filenames).

It didn't take a lot of figuring out. If someone can identify a font, they don't need to take a lot of guesses to figure out the filename. For example: I sell a font called Soap. Not surprisingly, it's either soap.otf or soap.ttf. Just about every site I checked kept their fonts in a rather obviously named subfolder. The quickstart guide doesn't recommend that the fonts be kept out the the HTML tree. Almost everyone called the main folder somethign very obvious . . . I did too when I was testing. Regardless, the parent to the fonder containing the fonts is plainly shown in the page source as well. As for the sub-subfolder, I could only find one site that didn't use the default folder name. Yes, someone could add their own security but most people do the default . . . apparently.

My embedding/linking requirement is that fonts can't easily be downloaded from a URL. It's not that crazy of a requirement. FLIR qualifies as "easily" because I tried it and it was very easy. I'm not technically adept . . . it took me an hour and a half just to install FLIR, but it only took seconds to figure out the folder path.

It's not just a matter of people taking the font for free. There are lots of ways to do that. It's having honest site owners, installing FLIR and unknowingly posting fonts which can be directly downloaded with an easily guessed URL.

All it really takes is a few spare minutes correct guess at a font file name. Not only do you get a free font but you also get an URL you can share or even remotely @font-face link to. All because the creator of said embedding scheme didn't consider adding any security whatsoever.

One of Fontspring's services is to generate @font-face ready typefaces which, among a few other things generates a random filename. I tested one of my fonts which had been run through Fontspring's @font-face system and it worked with FLIR: no problem. So there you go. My solution will be to require that the obfuscated font be used for FLIR. The price for use on a single domain is exactly the same price as a regular font license so it should be okay.

I like font hacks and admire anyone who tries to innovate. I wish that those who write font hacks had the foresight to make an attempt at keeping the fonts at least a little bit safer from direct downloading. At least safer than setting the default to an easily guessable subfolder of a folder which is shown in the page source.

Richard Fink's picture

>My solution will be to require that the obfuscated font be used for FLIR.

Renaming!
q4r-Tc81G.ttf
What a concept. Works for me, Ray. And if I was using FLIR, I wouldn't want anybody using up my server resources and bandwidth and taking fonts I've payed good money for and, in some cases, spent considerable time sub-setting and improving and converting.
No reasonable site owner or webmaster is going to argue with the logic of this - it goes beyond "protect my font from unlicensed distribution".
It's win/win and should be presented that way.

Just some thoughts regarding the change we're just beginning to go through for whatever bearing it might have on licensing:

For the past fifteen years web designers have been in prison, typographically speaking. Prison "Web Safe". Their meals have been cooked for them, their clothes cleaned for them, every aspect regulated. No thought required.
Soon, they'll have to deal with freedom. It *will* bring a change of consciousness about fonts. Fonts will be seen differently than they are today - as resources that you need to know something about to use effectively.
Today, fonts are this black-box thing you access by writing: "font-family: verdana, sans-serif;"
Today, the average web designer has no concept of "font-family". Font-family is synonymous with "the name of the font". The idea that italic and bold reside in different files doesn't even occur to anybody - why should it? It's been taken care of for them by the OS, out of view, for fifteen years. When it suddenly becomes their responsibility, it's completely different.
I could go on and on in this vein.
It's going to be very interesting to see how designers deal with the responsibility.
And when it *is* their responsibility, they won't treat those resources casually.

rich

dberlow's picture

>I could go on and on in this vein.

Please do: styling, sizing, scaling, rendering, treatments, leading, tracking...

But Prison? I'd say Childhood.

Cheers!

Richard Fink's picture

@dberlow

>But Prison? I'd say Childhood.

Spot on. The prison metaphor sucked but something more apt was eluding me. Childhood much better. Thought of it this morning then saw your comment.
David Berlow: Type Designer and Mentalist.

Of course, I *will* go on about styling, sizing, scaling, rendering, et al.
In the main, web designers don't know what they don't know about fonts.

But here we seem to be focusing on specific technologies and their relationship to EULAs.

rich

apankrat's picture

An update on Linotype. Previously on the show:

I had a really odd conversation with their support, which is in fact still ongoing. In first reply they merely said "we offer web licenses which offer this usage", "this" referring to Cufon. That's it. And asked for a mailing (!) address to send me an invoice. No mention of the fees, restrictions, etc. I replied asking for a balpark estimate of fees, and they replied that they needed to know the exact typeface and asked for mailing address again... you guessed it... for an invoice.

Only 9 days has passed and in response to my

I really don't need an invoice at the moment, just wanted to understand the pricing level and exact licensing terms. If you are set on sending me an invoice, please send it as a PDF to this email address.

now I have received a reply:

Dear Alex,
I can't - I still need your invoice address :-)
Best regards
Xxxx Xxxxxx
Linotype GmbH

Note the lovely smile. It is still like talking to a wall.

Richard Fink's picture

@sii

You don't know what to make of this post and I don't know what to make of your comment.

>It’s kind of like writing a letter to the SciFi channel asking them
>not to cancel Battlestar Galactica.

This means what? If it means that the people commenting here are out of touch, I find that offensive - although I don't believe you mean it to be - and, considering your position and who you work for, rather disturbing. Really.

>The war is over. The browser makers and the font makers have voted,
>and in five or six years we will hopefully see the majority of installed
>browsers supporting WOFF.

This vote took place when? Must have missed it. And what does the majority of browsers supporting WOFF have to do with anything? Please explain.

>Between now and then there will be interim solutions, best served by
>folks like Typekit who provide “fonts as a service” rather than the
>random, often hack-like, solutions currently being promoted.

Says you. If you really believe this, you're scaring me. Have you been watching Caprica?

>As to font pricing and web specific licenses, I don’t think any level
>of pleading from web designers (or the companies, large and small
>who will end up paying for the font licenses) will really make
>much difference – the market will decide.

There doesn't seem to any "pleading" necessary. If someone doesn't want to license to me under terms that I can live with, I just go elsewhere, that's all. Do you think I won't find what I need?
And Sii, it's "the companies, large and small who will end up paying for the font licenses" that comprise the "market" that you say "will decide". You're running around in circles. The browser makers and font makers have decided but the market will decide on their decision. Huh?

I'm glad you like Typekit. I like them, too. Both the guys behind it personally and as a service. But everything has its advantages and disadvantages. One disadvantage to Typekit is that it provides an avenue whereby font makers can say proudly that they are "licensing" for use on the web without really licensing for use on the web. As you can see from the comments here and a quick visit to Fontspring where, (at last count - it's more every day) Ethan Dunham has twenty one font makers who seem to be casting their votes some other way.
Therefore, as of right now, I am formally demanding a recount.
It seems Battlestar is back on.

The other downside to Typekit is that it postpones, among web designers, the learning about fonts and the way browsers utilize them, that must eventually take place.
There's no way around it. Web designers will have to learn some things they don't currently know about fonts. Ain't rocket science.

rich

Ray Larabie's picture

Now, all Larabie Fonts are @font-face linkable. So, I think I'm covered for web embedding now apart from making a chart on my embedding page.

How do I get the ball rolling with WOFF?

dberlow's picture

>chart on my embedding page.
link stink? I get "Page not found"

> Ain't rocket science.

I'm torn — is it that [web typography] "Ain't rocket science"? or is it "Ain't [typography as] rocket science [fun!]?"

>The other downside to Typekit is that it postpones, among web designers, the learning about fonts

Downside? and perhaps the downside of low-iodine salt is that when normal people use it they don't get enough iodine?

Cheers!

Ray Larabie's picture

Yup, link stink. Here it is: http://bit.ly/bbrUgM

Richard Fink's picture

@typodermic

WOFF - AFAIK, the quickest and easiest way to create a WOFF file is with the generator on Font Squirrel. However, the WOFF spec allows you to add some labeling data which the generator makes no provision for. There's source code for WOFF and the spec is published, but as yet, no comprehensive desktop tool I'm aware of for going from a fontfile->WOFF and then from WOFF->fontfile, and manipulating the discretionary data in between. I'm sure a few font designers have home-grown code for it.
However, WOFF is only supported in Firefox 3.6 which was just released and it will take some time for users to upgrade and 3.6 to propagate. (I still can't move to it and get all my add-ons to update to my satisfaction.)
That said, I know for a certainty that desktop tool(s) for working with WOFF are in the queue, it won't be long. Others might know about other options.
There's links here.

In a vein similar to WOFF, there's one other valuable tool I'd like you to be aware of, it's a couple of weeks away from release, but I can get you an advance copy and you can begin using it right away. (Dunham knows about it.)
It's something you and your customers can benefit from immediately.
I'll send an email to the gmail account listed on your site.

@dberlow

>Ain't rocket science
Manipulating font files ain't rocket science. Tables, some code, anything else?
Everything has a learning curve, but provided that decent educational materials exist, it usually doesn't take long for you to get the essentials clear enough in your head to, at least, make intelligent choices. To get to the place where you at least know what you don't know. Of course, as in any field, there are those with exceptional talent for it. But the basics are well within the grasp of the average web designer.

With creating fonts, there is an element reminiscent of ballistics involved. There is the "co-efficient" that still must be provided by the human eye.
Still no substitute.

rich

Ray Larabie's picture

Thanks, Richard. I've updated my embedding page with that info. If you have time, please check it out and let know if it's accurate.

Richard Fink's picture

@typodermic

Will do. Looked quickly, looked OK, but I do have some comments and suggestions. You've been kind of like my first customer, so to speak, and my commercial neurons are now firing at warp speed after a long time on impulse power. Thrusters on full.
Much to do today. Will get back to you.

rich

ralf h.'s picture

In a vein similar to WOFF, there's one other valuable tool I'd like you to be aware of, it's a couple of weeks away from release, but I can get you an advance copy and you can begin using it right away. (Dunham knows about it.)
It's something you and your customers can benefit from immediately.

You're making me curious too.

Richard Fink's picture

The site is up and the product available for download: EOTFAST
EOTFAST is a utility for creating natively compressed EOT files for use with any domain. There are no root string restrictions, as with Microsoft WEFT.
Utilities like Microsoft WEFT, ttf2eot, the Font Squirrel EOT generator, and Ascender's tool for EOT "Lite" are now obsolete.
Savings in file size typically range from 45% to 70%.
For example, a first-rate screen font like Droid Serif starts out at 169kb as a TTF with the full character set but as an EOTFAST file it weighs in at only 80kb. With still the full character set. Compression is lossless.
Please stop by the site to check it out. Further announcements will appear in various forums in the coming days.
The documentation contains very useful information for font designers looking to prepare their fonts for use on the web.

The download package also contains a HTML "EOT File Integrity Test" page and a helpful "fallback" test font.

EOTFAST is a must-have for anyone looking to use @font-face web fonts today or for years to come - for as long as Internet Explorer has a substantial user-base.
Version 2.0 is already in work. I'm using a Beta of it right now. And as soon as certain technical issues are scoped out, conversion from TTF to EOT using EOTFAST will probably appear as an online service, as well.

EOTFAST works to deliver web fonts to half a billion IE users today - not in some distant the future.
I like the WOFF format but it has a bit of catching up to do now, with EOTFAST.

Rich

Stephen Coles's picture

Rich, I commend your efforts, but IE is not the future of the web.

Jens Kutilek's picture

Richard wrote: ... Ascender's tool for EOT "Lite" are now obsolete.

This may be just marketing-speak, but in case it's not: Are you sure you understood the purpose of the EOT Lite proposal? It didn't leave out compression because it couldn't be implemented, but to allow other browser vendors to implement EOT support without any patent issues.

I like the WOFF format but it has a bit of catching up to do now, with EOTFAST.

Why? Tools for web font conversion have already existed for some time, for both WOFF and EOT.

In your blog post about EOTfast you wrote: EOTFAST is released as open-source under the Apache license. Where can I find the source code?

Jens

dberlow's picture

I'll believe it's a dessert wax and a floor topping when I've got my hands on it and tested the in and out puts. :)

Cheers!

Si_Daniels's picture

>Rich, I commend your efforts, but IE is not the future of the web.

This is kind of like saying the future of transportation is not the internal combustion engine. You're probably right, but IE is going to be around for many, many years. IE6 still has more than 20% market share!?

John Hudson's picture

Rich, it seems to me that what you have done is to produce an EOT-creation tool that is easier to use that WEFT. Now, for sure, the relative complexity of WEFT is one reason why EOT never took off in the decade in which it has existed as the @font-face implementation in IE, but it's hardly the most significant reason.

I don't understand why you have made a tool that avoids the (to other browsers) contentious URL-binding aspect of EOT while implementing the equally contentious patented compression. The latter, as well as your commentary, makes it clear that EOTFAST targets IE only, since only IE supports this compression. But IE also supports URL binding, so why have you disabled that?

Stephen Coles's picture

You're right, Si. I should clarify: the future of the web will be seen on many browsers. Support for only IE won't cut it.

Si_Daniels's picture

>You're right, Si. I should clarify: the future of the web will be seen on many browsers. Support for only IE won't cut it.

Agree. Also on many different devices with many different types of display and rendering styles.

Richard Fink's picture

First, more technical news:
Garrick Van Buren has converted Kernest's entire font library using EOTFAST plus - and this one has *me* amazed and astounded - he reports having found an answer to the problems of reliable gzip delivery for fonts of any kind.
More Gzipper Than Ever
Problems with gzip discussed here:
Who's Not Getting Gzip

@jens
>This may be just marketing-speak
No. I'll write sales puffery like anybody else, of course, but something quite that bold, no.
They're obsolete.
>to allow other browser vendors to implement EOT support without any patent issues
Correct as regards EOT Lite. But frankly, EOT Lite seems dead in the water as part of a W3C standard. It's mentioned as an aside in the current web fonts charter proposal.
EOT is the old soldier that we'll have to care for until quietly fading away.
I do not know exactly what is planned for IE9 other than continued support for EOT as a backwards-compatibility legacy thing.
"Don't break the web", meaning, as far as possible, continuing to provide support for existing web pages is an article of faith for the IE devs. People can bitch about conditional comments and versioning strings as much as they want but there'd be a lot more bitching if IE didn't have them. If Firefox pushes out an upgrade and there's a regression in the code, what's the problem? Not a lot. If it was IE, you might not be able to make a withdrawal from your bank. There's a huge disparity in the level of responsibility required which, unfortunately, a lot of people in the web community don't get. I'm interested in seeing if there's any unwanted side effects in the European market in the short term. Interesting.
>Where can I find the source code?
It will be posted but I can't tell you exactly when. On Github or Sourceforge or somewhere. The source for Version 2 will hold much more opportunity for collaboration and I'd rather wait until then. I do feel a responsibility to make sure that the basics are solid, first. I don't know of anybody who's done as much hard research as me and there's a lot more to do, too.
There will be an announcement and a mailing when that happens.
In the meantime, the executable is there for the asking. You're welcome. Will you be using WEFT again in the near future?
>Why? Tools for web font conversion have already existed for some time,
>for both WOFF and EOT.
Implementations, man, implementations. Half a billion or more users can benefit from EOT in IE now, today. FF 3.6 was just released so the pool of users who can benefit today from WOFF is indeed small.

@johnhudson
>one reason why EOT never took off in the decade in which it has existed as the @font->face implementation in IE, but it's hardly the most significant reason.
Oh geez, you've got me singing the song "Turn, Turn, Turn" in my head, now. (Go ahead, all together, now - I'll give you minute...)
Bandwidth, bandwidth, bandwidth. At the time of what I call "Pax IE" when IE6 ruled the roost with no competition whatsoever, it was still largely a dial-up world. Let's not forget how much has happened in the last five years. In this case IE was ahead of the curve. It happens. Even in Redmond. I know it sounds simplistic, but it was just a case of other web development techniques having a greater priority.
As far as URL binding etc.... you're leaving me wondering what on earth we were all gnashing our teeth about last year. Was it a dream? ;) Your questions are reasonable, but let me get back to them.

@stephencoles
>the future of the web will be seen on many browsers. Support for only IE won't cut it.
It sure won't. And you can't cut it without IE, either.
Bottom line: Both EOT and WOFF offer a way to wrap a font file without the encumbrance of root strings and with highly effective compression. In effect, there isn't a whole lot of difference now between the two.
I have gotten the distinct impression that a case was being made that IE's @font-face implementation was in some way fatally flawed, and that the font design community therefore had no choice but to wait until IE caught up before offering licenses under WOFF while avoiding EOT and the huge user-base that can benefit from it.
Now, in light of EOTFAST, what's the diff?
There will be convenient, easy to use tools for both formats.

Richard Fink's picture

@stephen

>Rich, I commend your efforts, but IE is not the future of the web.

I won't go near the claptrappery of a phrase like "future of the web".
But there's this:
Oil is not the future of humanity's need for sources of energy.
I guess you'll be keeping your car in the driveway until that happens, eh?

;)

Stephen Coles's picture

My point is: you need both — EOT and WOFF — for the greatest compatibility right now. That’s why the Web FontFonts released today come in both formats.

Thomas Phinney's picture

No, the two formats you need right now are EOT and desktop fonts. You don't need WOFF for compatibility at all. Web FontFonts are in EOT and WOFF because nobody wants to license desktop fonts to end users for direct web use.

Don't get me wrong: I'm convinced that WOFF will be the format of choice in a few years. But right now it's only supported by Firefox 3.6, so it has a long way to go still.

Cheers,

T

Stephen Coles's picture

> Nobody wants to license desktop fonts to end users for direct web use.

Right. Making that point kind of moot, no?

Thomas Phinney's picture

Not moot... it explains why services like TypeKit are relevant; licensing for EOT+WOFF without desktop fonts misses ~23% of browser users who are on Firefox 3.5 or Safari 3.1-4.0. (Admittedly, that percentage is doubtless decreasing rapidly as Firefox users migrate upwards, with a floor of about 4% Safari users.)

Of course, there's also another ~8% using browsers that don't support any version of @font-face, basically Chrome plus assorted mobile browsers.

Cheers,

T

gferreira's picture

Chrome does support @font-face.

dberlow's picture

It sure does.

Rich, what does EOTFast do when it meets a font with an embedding bit IE does not like?

Cheers!

dberlow's picture

hmmm?

Richard Fink's picture

@dberlow

>Rich, what does EOTFast do when it meets a font with an embedding bit IE does not like?
In version 1.0, it converts the font into an EOT and then that EOT does not work in IE because IE itself declines to load it. This will happen if the embedding is set to "restricted". Whether the EOT is working can be immediately confirmed using the EOT Test page that's a part of the package. Although the test page will not tell you what the nature of the problem is.
In version 2.0 (in Beta), there are user alerts as the conversions take place, telling you exactly what potential problem(s) there might be and restricted embedding is one of them. This is a stop error. No conversion. No point in allowing it to go forward - IE won't load the file.
I considered the idea of checking for a vendor ID of "FBI" and then changing the permissions to allow for embedding but decided against it. Instead there's just a pop up saying, "Google: 'Fonts NBC'". (Just teasing, David.)

EOTFAST is about assisting in the creation of working EOT files. No more, no less.

That answer your question?

rich

Thomas Phinney's picture

Ah, true enough, Chrome 4 supports @font-face at last, been about three weeks now. Anybody know if that's only TTF/OTF, or does it also include WOFF?

T

Richard Fink's picture

@stephencoles

>That’s why the Web FontFonts released today come in both formats.

IMHO - that's what must be standard practice for the foreseeable future.
And I'm really glad to hear it.
Yes, it's more work on the back end - conversions and so forth - but show me a way around it. There just isn't any.
"Waiting For WOFF" isn't a viable strategy. What if the rest of the world decides not to wait around with you?
WOFF is just a transport wrapper that adds nothing to intrinsic value of the font. And it will take years for it to take hold.

@tp
>No, the two formats you need right now are EOT and desktop fonts. You don't need WOFF
>for compatibility at all. Web FontFonts are in EOT and WOFF because nobody wants to
>license desktop fonts to end users for direct web use.
Completely accurate. Although I'm not following the "desktop fonts" and relevancy of Typekit thing in your other comment.

Font services will make sense for a lot of users as long as integration into the page is an easy thing and the fonts look good. Somebody with a freebie Wordpress blog doesn't want to fuss with fonts. Just add some spice to the page.
As far as the fonts looking good - whole other discussion.

blank's picture

Based on this thread I am changing my EULA to be more permissive about some of this stuff. What do people think of the following:

You may not make the font available via the internet either by linking or embedding except as specified below. “Embedding“ and “linking” include, but are not limited to, Typeface.JS, Cufón, sIFR, and directly linking to the font for use with the CSS @Font-Face tag.
II. You may embed the font into an electronic document, such as a PDF file, provided that document allows no editing using the font.
II. You may embed the font into a web site using Flash only if the text contained within the Flash file is static and users are not able to create content featuring the font.
III. You may use the font with software that automatically generates bitmap or vector images, such as Typeface.JS, Cufón, sIFR, and FLIR, provided that you purchase a license for each computer running the software.

Nick Shinn's picture

It's like you shouldn't put a hard-and-fast dated EULA in a font package (which will be "on the shelf" at distributors for years, and they won't want to be constantly updating), but rather a link to a EULA that's current at the time of purchase of the font. Versioned EULAs.

dberlow's picture

>In version 1.0, it converts the (any) font into an EOT...

any font then? regardless of what the foundry set the embedding bit to?
(why did you have to release 1.0 first? what's the rush that's put your speeding tricycle in front of the train?)

>EOTFAST is about assisting in the creation of working EOT files. No more, no less.
... just as a handgun is about chemically assisting matter to supersonic speed. No more, no less.

Cheers!

ralf h.'s picture

Chrome 4 supports @font-face at last, been about three weeks now. Anybody know if that's only TTF/OTF, or does it also include WOFF?

No WOFF, it's working just as Webkit/Safari.
http://www.webfonts.info/wiki/index.php?title=@font-face_browser_support

Apart from Mozilla, no other browser maker seems to be very interested in WOFF at the moment.

Richard Fink's picture

@all

Re: Fontshop's Web FontFonts initiative which I was just looking over.

http://www.fontshop.com/blog/?p=1763

They are saying that EOT Lite and WOFF will reach 90% of web users.
This number is incorrect. It is therefore misleading.
Plus, the introductory sales copy ignores that Safari users and Chrome users will not get the fonts since neither EOT or WOFF are supported in either browser. I find this a step beyond putting a good face on things.

Their technical document:
http://www.fontshop.com/blog/newsletters/pdf/webfontfontuserguide.pdf
also has critically flawed information regarding best-practice CSS syntax and very, very incorrect information regarding Internet Explorer's @font-face implementation.
Flat-out wrong.
Misinformation dispensed from a major font site doesn't do web users, font designers, or anybody any good.
I find this very disheartening.

I urge them to either remove that documentation entirely or mark it plainly as being severely incorrect in parts and under revision.

rich

Richard Fink's picture

@thomas phinney

Aha! Sometimes I'm slow. "Desktop Font" = euphemism for TTF or OTF delivered raw, naked, and steamy - but chopped up. The way the Russians like to eat 'em.

As for Chrome - reported on Dec 12, 2009:
http://readableweb.com/font-face-works-automatically-in-new-google-chrom...

TTF/OTF support has been a part of the current version for quite awhile now.

No WOFF.

Si_Daniels's picture

"They are saying that EOT Lite and WOFF will reach 90% of web users."

No they say that IE + FireFox = 90% of Web visitors which is close to being correct. Of course this avoids the fact that there are versions of FF that don't support WOFF.

dberlow's picture

>Re: Fontshop's Web FontFonts initiative which I was just looking over.

Yes Rich, but it's all legal handling of their IP. You have a problem with that, which should be solved before you start tossing tummy chuck on other efforts.

>I urge them to either remove that documentation entirely or mark it plainly as being severely incorrect in parts and under revision.

And I urge you to remove your infantile software, or mark it plainly as being dangerous to the legal status of its users. :-)

Cheers!

Thomas Phinney's picture

@Richard: Yes, that's what I meant. Glad you figured it out, because I didn't understand what it was you didn't understand. (Heh, how's that for a twisted sentence?)

@Si: Hmmm. Good point. That would be marketing!

Cheers,

T

Richard Fink's picture

@thomasphinney

In keeping with your observations - what Fontshop is doing with the Web FontFonts initiative is called a "bait and switch".
I've studied the advertising styles of the early to mid 20th century closely and in so doing developed a soft spot for hucksterism like this.
(It is today, however, generally illegal. If the customer is "baited" to sign on using false claims and then "switched" to something that's going to cost more. I'd have to look closer to see if that's the case here. But I really don't care.)

Works like this:

1) First, you suck the customer in with what seems like a perfectly reasonable, even juicy offer. 90% of browsers supported! Specially optimized fonts! (Not sure if there's anywhere to actually preview what they look like in the browser on Fontshop - I couldn't find it.) Anyway, at first, everything looks great.

2) Turns out there's a catch that was not immediately apparent - in this case its that fonts formatted in EOT and WOFF won't show up in Safari or Chrome. (You mean I can't post the TTF?) Of course, no web designer is going to want that and so the customer is steered to the "free" Typekit hosting option as a solution. (A solution to a problem that was created by the nature of the sales offering in the first place, of course. Wink. Wink.)

The Typekit hosting service is what's being sold.
The "Web FontFonts" is just a way to steer the customers to it.
(Check close and think about it. Unless I've missed something fundamental, you'll see I'm right.)

Of course, the more trustworthy the source of the offer - Fontshop! - the less likely the customer will be on the lookout for gotchas, so the better it works.

Slick! If Bryan Mason thought of this - Bryan my hat is off.
I thought this kind of marketing went out with the aluminimum siding salesmen characterized in Barry Levinson's classic 1987 comedy "Tin Men" but I guess there's a revival going on.

I'm really starting to like the font business a lot.

Rich

John Hudson's picture

Rich: Unless I've missed something fundamental, you'll see I'm right.

I know that you're wrong, so you must have missed something fundamental. Actually, I'm having a hard time keeping track of how many fundamental things you missed. How about this for starters: we're at a transitional moment in which new licensing businesses are coming along in the midst of inconsistent format support. There is absolutely no obligation on any vendor to provide their fonts in all supported formats in all browsers, and if, in light of the inconsistent support, companies try to provide temporary alternatives to customers who feel they need to implement their designs across more browsers than support the formats offered by those vendors -- any my own customers have indicated that they feel no such need --, that shouldn't be grounds for suggesting that such companies are affecting a con. Frankly, if I were FontShop, I'd be asking my lawyers to review your last post for a possible libel suit, since you have accused them of something that you acknowledge is ‘generally illegal’.

Not long ago, you were jumping up and down demanding that font vendors start licensing fonts for the web and to make clear in what formats they intended to do so, despite the fact that I, for one, thought ‘What's the rush? The browser support isn't where it needs to be yet.’ Now, one of the most respected and successful font vendors is doing just what you demanded, and you are accusing them of doing something both else and nefarious.

This seems to me a grossly unfair detraction.

Syndicate content Syndicate content