Foundries! .webfonts, EOT, or EOT Lite? And Typekit?

Miss Tiffany's picture

Many of you may have already seen the growing list of foundries and type designers who support, and/or at least like the idea of, the .webfonts proposal. I'd also like to get a list together of foundries that support EOT and/or EOT Lite. (I can't find a link to the current propsal.) And while we're at it what about foundries who are going to use Typekit?

This is a lot to ask. But if you could just list your name, foundry, and which format you support. And if you are going to use the Typekit service.

paragraph's picture

I am involved with the Typekit trial, do not understand enough of the other proposals to decide yet. At the moment I rely on my vendors EULAs (MyFonts and Monotype/Linotype/ITC/Faces).
Jan Schmoeger, Paragraph

Christopher Slye's picture

Ascender's EOT Lite proposal is here. Adobe supports it -- which is to say, we like what we read about it and we're giving it a good look.

jeffveen's picture

We're putting together a blog post introducing some of the foundries and designers participating in Typekit's pilot program. We'll publish it soon - likely by the end of the week.

dezcom's picture

Personally, I support proposals which reasonably protect the font from theft and do not burden users or browsers with excessive roadblocks. Both EOT and EOT lite "seem" to do this. The proof is in the pudding though. We will have to see what becomes of the Monotype offer of release of compression sourcecode and the Microsoft offer to release its wrapper. The major browsers need to all be on a level playing field.
As far as type designers go, I wonder what the new deal will do for the hinting regimen.

ChrisL

k.l.'s picture

(As far as type designers go, I wonder what the new deal will do for the hinting regimen. -- This is unrelated to the wrapper format question and depends on different platforms' rasterizers.)

dezcom's picture

Thanks, Karsten--one more issue :-)

ChrisL

kentlew's picture

> Microsoft offer to release its wrapper

I believe the EOT code and specification are already public. I just can't find the link right now.

dezcom's picture

Thanks, Kent!

ChrisL

outrasfontes's picture

Tiffany,

(I can’t find a link to the current propsal.)

The EOT Lite proposal is here: http://www.typophile.com/node/59489
Official announcement here: http://www.ascendercorp.com/pr/2009-07-15/

I'll be certainly with my resellers' positions on that issue (MyFonts, Monotype/Linotype/ITC, AscenderFonts).

But I'm open to analyze any other model that is proposed, except to put raw fonts on the web.

Ricardo Esteves,
OutrasFontes

billdavis's picture

Ascender supports the ideas in the .webfont proposal (and also the .zot proposal). Unfortunately those will take years to achieve widespread adoption. So the only opportunity that we see for a single web font format across all browsers in the short term is EOT Lite.

We proposed EOT Lite to address the two features of EOT that the browser makers objected to: MTX font compression and URL binding. If the browser makers take up Monotype's offer for MTX, then EOT Lite would be an even better solution.

Regardless, EOT Lite provides an achievable solution that would give web designers a single web font format, and access to a large collection of commercial fonts that they desire (and that we want to offer!).

outrasfontes's picture

If the browser makers take up Monotype’s offer for MTX, then EOT Lite would be an even better solution.

It seems that Monotype is making a great offer to the type comunity, giving MTX compression technology to the public domain. With generous actions like that, everybody wins, I think.

I really hope that Mozilla guys can show their positions in a more clear way at W3C forum. I'm spending too much time reading arguments there that seem to be looking for a perfect (impossible) solution. Too platonic for me.

I think the proposals of Ascender (EOT Lite) and Letteror/Typesupply (.webfont 2.1) are much more pragmatic and productive for us all.

dberlow's picture

The Font Bureau supports the ideas in the .webfont proposal (and all other proposals). Unfortunately those will take years to achieve widespread adoption by which time they will offer no more protection than any other format. In the mean time we are publishing fonts with permissions and recommendations included, unique file naming for the web to distinguish them from uses calling by font name, and one other thing.

Cheers!

dezcom's picture

"and one other thing."

A huge guy named Nunzio who knocks on your door with brass knuckles if you rip off the fonts? :-)

ChrisL

Richard Fink's picture

