In recent days, Daggett has made it pretty clear that he/Mozilla don’t have much interest in EOT Lite. I am not convinced his arguments make much sense, but that doesn’t really matter. No is no.
It's not particularly clear to me. I haven't seen him say "no".
Just when you thought a moment of clarity emerged from the recent TypeCon mega-panel, the water gets murkier once more.
>Proprietary in what sense?
I meant that they have their own software and services that they rent to you.
Bill: ...where do you think that leaves the other initiatives...
Very much on the table, especially .webfont and ZOT.
We didn't talk about ZOT during the TypeCon panel, but it is a serious contender for an interoperable web font format. It's probably the simplest of the options being considered, but isn't as flexible as .webfont because, like EOT, it is very OpenType-focused, whereas the wrapper model of .webfont could be applied to other kinds of font data in future.
ZOT applies compression to individual OpenType tables, rather than compressing the whole font as in .webfont. ZOT contains much less extra-font metadata than either .webfont or EOT/-Lite. ZOT was proposed by Jonathan Kew, who used to work for SIL where he developed the brilliant XeTeX page layout program, and who now works for Mozilla.
David's perm table idea, like FontLab's EEULAA table, is orthogonal to the web font format discussion: anything that resides in the font data itself will be included within any web font wrapper. Regardless of what wins out as the interoperable web font format, the idea of license permissions, serialisation and other kinds of customised metadata in the font seems to be an idea whose time has come; indeed, whose time came some time ago!
Peter Biľak's approach seems to me a hack and a short term solution in response to the current situation. I don't think it is a viable web font format for the long term, and I doubt if Peter thinks of it as such. It should be noted that he supports the .webfont proposal.
Chris, John Daggett's opposition to anything EOT-related does seem pretty fixed. If he hasn't said 'No' in so many words, he has certainly said it in as many other ways as possible. I don't take this to mean that it is impossible that Mozilla will support EOT Lite, only that if they do it will be grudgingly and probably only after a lot of fighting.
Interestingly, the people on the W3C list who are now putting most pressure on Mozilla and Opera to support EOT Lite are web developers who want a format that provides immediate support to millions of users via various versions of IE and which will be backwards compatible, and who don't want to wait for a new format to be standardised.
Dagget didn't say no explicitly, but he's trying to reject anything that smells like Microsoft (as someone said here), giving nonsense excuses without analyzing it.
"I meant that they have their own software and services that they rent to you."
I don't think there's anything proprietary from a technical standpoint.
John, you write that:
David’s perm table idea, like FontLab’s EEULAA table, is orthogonal to the web font format discussion
Acutally this is well in line with Mozilla's attempt to push ZOT. Mozilla/Opera argue that metadata could be placed in a normal font table, which is what both PERM and EEULAA are far as I understand.
Peter Biľak’s approach seems to me a hack and a short term solution in response to the current situation.
I would not call it a hack. It is a service, like WebKit is. It implies more than just the technical aspect of font linking, it also covers choosing and licensing fonts. I assume that if EOT Lite or .webfont or ZOT or whatever else someone will come up with has been implemented, these services will switch to the "safer" font formats -- without loosing their service legitimation.
Best wishes! Karsten
There are people who still use IE? How unexpected. That should hardly be the target audience for anything design related these days.
We've done some nice web fonts, and since it seems to be the industry standard at least for now, they are now available in .swf format at http://www.fontcraft.com/fontcraft/?p=1178
It's a starting point, anyway.
Dave NalleScriptorium Fonts
As far as Mozilla's opinion, I haven't seen a firm "no" regarding the new EOT.
Would they rather not do it? That certainly seems to be the case.
What I've seen so far are preferences dressed up as arguments, and fairly exposed as such.
It's time to put the F back in WTF.
I'm not so sure they're ready to deny the web developer/design community Web Fonts for at least an additional 5 years (if not forever), over a refusal to treat a file with an .EOT extension as if it had an .TTF extension, which is, essentially, all that is being asked of them.
Indeed, at least Robert Callahan has said he would like input from the web design community.
The new EOT, EOT Lite, has been in existence for less than fours weeks!
Karsten: I would not call it a hack. It is a service, like WebKit is.
I was referring to what I understand to be the served format and the mechanism used to obfuscate the font and prevent it from being installed as a desktop font. As I understand it, this involves deliberately corrupting the name table, which is why I characterise it as a hack: something contrary to the font specification.
I agree that the Typotheque service is just that, a service à la Typekit and Kernest, and the served format is irrelevant to that and, hence, the service is orthogonal to the format debate.
Perhaps, since in this context a font is not (supposed to be) installed on a local computer, these hacks are acceptable. Perhaps acceptable even within .webfont, .eot or .zot whose file suffixes signal that these are web fonts. Not acceptable though if these hacks were applied to .ttf or .otf "web fonts" delivered to customers since these miss a "no desktop font" flag.
Richard: The new EOT, EOT Lite, has been in existence for less than fours weeks!
And Firefox 3.5 has been out for less time than that, supporting naked font linking. If you could guarantee that the outcome of a longer process would be Mozilla support for EOT Lite and definitely not IE support for naked font linking, then I think font makers would be less of a rush to see something like .webfont or ZOT embraced as a single interoperable format.
If naked font linking is taken off the table as an interoperable format, I don't much care which other format wins out in the long run so long as it contains the minimal level of protection against casual misuse that the majority of font makers have indicated they would accept. EOT Lite isn't going to go away, and Ascender's strategy seems a good one: make EOT Lite a significant presence in the market with the benefit of backwards compatibility and major foundries licensing for and providing web fonts in the format. Frankly, I'm not sure that Ascender would want EOT Lite to become the subject of a W3C working group, as they might get more mileage out of establishing it as a de facto standard rather than working to make it a de jure standard.
Back when this debate started with Opera's support for naked font linking, Håkon Lie had the idea of letting the market determine the format, thinking that naked font linking would win out because of the relative ease it offers to browsers and web authors. I think he badly underestimated both the resistance of the foundries and also of our bigger customers, who want a format that protects their own font IP. He also didn't anticipate EOT Lite, which -- credit to Ascender -- has completely changed the nature of the debate and put the non-IE browsers on the defensive. Now you, and I anticipate other web designers and publishers, are pressing that advantage and I think this is a good thing.
Today, if the market were allowed to determine the format, I strongly suspect that EOT Lite would be the eventual winner. What I'm not willing to accept, though, is that we might end up with multiple interoperable formats including naked font linking. This is why a commitment from browser makers to a different interoperable format such as .webfont or ZOT, acceptable to everyone on both technical and political grounds, is attractive to me: the non-IE browsers get to duck out of supporting EOT Lite in return for accepting that naked font linking is dead-in-the-water.
I suppose much depends on how likely one considers it that the non-IE browsers, and Mozilla in particular, will cave and support EOT Lite without any reciprocal agreement from MS to support naked font linking. This is, I suspect, where the interests of font makers and the interests of web designers diverge: because while web designers might want EOT Lite on the basis of its backwards compatibility, they don't really care whether naked font linking also becomes interoperable, whereas font makers and some of our customers care very much indeed. If web designers and authors such as yourself want font makers to stick with you in demanding cross-browser support for EOT Lite, rather than letting the non-IE browsers opt for .webfont or ZOT instead, you need to make at least a strategic commitment to rejecting naked font linking. A quid pro quo alliance between font makers and web designers supporting EOT Lite is certainly possible.
PS. I've read Robert Callahan's contributions to the W3C list, but I don't know who he is or what his stake in this is. Can you enlighten me, Richard?
>I’ve seen that as well on some machines running the latest FF 3.5 (not a beta). No idea!
Search previous threads on 'vertical metrics' or "chopped off".
> you could say that alignment zones and stem hints are fundamental to the digital graphic culture we now have...
Nick... I and other designers want to add the intra and inter glyph white-space to that fundamental list to make possible an end to typographic "x abuse" (we see a lot in this site). But the two main owners of TT/OT think the list is long enough at 2 things, alignment zones and 'page color'. And though ISO, the web's users, and I 'want it' otherwise, "type scaling" is set up that way by MS and Apple. Though all of the technology to handle readable web type exists, basically "it's resolution's fault" that you can barely ever have optimal quality for your needs.
Then, One could say that this web site's apparent use of @font-face suffers from low resolution typographic x abuse the site developer has absolutely no control over with these or most outline fonts, now or ever.* And the site suffers @font-face abuse from the user's perspective. I.E. the definition of the top 3/4 of the page as 2 assets, for the foreseeable future, does the user absolutely no good in transmission speed, and may in fact end up with that lovely script text appearing as Verdana, likely doing the publisher of the website nearly no good. Render unto pixels, that which is their due.
That covers text and display type on this type. But the sub heads, they are very nice and I like the color scheme.
@Hudson> This is, as Si Daniels put it, the ’elephant in the room’ that no one is talking about.
Thanks John for repeating a not entirely completely untrue statement. Since 2004 when the final hinting/fontformat/OS environment was being described for its eventual 2007 release from Longhorn into Vista, I and quite a few others have never called this issue an elephant in the room. ;)
Otherwise, "web text readability" has been a rather huge topic here and elsewhere. Search on that instead of 'elephant' if anyone is interested. The fact that learned type people are supposing an emergency availability situation, and are supporting a new font format to utterly exacerbate the beast raw into a naked and raging elephant, is what surprises me.
>The so-called ’web safe’ fonts like Verdana,
...are, as John correctly points out, safe by availability and by contour design, and at 13ppx Verdana is particularly safe because it was drawn to fit that size, (delete the hints and it works about the same at 13, when anti-aliased). But mostly, web safe fonts are safe simply from their original selection as part of a class of published digital outlines to accompany everything; as Courier, Times and Helvetica (et al), are familiar enough for users to "fill in the blur" of the bad sizes, they just barely work. While Verdana et al are by contour design, made to minimize the blur by maximizing critical font-wide type design features, also in familiar forms people are used to.
>...I’m cooking something up to help web typographers with that....
I call help, 'recommendations'. When taken from groups of fonts, a data-base of recommendations will provide a web typographer with a 'ball park' to start testing, or just go with the recommndation, for any particular use. I'd love to see what you cook up but people think adding this meta data to the OT font specification is the quickest and only way to begin addressing web text readability education on the scale required.
>...Microsoft needs to rethink how it helps type designers with designing fonts
See what happened on this forum when I quested for a clear cleartype specification in '05? Search on "giant pile of excrement", as far as I recall.
>I realize that there are some strong arguments in favor of manually-hinted TrueType fonts with deltas for different sizes...
You must mean Variations for different sizes. :) Deltas, they may be, that term has been demonized to an evil size-specific blot. Search on "Superpolator"
*Unless e.g. you set your OT/@FF-friendly browser's text size to medium, then go to:http://www.fontbureau.com/test/franky/
...there you can futz with the site's typographic size and weight controls outside of the evil grip of everyone but me and some of my crazy ideas for "elephant training."
Remember, set your OT/@FF-friendly browser's text size to medium, set your OT/@FF-friendly browser's text size to medium. Don't forget, set your OT/@FF-friendly browser's text size to medium.
Also: You can steal these fonts now if it suits you. Or you can wait, and steal better ones later. Or you can wait until the new font wrapper everyone is so hot for, is thoroughly undressed by time as it surely must be to be accepted, and then you can steal these fonts from that format. See!? Lots of choices! Sorry for the L.P.
Dave: There are people who still use IE? How unexpected. That should hardly be the target audience for anything design related these days.
That makes as little sense as saying only design-related books should be designed or that if readers do not consciously care about design then typography is irrelevant because those readers are not 'the target audience'.
For those trying to keep score, I believe that David Berlow is replying to several comments from this other thread:
There you'll find Nick's comments about alignment zones, John's quote of Si's "elephant in the room" comment, and there the "this site" that David is referring to is the lead topic.
I can totally understand how he might have conflated the two threads.
"And Firefox 3.5 has been out for less time than that, supporting naked font linking. If you could guarantee that the outcome of a longer process would be Mozilla support for EOT Lite and definitely not IE support for naked font linking, then I think font makers would be less of a rush to see something like .webfont or ZOT embraced as a single interoperable format."
This is a false choice, John. What is your approach guaranteeing? Nothing. None of us can guarantee any outcome at all on anything in these discussions. All you can do is approach things as smartly as you can.
Hakon Wium Lie would agree that the .fonts-from-the-moon proposal was fine with him as long as it moved the conversation past EOT. I don't say this to disrespect him, it's just in keeping with his previous statements on the subject and his own theatrical style. I can't help it if he goes about things as an actor playing a role, he just does.
Lie and, to a lessor extent, the guys from FireFox have made it clear they want to support linking to raw files and nothing more. What commitment have you gotten to make you think that's changed? Just because they'll kick around some alternatives with you in on online mailing list?
Look, if you're willing to punt this down the road an extra five years, what's the all-fired rush?
Whatever you feel you are, today, "working out" will be killed in the cradle. The nit-picking is already beginning in the .ZOT versus .webfonts proposal conversations.
Further, font-producers are not the only stakeholders here John.
Copyright is granted by the public, it's not a divine right.
You give a damn about protecting your fonts and I give a damn about being able to use them. I'll have my say, too, and so should the web development community at large.
Evaluation takes time.
I think you are also underestimating the amount of communication and influence that can be exerted behind the scenes by players to whom we are dwarfs.
That's just how I see it.
Hmmm. "Smells like Microsoft" sounds like a completely ridiculous reason to keep the experience of the internet for people world-wide significantly worse than it could be. Is that really what's going on?
Hmmm. “Smells like Microsoft” sounds like a completely ridiculous reason to keep the experience of the internet for people world-wide significantly worse than it could be. Is that really what’s going on?
I encourage everyone to read these *few words* and try to make your own conclusions.
I'm learning with Opera and Mozilla guys that being prolix and evasive is an art for few. Maybe in the next 5 or 10 years we'll get a conclusion in that panel.
“Smells like Microsoft” sounds like a completely ridiculous reason…
Not to anyone who followed the proceedings in the Microsoft antitrust trial. Lies and duplicity are hardly out of character for the great beast of Redmond. Not giving Microsoft an inch is a pretty smart move IMHO.
Richard: Lie and, to a lesser extent, the guys from FireFox have made it clear they want to support linking to raw files and nothing more. What commitment have you gotten to make you think that’s changed? Just because they’ll kick around some alternatives with you in on online mailing list?
No, I'm asking for a commitment in the form of a W3C working group. John Daggett from Mozilla has suggested an informal, ad hoc group to work out the details. I'm not satisfied with that, for the reasons you suggest. I want a formal W3C working group with a specific mandate.
In case I have not been clear: I think it is great that you are putting pressure on these browser makers, and if you can get more web authors and designers to do likewise, so much the better. Mozilla and Opera are being disingenuous about EOT Lite, and they deserve to be called on this, as you and Microsoft are doing. My name still isn't on the list of foundries supporting .webfont, and I still think EOT Lite is the stronger option. I'm also aware, though, that a great many of my colleagues support .webfont and would might be willing to support ZOT, and as one of the more vocal participants I feel an obligation to fairly represent that perspective.
A little while ago, you were urgently encouraging font makers to organise and negotiate collectively. To a large extent, this is what is now happening, and you're suddenly asking us what is the rush.
Urgent to choose representatives and a strategy, NOT urgent to start entertaining any notion anybody seems like they want to talk about. (I'm overstating, I know.) Glad to hear you are hanging tough on the Working Group. I don't know if that binds anybody to anything, but at least it's concrete.
Here's what I propose, along with my reasons:
The new EOT changed everything. I was taken totally by surprise when it first showed up. At first, I thought it was some kind of negotiating gimmick. (I really did.) It took me about a week to accept it as real and understand the ramifications.
It's huge. And Ascender and Monotype are already signed on. I assume Adobe will follow.
Organizing and lobbying collectively is the strongest way to go. A group of about three to four spokespeople - two main reps and one to two alternates who have credibility and respect.
Otherwise the entire font community will get chopped apart. The font guy who expects the least will always be held up as the poster child.
"Hey, it's OK with him", they'll say, "Why not you?"
Now, in fonts there's no central organization with legal authority along the lines of, say, the Writer's Guild.
But there is SOTA. There is AtypI. I think it's time for the top people at those organizations to get political.
If now isn't the time, when is?
There are membership lists aren't there? How long does it take to solicit nominations and take a final vote? A week? Two at the most. This is a highly special circumstance calling for special measures. While the final reps are being chosen, the presidents or boards of those organizations should, indeed, must appoint provisional reps.
(There's this thing called the Internet that can be most helpful with stuff like this. Crappy fonts, but for getting things done fast, it's the bees knees.)
A thread about the selection process - for questions and comments - should be started right here on Typophile.
Who's running SOTA right now? I know there's a changing of the guard taking place soon but I'm assuming the same folks from Atlanta are still in place. True? Not true? Tammy, Kent, are you there?
I know next to nothing about AtypI, who's running the show there?
John, so far, on the W3C mailing list, you've been the de facto industry representative. Except for Karsten, I think you've been the only professional font-producer talking. And I do give you credit for trying to take the bull by the horns. (And there has been a lot of bull, eh?)
But you can't, nor should you do it alone.
Obviously Tal and Erik have lobbied for their .webfont proposal which they feel strongly about and it's a serious proposal.
The problem is, EOT is working code on hundreds of millions of machines. Support for it would provide such profound benefits in such a short time that pushing it out front is a no brainer. Would Tal and Erik be willing to hold their fire for the greater good? (With the understanding that their proposal will be given the airing it is due once the status of the new EOT is decided?)
Don't know. I'm sure they'll make their views known.
I don't think the reps should be any of the "big dogs". Adobe, Monotype, MSFT, can speak for themselves.
As a member of SOTA, (full, not the cheapie student membership) I nominate you, John, to be one of the representatives. Provisional and permanent. You have a command of the technical issues, the verbal chops, and, obviously, the motivation.
Also, as a member of SOTA, I'm making a motion that no later than five days from now, all the recipients of the W3C Web Fonts mailing list, as well as any other concerned parties that may be identified, be formally notified of SOTA's intentions to present a group of representatives formally charged with representing the interests of SOTA's membership in dealings with browser makers and web-standards bodies.
Who seconds this?
(BTW - is there a place on SOTA's site for stuff like this, or should we just do a thread here?)
How does this sound to everybody? Anybody? Speak, please.
Richard, neither SoTA nor ATypI is an organisation representing professional font makers, and the fact that you, not a professional font maker, are able to become a full member of SoTA should make that fact obvious. These are organisations that put on conferences devoted to typographic design. It is not their mandate to represent font makers as you suggest, and I think you will find a lot of font makers objecting very strongly to your presumption.
These issues are being very actively discussed in the professional type design community. Large numbers of us are in daily contact, and I think the views of the community are being expressed. There isn't a uniform position, but there is a high level of understanding of the issues, and a responsiveness to the changing situation. A more formal representation is possible, and will likely happen in the case of a working group. What you might expect in that case is a list of font makers and vendors endorsing representatives and policies. The constitution of that list will be a better measure of the validity of the representation than the arbitrary membership of organisations such as SoTA and ATypI.
Rich, to answer your questions about SOTA: You can find info here. The board of directors is listed here. I think John's characterization is accurate, but the description on the SOTA site should tell you what you need to know.
ooops! Thanks Kent ;)
Dagget didn’t say no explicitly, but he’s trying to reject anything that smells like Microsoft (as someone said here), giving nonsense excuses without analyzing it.
Sorry if there's something I didn't explain with sufficient rigor. What exactly are you referring to?
This is not simply me trying to malign anything coming from Microsoft, I just don't see EOT-Lite as a very good proposal, mainly because it's taking an API from an existing product and using it to define the behavior for a standard. ZOT seems to me like it provides better obfuscation and is more efficient and the .webfont proposal makes the license details more evident to anyone poking around with the font file.
The advantage of EOT-Lite over new formats is that it gives some form of backwards compatibility with IE6, IE7 and IE8 which supported EOT-formatted TTF fonts, so authors would only need to use one version of a font to get some form of cross-browser support. No version of IE loads EOT-formatted CFF fonts, so this isn't really an advantage for CFF-only font vendors like Adobe or Hoefler & Frere-Jones.
In some sense it boils down to whether the advantages of having a better format outweigh the disadvantages of web authors having to support two font formats to fully support previous versions of IE (i.e. new format plus EOT).
> Now, in fonts there’s no central organization with legal authority along the lines of, say, the Writer’s Guild. But there is SOTA. There is AtypI. I think it’s time for the top people at those organizations to get political.
Rich -- I have heard your frequent call for some kind of single representative voice for the type "industry." And I don't necessarily disagree with the sentiments, instincts, or passion behind this call.
With all due respect, however: in directing your call toward SOTA, I'm afraid you've misunderstood the nature of the organization. As has been previously stated, SOTA is not, and does not purport to be, representative of the "industry."
I can understand why, because of recent visibility of SOTA and its annual conference, one might look to this organization as a potential for collective representation, but I don't think it's a proper fit.
The SOTA board, which you can see at Christopher's link above, is currently composed of 12 part-time volunteers, seven of whom are basically self-employed individuals. Two are full-time educators. And three members happen to work for larger font-related companies (but none are on the board as representatives of these corporations). By my reckoning, only five members are published type designers (three of whom are ending their terms next month).
The membership of SOTA is essentially a club, not a professional organization. I think "Typographic Aficionados" says it all. The current membership numbers 38 non-student members. Of those, as near as I can tell, about 17 are type designers or otherwise directly involved in the font development business (and this number includes the board members cited above).
Speaking purely personally, I do not think SOTA is a position -- organizationally, constitutionally, or resource-wise -- to become a political voice for the industry. I think SOTA can and should campaign for and provide opportunities for public and community awareness. But I don't think that political representation or advocacy fall within its purview.
While SOTA enjoys good, close relations with, and widespread support from, much of the professional type community, I doubt any majority of that professional community would be willing to grant SOTA any political authority to advocate on its behalf.
To be clear: these are my personal views. I am not speaking for SOTA, and I am one of those whose board term is ending.
Without having as yet read any of the posts subsequent to my last suggestion, I have been advised by email that what I am suggesting will not bear fruit.
I am taking that advice. I tossed out an idea - a possible way of approaching the problem. Even if the consensus is that it's a dumb idea, I hope that it at least provides food for thought because the problem still remains.
I will continue to be a booster for the new EOT because it promises the most in the shortest amount of time.
Every profession has it's own internal dynamics, and not being a font-producer myself (although you never know!), I do not presume to tell anybody how to run their professional lives.
Rich -- On a more constructive note: I do think that the ATypI is potentially a more fertile ground for your call to take root -- especially given their history and roots as a much more trade-oriented professional organization.
You can read about their purpose here: http://www.atypi.org/05_About_us
And you can also download a PDF of their current governing statutes, where I direct your attention to Article 2, (a)-(d). You'll also find that their membership is an actual voting body.
I think ATypI is more constitutionally disposed to the kind of unified, "industry" advocacy that you urge. Although, I suppose that they may face similar organizational and resource challenges.
I believe that Tom Phinney and Si Daniels are the two ATypI board members who participate on Typophile most frequently.
I understand that ZOT can be even more sofisticated and I apreciate Erik and Tal's efforts on the .webfont proposal. IMO, all that proposals look good for type designers/vendors. But tell me, what is the big deal in supporting multiple formats in the next FF versions? I mean, multiple formats was never a problem on www. You din't have any problem in supporting naked font linking on FF3.5 without any protection (and sorry, the type comunity did'nt like that idea). Supporting EOT Lite AND ZOT can be a way to let foundries, web designers and authors chose what is the best for them.
Kent, I don't think ATypI is any more representative of font makers than SoTA, despite its origins as an industrial cartel and its impressive looking statutes. Like SoTA, ATypI has an open membership policy, which means than anyone interested in type is permitted and encouraged to join the association: type designers, font makers and font vendors, yes, but also graphic designers, teachers, students, afficionados, etc. As a basic rule of thumb, I'd say that an association cannot claim to represent a profession if its voting membership contains both members of that profession and their customers. It would be like saying that an association open to everyone who has teeth represents the dental profession.
John Daggett: No version of IE loads EOT-formatted CFF fonts, so this isn’t really an advantage for CFF-only font vendors like Adobe or Hoefler & Frere-Jones.
Its not clear yet what Microsoft intend to do with regard to implementation problems that they have described as 'bugs'. Knowing how MS tracks and addresses bugs, a hotfix is always an option for a critical bug. Of course, what makes a bug critical is the user base and the potential impact -- both the negative impact of the bug and the positive impact of fixing it -- and this means that a bug that wasn't critical for the past ten years might suddenly become critical today.
Personally, if I were MS, I would be doing everything possible to undermine your rejection of an EOT-derived solution, including hotfixing IE back to version 6.
A little over a week ago, I expressed to Ascender what I thought they would need to do to get other font makers to support and license fonts for EOT Lite . Our concerns about EOT -- beyond the weakness of the protections it offered, which we now realise were stronger than anything else we're going to get the non-IE browsers to agree to -- were mainly around poor tool support and the awkwardness of building .eot generation into our existing mastering and delivery workflows. Tal and Erik's .webfont format was specifically designed to avoid such problems, which is one of the reasons why it was so enthusiastically supported by font makers. As I told Ascender, if they wanted font makers to sign up to EOT Lite, they would need to address the tool issue in a way that makes .eot creation as easy for foundries as .webfont creation. Less than a week later, I'm beta testing that tool, so I think the will to make EOT Lite a serious contender is definitely there.
I'd agree with that, but obviously the analysis changes if EOT Lite becomes better. Which is why it is in Microsoft's interest to hotfix their bugs.
This is not simply me trying to malign anything coming from Microsoft, I just don’t see EOT-Lite as a very good proposal, mainly because it’s taking an API from an existing product and using it to define the behavior for a standard. [ ... ]
The advantage of EOT-Lite over new formats is that it gives some form of backwards compatibility with IE6, IE7 and IE8 which supported EOT-formatted TTF fonts, so authors would only need to use one version of a font to get some form of cross-browser support. No version of IE loads EOT-formatted CFF fonts, so this isn’t really an advantage for CFF-only font vendors like Adobe or Hoefler & Frere-Jones.
John, you're leaving out a big advantage of EOT Lite: It's already out there. I realize it was Ascender's gambit all along to push it out into the world as aggressively as they have, but it's there, nevertheless.
To describe is as "taking an API from an existing product and using it to define the behavior for a standard" might be a well-intentioned description on your part, but it seems contrived from my POV. We're talking about a fairly simple and open font wrapper. It's easily understood, anyone can create them, and it contains enough protection to satisfy most foundries (I think). I am just not getting why you see it as such a completely different animal from webfont or ZOT.
There are potential problems with it working with CFF, but Microsoft has motivation to address them. Obviously we're looking at that very carefully.
My point is not to tell you that we should end the debate right here and pick EOT Lite... I'm just not convinced by your (and others') reasons for taking it off the table so quickly. It still looks like a reasonable contender to me.
@ John Hudson
Maybe it is time to see wich are the foundries/vendors/distributors are supporting the EOT Lite proposal.
I can see already annouced on the web  :
Bigelow & Holmes
Tour De Force
Am I missing anyone?
We should notice that the .webfont proposal (by Erik and Tal) are also supported by very respected foundries around the globe and, despite the passions involved, I still think that it's not an either/or situation. Multiple solutions can live in peace together, bacause most of the type designers/vendors interests are not so different, I think. All of us want to find a way to protect our font IDs, so we can still provide high quality products, feed our families and pay our bills. ;)
"No version of IE loads EOT-formatted CFF fonts, so this isn’t really an advantage for CFF-only font vendors like Adobe or Hoefler & Frere-Jones."
Just to key in on this part of your post:
First, the statement is incorrect. The set of fonts that Adobe markets for web use, Web Fonts Pack are TTF. (A bargain at $69.99! Although I can't, today, post them on a web server in raw form.) In other words, Adobe seems quite willing to adapt it's product line to the realities of the market. To characterize any font-producer as "CFF-only", as if they are hand-cuffed and would not fall all over themselves to offer TTF or EOT versions of their fonts should a demand develop, is preposterous. OTF's are being converted to TTF's and EOT's for use on the web as I write. You know this.
Second, in what way, shape, or form is this an appopriate or even a wise criteria upon which to decide whether to support one file format or another? Browsers are conduits - everyone using that conduit must adapt to it, or back away.
Because of FireFox and Safari's raw-only support for font-linking, the problem we have today is that vendors ARE backing away.
And I must say, this is exactly the kind of argument I spoke of in my previous post. Now, Adobe and H&FJ are being held up as the "poster children" whose interests you are out to protect. If you were to ask them, I'm sure they'd say their interests would be best protected by FireFox immediately issuing a patch that 1) disables raw font linking 2) enables EOT.
How about that? Is that going to happen?
If "support" is defined as something like "agree with the spirit of the proposal; examining with careful consideration," you can add Adobe.
(I think that is more or less what the "support" list for webfont means.)
BTW - thanks for posting your views here, in the lion's den, so to speak. Hah!
I think it's greatly appreciated by all.
Yes, Christopher. That's what I thought when I said support :)
Maybe we can chance the ambiguous word "support" by "agree with the spirit of the proposal", so...
Foundries/vendors/distributors that seems to agree with the spirit of the EOT Lite proposal:
Bigelow & Holmes
Tour De Force
During the web fonts panel at TypeCon, Ivo from FontShop indicated that they would license for EOT Lite as well as for .webfont, so that might indicate that they ‘agree with the spirit of the proposal’, but I would not presume that and you may wish to contact them before adding them to any lists.
>mainly because it’s taking an API from an existing product and using it to define the behavior for a standard.
Why is this a problem? What harm or damage results? I don't know what went on in the early browser wars between Netscape and Internet Explorer, but I don't think Microsoft ever had any problems with adopting good ideas from others, to say the least. Here if a kernel of EOT--now modified--is a quick and satisfactory way to get fonts on the web, why not support it? Going forward, the code is not going to be proprietary to any company, I gather, so what's the issue?
Also a factor you don't discuss, is the speed at which all this can happen. This is important both to benefit internet users, and for the font business. I don't know the technical issues, but if a satisfactory solution can be implemented in a year, and a slightly better one will take five years, I think there's a good argument for going for the quick and satisfactory solution, and then upgrading it over the years.
Also if alternatives are compatible, then other better solutions can be implemented later.
Why not get this done now, if it can be done satisfactorily, and work on improvements and alternatives later?
jdaggett -- No version of IE loads EOT-formatted CFF fonts, so this isn’t really an advantage for CFF-only font vendors like Adobe or Hoefler & Frere-Jones.
Not that I am a friend of EOT (Lite) but: The fact that IE doesn't support CFF-OT-based EOTs is less of a problem than is the ugly rendering of CFF-OT fonts on the Windows platform, see this discussion and this earlier one. In some cases the result is hardly legible at the crucial sizes -- text sizes. And this is not a question of font quality since high-quality fonts are affected too. Possibly it is not even "recommended" to serve CFF-OT fonts for web use, no matter which web font format will win the race.
but I would not presume that and you may wish to contact them before adding them to any lists
I would not add them to any list before it's clearly announced/expressed for themselves on the web.
Please note that I'm not trying to make any “official list of supporters”. I would not have any authority or even intention to do that. I only believe that pointing the parts interested in the EOT Lite proposal (more than the quantity of them) could help to analyze the current state of the discussion (always moving ahead).
Do you think it is a good idea?
"Also a factor you don’t discuss, is the speed at which all this can happen. This is important both to benefit internet users, and for the font business. I don’t know the technical issues, but if a satisfactory solution can be implemented in a year, and a slightly better one will take five years, I think there’s a good argument for going for the quick and satisfactory solution, and then upgrading it over the years."
What you are saying is plain old common sense. But common sense hasn't cut it in this debate so far. Workin' on it, though.
To be clear: the benefits of the new EOT lite are not hypothetical.
Cross-browser implementation of EOT lite will do two things:
1) It brings web fonts, as a reliable technique, roughly 5 years faster than a newly drafted specification. If time is a consideration, as I agree with you it should be, hundreds of millions of Internet users will benefit 5 years sooner.
2) It also, at the same time, and as the growing list of font-producers who will license for the new EOT suggests, solve the licensing problems that have so far denied web designers the use of retail fonts.
Technically, support for EOT lite means having the browser treat a file with an .EOT extension as if it had a .TTF extension. There is little else to it of any technical consequence. In fact, those browser makers who have so far withheld their support, concede this.
I know you have a deep academic, research-oriented background. (We met in passing at TypeCon in the informal discussions after the panel on reading research. I was the guy with Wet Macular Degeneration, if you recall.)
Interestingly, Bert Bos, who was the co-creator of Cascading Style Sheets along with the fellow who is now EOT lite's most arch opponent, Opera CTO Håkon Wium Lie, agrees strongly with your "build on what exists" philosophy.
Some years ago he wrote a paper about what constitutes a sound approach to drafting standards and the section entitled Use What Exists lines up firmly in favor of what you suggest.
Bert is still at the World Wide Web Consortium and still weighs in occasionally on various things on the Web Fonts mailing list.
Richard, of course I remember meeting you, and from your welcome presence here on Typophile. I am glad to here that one of the movers on these issues is bringing a perspective of the process that is best for progress. That might help break the logjam.
(I have to remember that word for kerning!)
Which is precisely my point, MS could just as easily ship a hotfix to support a non-EOT format in IE versions back to IE6, the code to do this is no more or less complex. Personally, I hope they ship hotfixes to fix CFF support because it holds all browsers back on Windows, not just IE.
All the "protection mechanisms" that have been proposed center on origin-restriction when linking and the obfuscation of font data. EOT-Lite effectively allows cross-site linking in current versions of IE because it doesn't enforce same-origin restrictions and an EOT font with a null root string can be linked to from anywhere. Would it be better for MS to implement a same-origin restriction on fonts with a new format?
John, you seem to want to always put things in terms of a grand war between Microsoft and the evil forces of direct font linking. If it's really a war than like all wars we all lose in one sense.
Direct linking of TTF/OTF came about because it made linking to fonts easy, plain and simple. There will always be situations where direct linking to fonts is simpler and easier for authors, situations where the fonts are not intended to be restricted use or situations where the font designers are simply willing to use the legal system to enforce their copyrights instead of requiring garden fences built into the font file format. Direct linking to TTF/OTF fonts does not mean those fonts can't be lightly obfuscated, for example by changing the contents of the name table to produce a font that's effectively unusable as a desktop font but is still completely valid and works as a web font. The Typekit and Typotheque services illustrate this point. Protection does not require a file-based obfuscated format.
Sure, point taken, Adobe does sell some TTF fonts. But they are a predominantly CFF font shop, as are other font vendors. Switching to a TTF tool chain is not as simple as you imply. Adobe stated this clearly in response to a similar
remark you made on the www-font mailing list.
As to your second point, all I'm saying is that EOT-Lite does not guarantee backwards compatibility in IE for CFF fonts. Pooh-pooh the point if you like but for some font vendors I would imagine that's an important consideration.
Note: Firefox is not written FireFox.
In this case EOT is a documented format  but not a documented set of behaviors, separating how it works in IE now vs. how it should work in other browsers is not as simple as others imply. Should non-IE implementations just view the EOT as a header of padding bytes prepended to the font data and simply load the font data? Or do those fields, some of which are based on data in the font and some of which are not, affect usage? Are there implications of that defined behavior? For example, the original EOT submission blurred the meaning of the OpenType embedding bits to imply behavior within the browser (i.e. with Print/Preview set the user agent must not allow editing with a font). That sounds minor but a little thing like that has big implications for implementations, since browsers don't typically implement "fallback when font is readonly". Since my guess is the closest thing to a real spec is the source code of the t2embed library, figuring these things out takes time which in a way negates the "get it done now" aspect of EOT-Lite.
In many ways the first Ascender proposal was better, to simply obfuscate table tags. It's simple to understand what the proposal is and what needs to be done to implement it. EOT-Lite is a trickier thing to define.
I think any of these proposals could be in shipping implementations in less than a year.
It's not a big deal to support multiple formats but not ones that aren't well-defined, like EOT-Lite. Up until now the idea under discussion was to have one format that all browsers implemented. That's easier to standardize than two formats, one now, one later. And supporting a single format is less work for font vendors.
Cross-browser implementation of EOT lite will do two things:
1) It brings web fonts, as a reliable technique, roughly 5 years faster than a newly drafted specification. If time is a consideration, as I agree with you it should be, hundreds of millions of Internet users will benefit 5 years sooner.
Just curious why five years? Non-IE browsers are on 1-year replacement cycles, and IE8 is replacing IE7 at a similar rate. IE6 is it's own, oh so very, very special case.
It’s not a big deal to support multiple formats but not ones that aren’t well-defined, like EOT-Lite. Up until now the idea under discussion was to have one format that all browsers implemented. That’s easier to standardize than two formats, one now, one later. And supporting a single format is less work for font vendors.
Well, thank you for answering and I hope that soon you can solve all your questions with the proposers of the new format.
BTW, I tried to organize a list of font vendors that seem to agree with the spirit of the EOT Lite format, as described by Ascender. Most of them declared to be analyzing the technical issues involved: http://outrasfontes.tumblr.com/post/150248691/eot-lite-list
I am encouraged that you don't see this on your part as an "us vs them" issue, and also that you think that any of these solutions can be implemented in a year.
As I said, I don't understand the technical issues, but I am getting the feeling that the problem is really getting the leading browsers, especially you at Mozilla Firefox and Microsoft Internet Explorer to agree on a technical solution that provides a similar "garden fence," as you put well, it for web fonts.
I am guessing that most digital foundries will be content with any fence that provides a clear barrier and warning for the honest, even if it, like garden fences, is easy to breach. That's for the reason, as I wrote earlier, that only public use will be enforced by digital foundries. But if a foundry wants more protection or a site designer wants greater ease of use I guess the services like Typekit and Kernest will be there in any case.
I just think that the sooner some kind of garden fence is agreed on, the sooner digital foundries can write their EULAs, and they will have a sigh of relief, and the web will start looking a lot better and more diverse as far as typography.
So now I'm thinking the main issue is not, what garden fence is best, but what can you and Microsoft agree on, as you two dominate the market. I hope you all can resolve this soon.
John Daggett: Which is precisely my point, MS could just as easily ship a hotfix to support a non-EOT format in IE versions back to IE6
That wouldn't be a hotfix, it would be retroactive addition of a new feature. Non-support for a non-EOT format in the older browser versions is not a bug. There are genuine bugs, and these should be fixed. But as Sylvain has pointed out on the W3C list, this is Microsoft's problem not anyone else's.
If you move quickly, Firefox can have better .eot support than Internet Explorer. :)
How is adding support for EOT-formatted CFF fonts not adding a new feature? Hotfixes are typically gated on risk, not on a definition of "feature". Adding support for a simpler font format is far lower risk than adding support for CFF.
These are indeed Microsoft's problems but the argument is being made that EOT-Lite is better because other formats can't be supported for "years".
John Daggett: Direct linking of TTF/OTF came about because it made linking to fonts easy, plain and simple. There will always be situations where direct linking to fonts is simpler and easier for authors, situations where the fonts are not intended to be restricted use or situations where the font designers are simply willing to use the legal system to enforce their copyrights instead of requiring garden fences built into the font file format. Direct linking to TTF/OTF fonts does not mean those fonts can’t be lightly obfuscated, for example by changing the contents of the name table to produce a font that’s effectively unusable as a desktop font but is still completely valid and works as a web font. The Typekit and Typotheque services illustrate this point. Protection does not require a file-based obfuscated format.
1) As has been explained many times, one of the problems that font makers and vendors have with naked font linking is that it exposes all existing fonts to casual misuse in an environment in which the majority of users are unaware of the origins of the fonts on their systems, unaware that these fonts are licenses, and unaware of the terms of those licenses. The desire for a distinct web font format is to make a clear distinction, anticipating the web as the major typographic medium for the future, between what we now think of a ‘desktop fonts’ but which we may eventually think of as ‘legacy fonts’, and a new packaging of font data in which licensing, serialisation, customer linked data, etc. are consistently present and available to both the customer and the foundry.
I know a lot about fonts, but I couldn't tell you off hand which of the fonts currently on my system might be legitimately uploaded to a web server under current licenses and which might not. It would take me a lot of time to find this out, and that despite the fact that, unlike most users, I know where to look or who to ask.
I consider this distinction between existing fonts and new web fonts to be of general benefit -- it makes even free licenses more obvious to the user than they are now -- especially when combined with other proposed features of web fonts such as format compression. [For the reasons already discussed on the W3C list, server-side compression is not sufficiently implemented or implementable by all web authors; by the same token, the lack of compression in EOT Lite should be one of your arguments against the format, although we know how to solve that: accept the Monotype offer to release the MTX compression under a suitable free license.] Yes, naked font linking is easy, plain and simple, and this is why it makes casual misuse of existing fonts easy, plain and simple.
2) Server-side obfuscation such as Typekit practices, like server-side compression, is not a sufficient answer, since it relies on third party services to implement. Format obfuscation provides a minimal level of protection against casual misuse that the majority of font makers can accept. This means that we can have a single interoperable format that is a suitable baseline for all manner of font licenses, rather than multiple formats that might be suitable to some licenses but not to others; additional server-side protections can be offered on top of this basic format obfuscation.