I don't think you're going to get many type industry people to support this when you use a look-alike of a well-known commercial typeface (Optima), which was designed by Hermann Zapf, a type designer who almost stopped designing typefaces because of people copying his type designs.

what Mark said.

Despite raising hackles with two of the three types showcased as Mark points out... it looks like a lot of excellent work went into this. A couple of thoughts that will really encourage support:

• Can you protect the .js file so it is server specific and cannot be linked-to?
• Can you alter your conversion tool to respect the embedding preferences already included in fonts? ie if no embedding, then no conversion.
• Can you make the drawn text selectable/copyable?

What is a typical bandwidth hit to implement this?

Thanks for your efforts.

That's impressive! Not sure if it's any better/worse that good ol' sIFR, but that's some impressive work.

I don’t really know enough to comment from a technical standpoint, and I’m not sure that you’ll be able to gain traction in the face of Flash and @Font-Face. But it’s a pretty brilliant idea, and reads well even without hinting. Does it kern?

is the resulting text still 'live'? if not, i don't see the improvement over static images.

That seems like a fair point about the look-alike fonts -- I'll probably swap them out for something more appropriate.

Can you protect the .js file so it is server specific and cannot be linked-to?

I can put up some hurdles at least, but I haven't look too far into that yet.

Can you alter your conversion tool to respect the embedding preferences already included in fonts? ie if no embedding, then no conversion.

The conversion tool does respect embedding preferences.

Can you make the drawn text selectable/copyable?

At least in Firefox (and maybe in Safari too), you can actually select and copy the text, but you just don't see the text being highlighted as you select. It might be possible to add support for highlighting.

What is a typical bandwidth hit to implement this?

A typeface.js font ends up being usually a few tens of kilobytes, so not too bad at all. It will be cached by the browser, and so visitors should only need to grab it on their first page load.

Does it kern?

There's no support yet for custom hinting or kerning, but it's certainly possible to add those features in with some work.

I think kerning would be a key feature to have. That and giving the maker of the font at least the option to not to give it away for free.

Some people asked the advantage it has over flash. And that's simply for people on devices that don't use flash. While Opera Mobile supports it, Opera Mini doesn't, but does support javascript.

BTW; I tried it with Ælbrocan, and got some interesting results. Does it have a complexity limit or what might have caused the difference between http://coruna.elahorcado.net/js_test.html and http://coruna.elahorcado.net/frakturTest.html (the latter uses font-face designation and so needs Safari or similar)

«El futuro es una línea tan fina que apenas nos damos cuenta de pintarla nosotros mismos». (La Luz Oscura, por Javier Guerrero)

is the resulting text still ’live’? if not, i don’t see the improvement over static images.

Tremendous bandwidth and labor savings are big advantages. For example, a newspaper site could have all headlines in its own custom headline face as soon as a story goes live with no need for a person to generate and/or check an image, and not incur the cost of readers downloading every single headline image. For a site like NYTimes.com or ESPN.com this could be a great way to reinforce a brand at little cost.

It works beautifully on the iPhone (no Flash).

I'm on firefix/windows and the text is not selectable.

"• Can you alter your conversion tool to respect the embedding preferences already included in fonts? ie if no embedding, then no conversion."

I don't think this is the worst idea I've ever heard, but close. "Embedding preferences"? Embedding permissions! are labels on fonts for THAT PURPOSE, and no other(s). Since this is not embedding, and has little to do with PDFs, I don't understand, yet, why folks think embedding permissions can be used for web font linking. But I'm finding out.

Cheers!

What the hell is Optimer... is it the same as Musicer? You are right Mark, Zapfer will not be happy!

Michael

David Berlow, thank you for the compliment!

As a maker of type, I think font linking is a bad idea. The winning "solution" to font choice on the web is coming, and I hope font-linking aint it. By my suggestions, I'm trying to move this solution to a more "embedded-like" (EOT) option, which I prefer. That is why I am advocating for it to be domain/server specific. That is also why I wanted embedding permissions (!thankyou) to be respected. It would be nice to have a time machine, go back and create a permission for font linking, then journey back and ask David Chester to respect that. Or you could hope his users read your EULA.

Well, as David says, if I allow my fonts to be embedded in PDF documents, that doesn't mean I allow them to be converted into .js fonts/

Specific ".js" permissions would be needed.

Is there some way to include information in a font which permits it to work only at a specified URL?

Do we really need to complicate EULAs to that extent?

I'm still trying to figure out why PDF embedding is a big deal. I don't even want to bother with flash and js and css and...

David Chester was kind enough to ask for input from the type community. Rather than respond with a squabble about embedding vs pdf vs blah blah , I think the feelings could be summarized thusly:

Type Designers:
• Please don't make your solution a vehicle for freely distributing our fonts.
• If you can prevent (or strongly inhibit) theft of our fonts, your solution becomes much more attractive to most foundries.

Type Users:
• Thank you. It is nice to have alternative NOW in situations when Flash (SIFR) wont do.
• Please add kerning
• Please make all browsers selectable
• Please keep working on the features you're planing!

Aluminum: I'm with you. If readers have to buy fonts to view PDFs: what is the point of a Portable Document Format that isn't portable?

Nick: Specific .js permissions would be needed -- Hence the need for the time machine in my comment. Such permission doesnt' and probably never will exist.

This is imo pretty revolutionary, but I do agree on the permission debate. I think rendering happens on the machine of the user so they would really need the font file to make this work, right? I highly doubt this could actually work with 'real' fonts, because of the permissions etc. Who's going to give away his fonts for free? This might be the biggest thing to work on atm.

I really love what you've done so far!

Very interesting! How widely supported is VML?

T

"...font-linking aint it."
But it's here already and i t i s n o t going away. You are aware of this are you not?

"By my suggestions, I’m trying to move this solution to a more “embedded-like” (EOT) option"
Oh. Then you should lobby for doing so without making a format that can ONLY contain fonts.
By my suggestions, I’m trying to move this solution to work with what's already in place, that's actually meant as a solution for the problem at hand.

"Or you could hope his users read your EULA." and...
Or, one could want linking permissions, and a EULA to match and then not care unless it was legally appropriate.

"Type Designers:" then "Type Users:"
What are you talking about in this whole section?

" If you can prevent (or strongly inhibit) theft of our fonts, your solution becomes much more attractive to most foundries."
This is nowhere, I can't believe I'm still hearing it — a lot of people are getting lost in thought on preventative solutions.
I'm primarily interested in enforcement abilities where it counts, and I think more will join that view.

"If readers have to buy fonts to view PDFs:..."
What are you talking about? Has anyone ever had this experience?

"Do we really need to complicate EULAs to that extent?"
Look, if it is your business to grant licenses to font software in exchange for money, then you have to do the work, write the agreements, and as much as technology allows — to place notices of permissions in the fonts themselves. If it is not your business to grant licenses to font software in exchange for money, or you don't feel like it, then don't.

I do not yet believe the founders who have businesses licensing PDF permissions, are truly supportive of "dual purposing" the embedding bit.

Cheers!

Do we really need to complicate EULAs to that extent?

We should do whatever is most appropriate.
There are severe requirements on licensing major graphics software applications, requiring serial numbers that restrict their use to specific computers, and that is a part of doing business if you're a graphic designer.
We're not talking about $4.95 scrapbook script fonts here, but professional font software products that, when a family is licensed for multi-user use, can cost much more than Quark XPress.

But nick, if you're going with that analogy, it's flawed, as I only need to worry about purchasing the software for myself, not my audience.

In the end, obviously vendors are free to put whatever license they want on their product and consumers are free to decide to accept it or not.

It seems that most of the EULA restrictions on fonts have less to do with making more money based on the client, and mainly fears of somehow people copying the fonts. If it's the latter, than I think that's a silly thing to dwell upon.

On the other hand, if there's money to be made in tiered embedding licenses, then I could at least concede a business argument for it.

I only need to worry about purchasing the software for myself, not my audience.

Software is not purchased, it's too slippery. It's licensed, hence EULAs.
You need to worry about the terms of the EULA, and the fact that the web sites you design may be breaking it by distributing the software to your audience, or by making it easily available to piracy.

"...a silly thing to dwell upon."

So much for fair play and the rights of content creators.

"...money to be made..."

Can't we frame this discussion in less mercenary and adversarial terms?
Let's move beyond permissions vs. restrictions, profits vs. theft.

"Software is not purchased, it’s too slippery. It’s licensed"

Legally, yes. But that's now how consumers see nor want it. ;o)

"So much for fair play and the rights of content creators."

Their rights are granted already via the law.

"Can’t we frame this discussion in less mercenary and adversarial terms?"

That would be the ultimate goal. Not sure where to start, though.

Going back to this particular technology, the customer would see it as a nicety as they can now have another option to use a custom font choice.

The reaction in this thread, though, from the font vendors seems to be that they may not like the idea of people using this technology with their fonts.

Is that an issue? If so, is that an issue for the technology creator (davidchester), the consumer (obeying EULAs) or the font vendor (pricing? enforcement?) to resolve? Can it be resolved? Does it differ than current uses with sIFR and the like?