Please excuse my self-promotion, but I do think my explanation of the new EOT format is the most concise and easily understandable treatment I've read so far:
Jeffrey Zeldman Questions The EOT Lite Web Font Format
To bring readers of this site up to date:
So far, even though the new EOT is a reasonable interim solution which would bring web fonts to the most people in the shortest amount of time, the folks from Mozilla FireFox and Opera have said they are "not interested" in deploying it, despite this one great advantage. I'm not sure where Apple stands.
Since it would appear unreasonable to not give reasons for declining to support the new EOT, bullshit reasons have been put forth, in public, in the main forum for these discussions so far, the W3C Web Fonts mailing list.(Don't have the link handy... anyone?)
Failure to deploy the new EOT means delaying any kind of reliable cross-browser support for perhaps as long as ten years.
Please note that there is nothing to prevent a more mature and comprehensive spec such as .webfont or .zot from being developed either alongside or on the heels of an EOT solution.
Me, I guess I'll be boning up on my Adobe Flash skills because the way things are going, that's the only way I'll be able to see what I want to see inside a browser window for the foreseeable future. A shame. Really.

Richard Fink's picture

@dezcom
BTW - the "Nunzio" proposal, too, has been rejected. Unanimously, I'm afraid. ;)

outrasfontes's picture

Since it would appear unreasonable to not give reasons for declining to support the new EOT, bullshit reasons have been put forth, in public, in the main forum for these discussions so far, the W3C Web Fonts mailing list.(Don’t have the link handy... anyone?)

The sad arena:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/

John Hudson's picture

The funny thing about the bullshit reasons given not to support EOT Lite is that 'It smells like Microsoft' seems to me a valid reason and I don't know why Mozilla and Opera are making themselves look foolish coming up with obvious red herrings to try to justify their objection on supposedly technical grounds. :)

Microsoft's resistance to naked font linking isn't supported by technical reasons: it is supported by IP and strategic reasons. As such, it is a much stronger position than the pseudo-technical case that Mozilla and Opera are trying to make against EOT Lite. Microsoft are not trying to invent technical reasons why they won't support naked font linking: they're just stating it as a policy.

crossgrove's picture

Can anyone provide a link to the ZOT proposal?

k.l.'s picture

It's here:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/0018.html
In essence, each of an OpenType font's table is compressed individually.

Richard Fink's picture

The veil of reasonableness, I believe, has now been pierced. It's an open brawl.

Over the past couple of years, in what could be described as an "unseen revolution", the developers of the FireFox browser have acquired an enormous amount of power. With no check on that power - not the "market", surely - that I can see.
I've asked them to whom they consider themselves responsible, but have never gotten an answer.

In a larger sense, the web fonts debate is about accountability.

billdavis's picture

At the top of this post Tiffany asked about a starting a list of type designers and foundries that have come out in support of EOT Lite. Here are the ones I know of:

Adobe
Monotype
Microsoft
Ascender
Bigelow & Holmes
Ray Larabie / Typodermic
URW++
Boutros International
Mark Simonson
Chank
Garrett Boge / LetterPerfect
Ricardo Esteves Gomes / OutrasFontes
Tour De Force
Ronald Arnholm
Dalton Maag
Berthold
ParaType International
ShinnType
Mota Italic (Added on August 4th)

I'm sure there are others - hopefully they will add their names to this post.

paragraph's picture

Bill, if you can babysit me a bit, you can ad me and my free fonts.

Thomas Phinney's picture

Interestingly, the W3C discussion of EOT Light as a possible interim format has gotten increasingly reasonable and in-depth in recent days. The Mozilla/Firefox people seem to be seriously entertaining the idea.

I had originally thought that having EOT Lite as a stepping stone towards another format was kind of redundant and that nothing else would probably happen. But the non-Microsoft browsers have a strong interest in something "better," for the long run, and even Microsoft seems amenable to a two-stage solution, so who knows?

Regards,

T

dberlow's picture

That's Great Thomas! It is not embedded, it's not opentype, and it sure isn't lite anymore, why not have a 2-stage solution, if one won't work!?

Cheers!

davidmarshall's picture

> I’m sure there are others - hopefully they will add their names to this post.

I'm delighted to add Dalton Maag to this list.

While we would be happy to offer our support to any format which ticks all the right boxes, EOT Lite is the one which we believe has the highest chance of cross-platform, cross-browser, and cross-device success. And the only realistic proposition for fast roll-out.

We'd also like to see an easy-to-use and thorough subsetting tool (but that applies to font files in general) and ideally opposition to MTX fall - both on grounds of keeping the file compact to deliver real benefits over raw fonts.

If MTX doesn't gain traction, I would advocate an, if you like, extension to EOT Lite which allows the whole content to be compressed using LZMA. Obviously no out-of-the-box IE support for that, but there's no IE support for CFF either, so once it's in the spec, that may come.

Dave

Nick Shinn's picture

Bill, I supported EOT lite in the first thread you proposed it.

_Nick Shinn, Shinntype.

billdavis's picture

Thanks Nick! Sorry I missed that.

Also Christopher Fynn has expressed his support.

Bill

rob keller's picture

Our new foundry »Mota Italic« is in favor of solutions along the lines of .webfont and EOT Lite. The idea of subscription and javascript options are not very interesting.

We are happy to allow users to be able to host their licensed fonts on their own servers. For the time being this means modified .ttf fonts, but in the future, we would likely move to a web-specific format.

In regards to EOT Lite, have I missed something or has there been any announcement as to when Ascender will share their EOT-Lite-font-making capabilities?

Cheers,
Rob

billdavis's picture

Hello Rob,

We are pleased to announce our tool for qualified type designers and foundries to create EOT Lite fonts from their TTF or OTF fonts.

More information about what this tool does is available on our website:
http://www.ascendercorp.com/info/eot-lite-wrap-tool/

If you are are interested in a copy, just fill out the contact form on the site to send us a note.

Bill

paragraph's picture

Hello again, Bill. Do you want me on board or not?
Jan Schmoeger, Paragraph

Nick Shinn's picture

Thanks for providing this tool, Bill!
I will contact you soon to get a copy.

aluminum's picture

"for qualified type designers"

If EOT is, at least in part, an attempt to add some layer of 'security' isn't that arbitrary EULA clause a weak point?

Thomas Phinney's picture

There's not *much* protection in EOT Lite, but it is a tad more than for raw/naked desktop fonts.

What with the .webfont and ZOT proposals having merged, I am reasonably sure I like the direction of that proposal and think font vendors and type designers should back it. This does not preclude also supporting EOT Lite as well, however.

Regards,

T

k.l.'s picture

Link to the new proposal, ZOT + .webfont = WebOTF:
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1238.html
This is an elegant solution, combining ZOT's file structure with .webfont's xml metadata file. Worth supporting. So there is EOTL to serve the past and WebOTF for the future.

It seems that foundries are "updating" their support:
http://typegirl.tumblr.com/post/142912558/most-of-the-important-foundrie...

Karsten

dberlow's picture

>There’s not *much* protection in EOT Lite, but it is a tad more than for raw/naked desktop fonts.

I think what you mean, is the OpenType format, is a little older.

So, EOTL's protection is Time, as in — the time between when the tools get into the hands of 'qualified' designers, until those tools are in everyone's hands, after which EOTL is naked as Adam.

>This is an elegant solution, (= WebOTF:)

...and I will fully support it when is allows its vast swath of meta-data to include the hinter's uncle's dog.

And, WebOTF's protection is Time, as in — the time from when the tools get into the hands of 'qualified' designers, until those tools are in everyone's hands, after which WebOTF is as naked as Adam and Eve.

Don't ever be fooled; unless the format you're supporting the serving of has Electronic Permissions and Recommendations, being on these support-the-format lists is for the improperly informed, just properly afraid.

Or, do people out there actually think I, who quantitatively need more protection than most of that WebOTF list (combined), don't want protection too? ;-o

Cheers!

dberlow's picture

>There’s not *much* protection in EOT Lite, but it is a tad more than for raw/naked desktop fonts.

I think what you mean, is the OpenType format, is a little older.

So, EOTL's protection is Time, as in — the time between when the tools get into the hands of 'qualified' designers, until those tools are in everyone's hands, after which EOTL is naked as Adam.

>This is an elegant solution, (= WebOTF:)

...and I will fully support it when is allows its vast swath of meta-data to include the hinter's uncle's dog.

And, WebOTF's protection is Time, as in — the time from when the tools get into the hands of 'qualified' designers, until those tools are in everyone's hands, after which WebOTF is as naked as Adam and Eve.

Don't ever be fooled; unless the format you're supporting the serving of has Electronic Permissions and Recommendations, being on these support-the-format lists is for the improperly informed, just properly afraid.

Or, do people out there actually think I, who quantitatively need more protection than most of that WebOTF list (combined), don't want protection too? ;-o

Cheers!

Nick Shinn's picture

...for the improperly informed, just properly afraid...

No, it's just a business strategy.

The reason I endorse a fragile wrapper is that it will alert those who are mostly honest or don't know better that copying is prohibited, not because it will provide an impediment to those who are determined to steal.

John Hudson's picture

Right, Nick. There is no protection against deliberate theft, there is only protection against casual misuse. I've lost track of how many times that has been clearly stated, and I'm surprised if anyone is still confused about this.
_____

Don’t ever be fooled; unless the format you’re supporting the serving of has Electronic Permissions and Recommendations, being on these support-the-format lists is for the improperly informed, just properly afraid.

Since your EP&R proposal is for a font table, it can be included within any wrapper that wraps an sfnt font. The latest WebOTF proposal used the ZOT compression model, which compresses individual tables rather than the whole font, so a tool could efficiently decompress just the EP&R table to check permissions and recommendations, without needing to decompress and load the whole font first.

I'm still far from clear who you think is going to look at this table and what you think they are going to do with the information in it.

aluminum's picture

"There is no protection against deliberate theft, there is only protection against casual misuse."

How big of a problem is that, really?

"I’m still far from clear who you think is going to look at this table and what you think they are going to do with the information in it."

Same here. That's the one part that (from what I've read) really hasn't been explained yet.

rob keller's picture

Thanks Bill! Looking forward to trying out your tool soon!

Cheers,
Rob

dberlow's picture

JH>there is only protection against casual misuse.
JH>I’ve lost track of how many times that has been clearly stated,

Then let's have at it!

Let's first assume we are no longer sitting in class at the organic free-range typographic charter school, so I'm not interested in a lesson that says; 'it's like if you leave your money on the ground outside your car, vs. in the car unlocked' little boy. Let us talk fonts instead.

Users place a font on a server, and then write javascript and/or html/css to refer to that file. Just exactly what in any format is going to prevent that? Now, John... please.... define Casual Misuse, Today, and 5 years after any new format is released.

>I’m still far from clear who you think is going to look at this table and what you think they are going to do with the information in it.

You would need to task yourself seriously to thinking the development of web font business over time, technology and (especially) users from; "I don't know anything" to; "the web site is up'.

Or... are you going to claim casual misuse is a major issue, then not think about or satisfy, the needs of casual users? :-(

Cheers!

Nick Shinn's picture

David, have you been skipping school for 20 years?
The lesson of DTP is that despite the ease of font copying and the lack of punishment for transgression, not to mention the corrupting influence of font bundling and freeware, an indie font industry has emerged based on retail purchases. Please explain how that was possible, and why would things be different for web fonts, or go stand in the corner.

Richard Fink's picture

@nick

Tough to argue with an "existence proof". But if anyone can do it, I believe Mr. Berlow can!
The way things are playing out, with a little bit of luck and, I'm assuming, the continued good faith of those parties so far participating, I believe we'll see an outcome similar to the one you describe with DTP, with web fonts.

outrasfontes's picture

BTW, I've been testing EOT Lite fonts (generated by Ascender's EOTLiteWrap
software) and it looks fine in IE and in Firefox test build. I hope that Mozilla
can release this version soon as a Firefox update.

In the case we have more than one specific web format (WebOTF, EOTL, WTF, whatever) working in different browsers, that seems not to be real a problem.

Let's supose that we have Format 1, that works in Browser A, B and C and
Format 2 that works in Browser B, D and E.

So Foundry/Vendor X can analyze the pros and cons involved and decide
to licence its fonts using Format 1, Format 2, or both maybe, or even none of them.

For now, I'm beta-testing everything that is possible.

John Hudson's picture

David: Users place a font on a server, and then write javascript and/or html/css to refer to that file. Just exactly what in any format is going to prevent that? Now, John... please.... define Casual Misuse, Today, and 5 years after any new format is released.

Typical example of casual misuse of naked font linking: user has a font on his or her system and wants to use it to display text on web page. User has no clue where the font came from or what license terms may apply to it, only that it is available and he or she likes it. So the font is uploaded to a server and linked to as you describe. This is the first casual misuse. The second casual misuse happens when someone writes to that user and says 'Cool font! Where can I get it?' and the first user says 'Oh, you can download it from my server'. The third misuse happens when another user links to the naked font on the server to display text on his own website. The presence of a permissions and recommendations table in the font to which no browser pays any attention and that the user never sees seems to me to have no impact on this scenario.

Now consider the impact of a format distinction between desktop and web fonts: the existing fonts on the user's system are not useful on the web because they don't offer cross-browser interoperability. The user has to either get a new license and a new (customised, serialised, PERM'd) font, or has to figure out a way to make a web font. Either way, the very fact that some action is required raises the question 'Why?' which is directly answerable in terms of the existing license agreement. Simply put, the format distinction provides an opportunity to educate the user about the license, which is the distinction between casual and deliberate misuse.

blank's picture

Typical example of casual misuse of naked font linking: user has a font on his or her system and wants to use it to display text on web page. User has no clue where the font came from or what license terms may apply to it, only that it is available and he or she likes it. So the font is uploaded to a server and linked to as you describe.

Do you honestly think that people will casually sift through their browser cache looking for interesting fonts to use in their web designs?

John Hudson's picture

I'm not talking about browser caches, I'm talking about the fonts that people have installed on their systems, most of which most people have no idea where they come from: fonts that come with the system, fonts that come with applications, fonts that some friend installed on their machine, etc. Most people have no idea that font licenses even exist, let alone what these licenses permit or do not permit. This leads most of the font makers I know to be concerned that naked font linking is basically just an invitation to give away all existing TTF/OTF fonts. Moving forward, with a viable interoperable format and appropriate license metadata etc., font makers can provide web fonts and earn some money from this use, but only if they're not competing against massively widespread unlicensed use of existing desktop fonts on the web.

blank's picture

Sorry, I misunderstood you.

dberlow's picture

Yes James, Now you understand! Nobodies are stealing our fonts, and we have to do nothing to stop them, never.

JH> Typical example of casual misuse of naked font linking: user has a font on his or her system and wants to use it to display text on web page. [etc through 3 examples where obvious 'nobodies', casually copy, serve and link unlicensed font IP, supposedly because it's 'naked' (OpenType)]

Bought your red herring argument at the red herring argument store?

John's 'casual users' are either Fired by Legal eventually, or they are Nobodies we'd never get a license fee from... ever. All three 'casual misuse' examples are happening soon-as-can-be in another format, just as "casually". Users will send each other EOTL. Users will serve each other EOTL, and users will link to fonts on other's servers, in EOTL.

JH>The presence of a permissions and recommendations table in the font to which no browser pays any attention and that the user never sees seems to me to have no impact on this scenario.

If no browser can pay any attention to, and no user can ever see anything from EPAR or metadata of a truly useful nature, ever... is that the better scenario then?

A lot that was impossible, becomes possible with EPAR, for all formats 'downstream' and as OT is...

JH>This leads most of the font makers I know to be concerned that naked font linking is basically just an invitation to give away all existing TTF/OTF fonts.

OT is a web font format recommendation of the w3c. If a founder does not have a licensable OT font for the web, and there is nothing else for a developer's browser(s), (for years) what is that an invitation to do?

So... this fear is not resolved by the means most of the font makers I know are being ponded into. And as you can see, the demonization of EPAR has begun! "It will never do anything for anyone ever, so why do it?"

Ironically, I said the same a long time ago about any new format, then talked to 100's of clients and types, looked at thousands of types on clients, read a mozillion words from users, developers, permitters and recommendor's, confirmed that no new format will work, and that's how I got to EPAR.

How'd you get here, John? What's your motive? Who do you represent?

Cheers!

Syndicate content Syndicate content