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

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.

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.

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

(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.)

Thanks, Karsten--one more issue :-)

ChrisL

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

Okay, found it: http://www.w3.org/Submission/EOT/

Thanks, Kent!

ChrisL

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

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!).

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.

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!

"and one other thing."

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

ChrisL

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.

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

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/

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.

Can anyone provide a link to the ZOT proposal?

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.

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.

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.

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

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

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!

> 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

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

_Nick Shinn, Shinntype.

Thanks Nick! Sorry I missed that.

Also Christopher Fynn has expressed his support.

Bill

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

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

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

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

"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?

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

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

>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!

>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!

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

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.

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

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

Cheers,
Rob

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!

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.

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

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.

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.

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?

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.

Sorry, I misunderstood you.

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!

Nick> The lesson of DTP is that despite the ease of font copying [...]
True...

>...and the lack of punishment for transgression,
False...Some bodies have paid aplenty — Nobodies rarely get caught, big deal.

>Please explain how that was possible, and why would things be different for web fonts,

Well why not... if 99.9% of all DTP prepress clients suddenly wanted only a single sheet, full color, four fold, brochure, overnight for free... wouldn't that change the DTP four-fold brochure prepress industry? The market for pre-press print and web publishing are totally different dynamics, inhabitants and habits, except that they overlap in some tiny proportion, and they all want words. Don't be confused by the fact that fonts have word-making capabilities, or that some people use them casually on the web and in print.

More globally, the triangle of legal, technical and design issues forming this bermudaization are very very different, print to web.

>or go stand in the corner.

Part of what we must do, is make up for the past of format neglect and pathetic hacking at it. Part of what we must do is look into the future and 'help', It's a bigger problem than we should need to solve, alone, because it's taken so long for all the others to get their ducks in line. Sorry for them, is not sorry for us.

Cheers!

@outrasfontes

Do you have the capability of testing in IE6? And IE7?
I haven't had a chance yet, but there's been some questions raised as to the reliability of EOTL in those versions. I don't know if it's the CSS syntax or what.
If you see anything amiss in IE6 or 7, please post!
Thanks.
Richard Fink

David, I represent me, and I also try to represent fairly and accurately what other people have said to me. So when the great majority of font makers are a) refusing to license for naked font linking and b) vocally supporting distinctive web font formats, I think that should be acknowledged and I'm not about to suggest that all those people are idiots who just don't get it or are being ‘ponded’ into a solution, i.e. that they can't figure this out for themselves.

Nobodies we’d never get a license fee from.

So that makes it okay for them to take your fonts for free? Come on, David, you know the value of typefaces and you know how much of that value resides in either absolute or relative exclusivity. Are your customers going to want to invest in fonts that every ‘nobody’ on the planet might be using on his website? Protecting the customer's investment is job one if we want them to continue spending money on font licenses and commissions.

And as you can see, the demonization of EPAR has begun!

I don't intend to demonise the EPAR table idea. But when you say things like

A lot that was impossible, becomes possible with EPAR

I'm still left asking What? What?

Maybe you should hire someone to explain this to the rest of us, ’cause you’re doing a lousy job. So far, all you've done is convince me that you think you're right and everyone else is wrong, but I still don't what you think EPAR makes possible and how it makes it possible.

Really the question here is not whether I can explain something, but rather, whether one should support the EOTL format without industry developed meta-data included.

Berlow Said: A new web font wrapper will not protect web fonts beyond a week or two after publication.

Hudson said: It will protect them from casual misuse like OpenType fonts will not.

Berlow asked: Define casual misuse.

Hudson defined: Casual misuse is when someone places an OT font on a server, sends an OT font to another user, or links to an OT font on someone else's server.

Berlow said: This is exactly what will happen to any font format for the web. People who do this, are not concerned with IP issues, and are not likely licensees.

Hudson said: So that makes it okay for them to take your fonts for free?

Berlow Asks: Free possession will not be possible with a new web font wrapper?

I'm sorry John wants to ask something so circular in the course of honest dialog.

Some of us long ago supposed each foundry could have it's own wrapper and un-wrapper each day to protect just against everything. But if a stupid idea is no good 365 times a year it's smart just once then?;)

Hudson says: Maybe you should hire someone to explain this to the rest of us, ’cause you’re doing a lousy job.

Berlow Asks Politely: Will your definition of casual misuse be prevented by a new wrapper, by EOT or any other likely action no win discussion?

Hudson also Asks: I’m still left asking What? What?

Berlow says: There is no point in you going further without Your answer to the question above.

Will John's definition of casual misuse be prevented by a new wrapper? Or will Rocky meet the Squirrel of his dreams?

Stay Tuned!

None of the web font format proposals do much for casual misuse from one web site to another. This is not for lack of interest by type designers and font vendors, but because the browser makers are simply unwilling to accept anything that does much in that regard.

However, all of these proposals do have some degree of format barrier (garden fence) against casual misuse from as desktop fonts. This is the existing revenue stream that font makers are most worried about losing/threatening/whatever.

I'm not necessarily against David Berlow's EPAR table, but I do agree with John that it seems compatible with any other proposal that maintains the existing tables in a font, including WebOTF, EOTL, naked fonts, and just about anything else. However, if David wants to specify that he is really proposing not just "add an EPAR table" but "only naked fonts with an EPAR table," and explain why having an EPAR table inside a dedicated web font format is a Bad Idea, I'm all ears.

Regards,

T

@ Richard Fink

I did not have any problem with IE7 and IE8, but I didn't test it in IE6 yet.

First off, let me say that I think EOTL sucks and the only reason it is likely to become at least an intermediary interoperable web font format is that it enables foundries who do not want to license for naked font linking, i.e. almost all of them, to immediately start licensing TTF-derived web fonts that will work right now in the majority of browsers in use (IE) and can work tomorrow morning in Firefox etc. as John Daggett has demonstrated with his test code. Part of me wishes EOTL would suck more than it does, so that we could ignore it and concentrate on a better format like .webOTF. But I think we're going to be stuck with EOTL, so the question becomes how to make the most of it.

Really the question here is not whether I can explain something, but rather, whether one should support the EOTL format without industry developed meta-data included.

I've never suggested that that EOTL should be supported without such meta-data, and in all my discussions I have presumed that foundries will be adding such meta-data, either in a standardised table if we can agree on that or in private tables. I do know that things like the EEULAA have been under discussion for at least two years, your EPAR table is currently only an outline of what a table might contain not a technical spec, there is already disagreement in feedback from other foundries about whether all this belongs in a single table or in multiple tables (separate tables for licensing/permissions and for recommendations), standardisation in the OT/OFF spec will take time, and still we're missing the explanation of who is expected to make use of this metadata and how.

I understand some of the things that EPAR makes possible in theory, but I'm wondering how you see it working in practical terms. What are the usage scenarios, if this isn't just a bunch of bytes that everyone ignores? [And I don't ask that because I'm trying to 'demonise' the EPAR table, but because I've seen just how keen the browser makers are to ignore anything that implies they have to do something other than or in addition to displaying the linked font. Not to mention the 'libre' font zealots who want to ignore even the rootstrings in existing EOT fonts.]

Re. casual misuse, it's as Thomas says: a distinct format draws a line between fonts used on desktops and fonts used on the web such that a font licensed for use in one environment won't be casually used in the other environment. As I wrote above, the primary concern expressed by multiple font makers is casual misuse of existing desktop fonts on the web, contrary to existing licenses; other forms of casual misuse, including downloading and use of those fonts on the desktop, extend from that first misuse. The question is not, as you suggest, whether parallel kinds of misuse will also apply to EOTL or another web font format, but whether this particular kind of casual misuse of existing fonts can be to some degree prevented, such that the market for web font licensing is viable and font makers trying to sell such licenses are not competing against misuse of their own existing desktop fonts. I believe a format distinction can significantly affect this scenario, and apparently so do most of our colleagues.

I wrote: casual misuse from as desktop fonts

Hmmm. Something got lost in my editing prior to posting. Should have read something like "casual misuse of web fonts as desktop fonts."

Regards,

T

To be honest, I'm tired of the "a web font format won't protect anything" meme.

If we want to discourage the use of web fonts on the desktop, there is significance in creating a separate file type. The protection is twofold: First, the user has to confront the problem of "getting the font to work" on their desktop. This will not guarantee that they understand that they are violating a license, but it increases the likelihood of publicity and awareness of font licensing. (They Google it to find out why it's not working, and find out why.) Second, it's a legal tool, which gives lawyers (in the unlikely event the case goes to court) evidence of a deliberate act. The mere awareness that such an act would make a legal case more convincing in court is a deterrent for some.

Think about the copy protection on most DVDs. With a bit of knowhow, a user can work around it. But the very existence of that copy protection (which, btw, to most people first translates to "this isn't working when I try to copy it" as opposed to "I am not allowed to copy it") subsequently creates awareness of the licensing. If DVDs were easy to copy, I think there would be many more duplicates floating around by now.

So, to summarize, a web font format creates an opportunity for license awareness, and a "trail of evidence" threat to possible violators. I don't want to overstate the degree to which this helps, but I think it's non-trivial.

There's plenty of other features which would offer more, and better, protection. URL binding would be nice (but we won't get that). Same-origin checking would be nice (if it could be relied-upon consistently). License info metadata would be nice (and at least is relatively easy to imagine).

@outrafontes
Thanks for your input re IE7 and IE8. I've been pulled away with some family health emergencies and can't devote any time to testing for another 5 days or so. If you have any pages posted publicly, please post links - visiting them in IE6 would be an easy matter.

@christopherslye

The "level of safety" that type designers are going to get with web fonts is pretty well-settled at this point, right? So, to move on to the question that concerns people like me: does EOTL and .webOTF free things up? Are type designers ready to move on to the next phase?
(Partly rhetorical, yes. It's August. But soon decisions have to be made. New EULAs drafted, etc.)

...and MUCH more hinting to be done.

ChrisL

@dezcom

Hey, at least *somebody* gets it! Congrats, you win first prize.
In fairness, display manufacturers and rasterization software makers have much to do, too.
Like I said, it's August. But by October we should have it all straightened out.
(The only question is October of what year.)

Regards,

rich

> License info metadata would be nice (and at least is relatively easy to imagine).

Christopher, do you feel that EOT Lite offers more in this regard than WebOTF?

TP> None of the web font format proposals do much for casual misuse
JH> First off, let me say that I think EOTL sucks

Well... you each started well.

But--->

> a distinct format draws a line between fonts used on desktops and fonts used on the web. . .

point2 - OpenType is not going away, as a DeskTop format. It is not being replaced as a Web format. OpenType is what web fonts are today, working right now in a majority of browsers in use...

(...and can work tomorrow morning in IE.)

Please draw real line between two things, not talk line through two things.

point3 - new format does not prevent casual misuse. Users will do everything with new format they did with OpenType. In most cases, OT web font users will not even know the difference, simply pointing to OT fonts on disk and never seeing resulting .web font files.

('Slightly' less 'casual' users, will need to move result to own server.)

point1 We need to put meta data in existing open and published font format.

We can't all hold three points in head and draw useful line through them?

I make you big list.

CS>To be honest, I’m tired of the “a web font format won’t protect anything” meme

That is not a meme.

Cheers!

David: OpenType is what web fonts are today, working right now in a majority of browsers in use... (...and can work tomorrow morning in IE.)

This simply isn't true. The majority of browsers in use are IE (approx. 62%, a market share that is falling but will probably remain above 50% for at least another couple of years). In case you missed the memo, Microsoft's rejection of naked font linking in IE appears to be a high level policy decision, i.e. it isn't something that an IE group engineer is just going to reverse. And even if MS were to change their mind about this, IE's version cycle rate is long (approx. 18 months) and its market penetration for new versions is even longer. IE can't do anything by ‘tomorrow morning’, but Firefox have demonstrated that they can (or, at least, sometime next week). [And let's be clear that in terms of market share IE and Firefox are the only two browsers that count. Everything else is a niche product.]

The simple, ugly fact is that EOT is the only web font format supported in the majority of browsers in use, which is precisely why an EOT-derived format looks unavoidable. You should also note that the people pushing most vociferously for EOTL on the W3C list are neither font makers nor browser makers: they're people who make websites. They understand that EOTL is the only option on the table that is already supported in the majority of browsers, is the the only option that doesn't require waiting >18 months for a new IE version, and is the only option that offers a fast route to interoperability.

So I reject your point2 as invalid. Your point3 is debatable, probably endlessly: you think Chris, Thomas and I are wrong (along with most of your other colleagues) and we think you are wrong. But the fact that your point2 is incorrect makes point3 moot. There's going to be a distinct web font format, and I don't see any grounds to think that there won't be. Firefox are busy testing code for both EOTL and .webOTF; they co-developed the proposal for the latter; Microsoft are agreeable to both; font makers have indicated that they are willing to license for one or the other or both. Meanwhile, MS has said no to naked font linking in no uncertain terms, font makers have said they will not license for it, and it is dead-in-the-water as an interoperable format.

point1 We need to put meta data in existing open and published font format.

Quite probably. But I'm still waiting for your explanation of how this helps, in practical terms, of what kind of scenarios you envision in which this data is used.

There's no point in trying to draw a useful line through three points if one of those points is factually incorrect and another is open to reasonable disagreement. But one only needs two points to make a line, so why don't we consider the two realistic points:

a) There is going to be a distinct web font format

b) There is meta data that needs to travel in or with a font

OpenType is what web fonts are today,

However, a two-format appeals to me as a font manufacturer because I will be able to produce and market two kinds of OpenType font: one (.otf) for print and online display in bitmapped gif/png/jpeg files, that will be feature rich--and another (.eotl) that will have fewer features but more nuanced screen hinting.

Also, the licensing would be different, prohibiting using the .otf format online, or adapting web-format fonts from the .otf fonts.

Having different file format suffixes is a good way to signal the different capabilites and licensing requirements.

Sure, OpenType features such as small caps and figure alternates are web-viable, but I don't believe there's a market for that yet.

Christopher, do you feel that EOT Lite offers more in this regard than WebOTF?

No, I do not. In fact, WebOTF is attractive because it has made a very clear allowance for it by design. But I should add that I'm still digesting the proposals, and there's no particular Adobe position on it yet. So for me personally, license metadata is attractive in a conceptual way, but that's very different than however Adobe decides it wants to use it, officially.

That is not a meme.

For some it is. Maybe not for you. I can appreciate anyone who wants to discuss it with intellectual honesty, but there seems to be a tendency for some to toss it out as an ideological matter.

Thanks, Christopher.

Bill Davis wrote above that Adobe has "come out in support of EOT Lite." In light of your comment here,

> But I should add that I’m still digesting the proposals, and there’s no particular Adobe position on it yet.

do you think you could clarify what "support" means? If it means that Adobe supports the discussion, which is what I inferred from your post at the top of this thread (#3), would it be fair to say that Adobe also supports webOTF?

If it means that Adobe supports the discussion ... would it be fair to say that Adobe also supports webOTF?

Yes, particularly since it is something that is a maturation of preceding proposals. As you would probably guess, there is a pretty substantial leap between concepts and models that Adobe supports (by discussion) and business decisions it makes. This is not to say they're unrelated, but that there are a lot of meetings and tests which precede the latter. :)

Hmmm. Thanks for the excellent input guys!

To revise: point2 - OpenType is not going away, as a DeskTop format. It is not being replaced as a Web format or by a Web format. OpenType is what web fonts are all deriving from now, and most likely for a generation, for all browsers.

To not revise point3 - a new web format will not prevent casual misuse. Users will do everything with the new format they did with OpenType. In most cases, OT web font users will not even know the difference, simply pointing to OT fonts on disk and never seeing resulting .web font files.

John, you have been drawing an imaginary line with words, "simply a new format will protect". I say you are wrong, and am drawing the line in the OT font ahead of this nonsense. I have been on the right side, at the right time, for the format changes from Paper to Bitmap to Ikarus to PostScript to TrueType to OpenType. I have never been so accountable.

Because founders were not given a choice between these EOT, and whether to just add metadata to OT, and license that, they now are faced with two bad choices, (or one excellent good non-choice). Why? Because MS doesn't support their own format, and when it was 'our turn" to add to that format, well it wasn't our turn. So long and thanks for the petite caps?

And maybe because John says (to people who don't know better), things like ;
"What we're looking for is a format that is interoperable in terms of widespread browser support [good] and suitability to various kinds of licensing, rather than suitability only to free licensing [bad boy]."

CS reprise>To be honest, I’m tired of the “a web font format won’t protect anything” meme.

But Chris, that is why we are here. MS 'said' "Our OT format is Raw, as a web font format, won’t protect anything and is not improvable by us, or anyone else." (although I will never get the memo). And John says OT as a web font is Naked, suited only to free licensing. ;)

So once again I am doing the 'right thing'. Because there is an us in users, we are putting meta data in our OT fonts. Though I am not working alone on this I can only speak for myself and say, I am looking at near-omega lists and post-alpha tools.

We will be putting this meta data into our fonts in the early fall. This meta data and the tools that read it, will address outstanding and new licensing issues, initially. Later, when it can demonstrated to the interested, much more interesting uses will come forth.

The only other brief brief I'll give you all, is that those who support the EPAR and its meta data, do so entirely without a herd to embolden them. Those who oppose the addition of this data to the OpenType format, might just say anything going forward. So, Heads-Up and My Advice is to follow those who "are accountable."

Cheers!

P.S. Chris, after this little tempest, the dedicated web font development community has to go on to repairing the latin readability meme-plex in low resolution screen typography, so you'll get clearer definition of a meme then. As this is 'the heart of the letter', the beta presentation of this will be at ATypI. You who've been present here over the years, know the alpha.

@nick
"However, a two-format appeals to me as a font manufacturer because I will be able to produce and market two kinds of OpenType font: one (.otf) for print and online display in bitmapped gif/png/jpeg files, that will be feature rich—and another (.eotl) that will have fewer features but more nuanced screen hinting."

Market-oriented thinking!
I like it.

@john hudson

John - the following paints a very wrong picture:

“[And let’s be clear that in terms of market share IE and Firefox are the only two browsers that count. Everything else is a niche product.]”

Just because a browser’s share of market is below a certain percentage doesn’t mean it’s not going to figure into the equation when a web site’s creators decide on using web fonts or not.
There is a strong, strong pull towards authoring for the lowest common denominator (at the cost of not providing a superior, optimal experience for those using more recent and capable browsers - a philosophy I’ve always found frustating.)
In this respect, Safari is no niche product. If web fonts can’t be delivered to Mac users, many sites will pass on it until they can.
Similarly, Chrome hasn’t got any market share worth talking about but because it’s a Google product and has a higher share among developers, what it does and doesn’t support has a far greater impact than it’s numbers would suggest.
Should Firefox support EOTL and .webOTF, that will be a very, very influential factor for the developers of Safari and Chrome. (IMHO)
Itty bitty Opera (which really is a niche product in every sense) has already signaled it has no choice but to follow where Firefox (and IE) lead.
But Safari is a big problem. Until they sign on to these formats, web fonts are still a very iffy proposition for web devs.
Those who manage web sites - especially shopping sites where dollars are on the line - have an almost irrational fear of leaving users behind. Damn near phobic.
Site managers will tend to shy away from new techniques far longer than it is rational for them to do so.

@dberlow
To not revise point3 - a new web format will not prevent casual misuse

A new web format *will* prevent casual misuse, but it will not protect against a deliberate act of misuse – this is very important difference.
Bringing back a “garden fence” analogy – once in a lifetime everyone of us may find oneself trespassing on someone’s private property if the property has no signs and no fence around it. Simply posting the sign “no trespassing”, or putting a fence that can be easily jumped would prevent many people from trespassing. And I absolutely agree with Christopher Slye that a simple fact that web font format is different from one used on a desktop would require people to do something to web fonts to get them to work on a desktop. Many will stop right there and do nothing, some will be curious enough to find out why web fonts are not working on a desktop and what needs to be done to make them work – I am sure many will choose to not do it when they learn what they wanted to know. As a result, a web font format will significantly reduce casual misuse, and will require an informed decision for someone who is going to commit a deliberate act of converting a web font into a desktop format.

point1 We need to put meta data in existing open and published font format

I agree, but this is something we can do today, without anybody’s permission. What I particularly like about WebOTF proposal is that it offers opportunity for extensible metadata. There can be many reasons for this to be useful, and there can be many circumstances when the metadata included in the existing font may need to be different from what you want web users to see. For this reason (and compression, and other things) I have no doubt that WebOTF is a better long-term alternative to EOT-Lite.

On EOT-Lite:
I agree that EOTL is not an ideal solution, and we do not have much flexibility in defining what EOTL is, because of the backward compatibility with legacy IE implementations. However, it’s this very compatibility that makes it an attractive short-term solution, one that can bring web fonts to authors and all web users *today* and make web fonts a market reality for all of us tomorrow. Web authors are our potential customers, I don’t see why we should tell them to wait another five years before we can agree on (and develop implementations for) an ideal solution. Rather, I would give them something they (and I) can live with today, and present them with much better solution five years from now. I am sure that it will benefit everybody – I consider EOTL a full-scale web font trial that will provide us with valuable feedback.

Regards,
Vlad

@Vlad

“I consider EOTL a full-scale web font trial that will provide us with valuable feedback.”

Thank you for sharing this opinion. (This is one aspect of EOTL that's occurred to me and I've hesitated to write about it because I thought it might be construed as a bit of a reach. But I guess I'm not alone.)
I absolutely agree. What deployment of EOTL is going to teach us about web fonts - implementors, web designers, web devs, type designers, all of us - is tons more valuable than years of debate and best-guesstimates at the W3C could ever give us. That we can so easily take an existing real-world solution and expand it to reach so many users in so short a time is a great stroke of luck in that regard.
One hell of a trial run, indeed.

Regards,

Rich

David: The only other brief brief I’ll give you all, is that those who support the EPAR and its meta data, do so entirely without a herd to embolden them. Those who oppose the addition of this data to the OpenType format, might just say anything going forward.

But, David, as far as I know no one is opposing the addition of meta data to the OT format, at least in principle. There's going to be plenty of debate about what that meta data should contain and how it should be structured, but I think you'll find most font makers supportive of the idea.

EPAR is not being opposed; rather, you've been asked two questions, neither of which you have answered:

My question: How do you see EPAR practically being used, i.e. in what kind of scenarios do you see this data being accessed and what actions result?

Thomas' question: do you think that ‘having an EPAR table inside a dedicated web font format is a Bad Idea’ and if so why?
_____

Users will do everything with the new format they did with OpenType.

And some new things too. As explained multiple times by multiple people: a distinct format is a barrier to casually doing those new things to existing OpenType fonts. this is what various foundries have indicated that they want to protect against: widespread, casual and unthinking use of existing TTF and OTF fonts as web fonts, so that when entering the web font market they don't have to compete against unlicensed use of their own products.

Richard: In this respect, Safari is no niche product.

Or, rather, the nature of its niche makes makes it more important than its mere market share would. This is a fair point, and I accept your analysis.

An excellent observation.

Vlad>A new web format *will* prevent casual misuse, but it will not protect against a deliberate act of misuse – this is [a] very important difference.

Most users have never served a font. So... if doing something entirely new is not a deliberate act, I'm not sure what is "a very important difference"?

Most users have never converted a font. So... if doing something entirely new is not a deliberate act, I'm not sure what is... either.

>Thomas’ question: do you think that ‘having an EPAR table inside a dedicated web font format is a Bad Idea’ and if so why?

I assume by 'dedicated web font format' you mean a font format intended exclusively to be served by file name at the ends of urls, to user's machines with full interoperability, a format devoted to being served via linking?

It depends on the format. In the case of EOT, I have consistently expressed that if the font format is called, Embeddable OpenType, then the EPAR inside could say that the font is not for embedding, I won't support that. The format is dedicated to linking served fonts to described contents, and we have enough educational problems left from this font war. Also, as expressed much earlier, if this dedicated font format uses 'meta-data' intended for the permitting of actual embedding, I would not like to support it's repurposing of that meta-data for serving or linking permissions ... at all.

If these things are solved, and if MS doesn't want EPAR in OT, but it's arms're open to EPAR in EOT or EOTL, why not? But then again, does that make sense to you?

As for the other font format proposal, how would anybody know that having an EPAR table inside would be good? But... if I hear "let's do this .webfont conversion thing, take it to the streets ASAP, and then add whatever into this marvelous extendable format" I'd be against that. We have a marvelous extendable format, and that must be the source of all of the new format with exception perhaps of some point-of-license microdata. Otherwise, there will so much expense in this, no one will like it.

So, as EOT stands, there are two things in the way? As .webfonts stands, there's nothing in the way yet? But they both stand in the way of OT, which is not going away.

John, I know the question. I'm gathering time. "Casual misuse" was introduced . . . "unthinking use of existing TTF and OTF fonts" and "only freely licenable" ...it all takes so much time. :-)

Cheers!

David: It depends on the format. In the case of EOT, I have consistently expressed that if the font format is called, Embeddable OpenType, then the EPAR inside could say that the font is not for embedding, I won’t support that.

What's in a name? I agree that it would make no sense to call something 'Embeddable' and at the same time have a table in the font, or even simply the license agreement in the name table, say that the font is not embeddable. It would confuse people. But EOT was never short for "Embeddable OpenType", it has always been short for 'Embedded OpenType", and if a font is embedded but the tables say it must not be embedded then that isn't confusing at all: it's a clear violation.

It should also be noted that EOT Lite is only a working name, and various people on the W3C list, not least Håkon Lie, have already insisted that if this proposal is to become a recommended format then the name must be changed to something that does not reference EOT, so as to avoid confusion and to avoid the suggestion that browsers supporting 'whatever EOTL will end up being called' need to do something, anything with EOT files.

So maybe its helpful to think not in terms of EOTL but instead of a distinctly named similar format that happens to be backwards compatible with EOT support in IE.

Also, as expressed much earlier, if this dedicated font format uses ’meta-data’ intended for the permitting of actual embedding, I would not like to support it’s repurposing of that meta-data for serving or linking permissions ... at all.

The terms 'embedding' and 'linking' are used confusedly and interchangeably and without clear definition. This is why no one seems quite sure whether the OS/2 embedding bits relate to web use in any way; apparently they were originally conceived of as relating to such use, but now seem to imply something quite different, despite Microsoft historical use of 'embedded' in the context of web linked EOT files. And then there is embedding within an application or a game, etc., whether online or on disc, and that is quite different from document embedding or web linking. Terminologically, its a mess.

If these things are solved, and if MS doesn’t want EPAR in OT, but it’s arms’re open to EPAR in EOT or EOTL, why not? But then again, does that make sense to you?

Is this what you've heard from anyone at MS? I can sort of imagine the argument that adding EPAR to OT implies possible widespread system and application updates to do something (what?) with that data, whereas if EPAR is limited to a specifically web font format then only browsers are, possibly, on the hook to do something (what?) with the data. That looks to me like the kind of MS argument I'm familiar with.

We have a marvelous extendable format, and that must be the source of all of the new format with exception perhaps of some point-of-license microdata.

I basically agree with that, and I think a distinction between font level metadata and 'point-of-license' microdata is probably a useful one, given that it looks like we're going to need criteria to determine what belongs in font data and what belongs at the header level.

But you are going to have to move Real Fast if you want EPAR to be into OT/OFF before an interoperable web font format is becomes a reality. The browser makers have got it into their heads to come up with an interoperable solution to using more fonts on the web, and the factors pushing them -- and the degree to which they are pushing each other -- are well outside of the control of font makers.

John Hudson wrote: this is what various foundries have indicated that they want to protect against: widespread, casual and unthinking use of existing TTF and OTF fonts as web fonts

I would have said it is the other way around, the foundries have indicated they want to have a distinct format to protect against widespread, casual and unthinking use of the new web fonts as desktop fonts.

But maybe I've missed some discussion of the converse being true as well? (Note: I don't accept Thomas Lord's assertion as evidence.)

Cheers,

T

Thomas, the point about the vulnerability of existing desktop fonts to use as web fonts, due to ignorance of licensing terms, was made by Christopher during the pre-panel meeting at TypeCon, and I believe Ivo and others concurred. I think it is a valid concern, and in some respects more immediate than the casual and unthinking use of web fonts as desktop fonts. Without the format distinction, there isn't really any such thing as a web font: there is just a desktop font being used on the web and then downloaded and used on someone else's desktop, and without any way of telling where the font came from.

John> So maybe [] think [] of EOTL[,] but instead of a distinctly named similar format [one] that happens to be backwards compatible with EOT support in IE.

Does this 'backward compatibility' still include ambiguously 'web serving' fonts permitted by founders only for embedding in a document?

Cheers!

David: Does this ’backward compatibility’ still include ambiguously ’web serving’ fonts permitted by founders only for embedding in a document?

Backwards compatibility means that a newly defined web font format with the same file header and fontdata arrangement as an EOT font and a recognised magic number will be displayed in IE6, IE7 and IE8 using existing EOT handling. Because the newly defined format is specifically a format for web font linking, it shouldn't be used for any font that is only licensed for embedding in a document. Where's the issue?

Historically, there's a terminological and practical disconnect that renders the OT embedding bits virtually meaningless. The EOT spec relates them specifically to font linking on the web, only refers to such linking as embedding and to linked fonts as embedded fonts: Applications that implement support for font embedding must not embed fonts which are not licensed to permit embedding. Further, applications loading embedded fonts for temporary use (see Preview & Print and Editable embedding below) must delete the fonts from the device when the document containing the embedded font is closed. Sure, terminologically it is confused, but this was the spec for a font file format specifically intended for linking in web pages using @font-face: 'embedding' in this context can only mean web linking.

But in the long period during which EOT was largely ignored by font makers and web designers (outside of complex script countries), the embedding bits came to be associated with document embedding rather than web linking, to such an extent that the browsers now implementing naked font linking feel justified in simply ignoring the embedding bits entirely as if they have—and have never had—any relevance to web font linking.

This is where, theoretically, something like EPAR comes in, to clarify what the embedding bits now only obscure or confuse. But if the existing embedding bits had retained in peoples' minds their EOT-specified relationship to web linking, and if the Monotype vs. Adobe court decision over PDF embedding had not determined that these bits did not constitute a technological protection under the terms of the DMCA, then I don't think we'd see any naked font linking of TTF and OTF fonts, because the non-IE browser makers have indicated that they refuse to get involved in any enforcement that might make them liable under DMCA, and more generally just don't want to get involved in anything that looks like rights/permissions management. In other words, naked font linking is only possible for them because they consider the embedding bits completely ignorable.

So this is why I'm wondering how EPAR is supposed to affect any of this? It seems to me that either EPAR is ignorable, in which case these browsers will ignore it as they ignore the embedding bits, or it is not ignorable, in which case they will refuse to touch fonts that contain it, as they refuse to touch EOT fonts that contain rootstrings.

Whew! So ask a simple question...

John's answer, is that EOT cannot be changed, (except to provide less protection as the 'other' browser-makers see fit). So if one browser maker (MS) wants to repurpose our permissions, and the rest want to ignore them completely, we have to make sure a competent and dedicated format is developed so users at least can be informed if they choose.

Maybe EPAR is ignorable, designed that way to suit the needs of browsers, but it is apparently without competition in this area, and as such, it is already irreplaceable.

From the EOT spec:

"There exists a need for a mechanism to allow people who have licensed the font for use with their documents a way to also use the font for their web content without violating the EULA agreement which they have accepted."

EOT is not only not solving this problem: it makes a single permission, into a double permission, without permission.

So my position remains that without having one permission (at LEAST), dedicated exclusively to "serving", a font format is not a web font format.

EOT was made as a PDF competitor. Precisely because it failed to do that, I'd rather not allow it to become a killer of PDF font embedding. It's not really good at anything, and that's why we ignored it John.

This week, let's count actual heads on this.

Cheers!

[How to close the "strong" tag? Just the end tag does not seem to work.]

Hmmm. You're right, it doesn't. Guess we need a moderator in this case.

I just saw there were actually 2 open ones. Seems to be OK now. Carry on :)

Guess we need a moderator in this case.
this is always the best and probably simplest (if not the most immediate) option.

David, why are you talking about EOT?

EOT is irrelevant. We're not talking about licensing fonts for EOT, we're talking about licensing fonts for new formats, one of which has the practical benefit of being recognised by EOT implementations in existing IE browsers. From a licensing perspective, its something distinct from EOT, and hence what EOT did or did not permit isn't an issue. You specify in your license agreement for the new format web fonts what is allowed and what is is not allowed, and the fact that it is a new format clarifies the scope of the license agreement, i.e. the license applies to this file format, not to any other.

Among the points agreed by the browser makers on the W3C list is that under ‘EOT Lite’ implementation

1) the new EOTL fonts will need to be recognisably distinct from EOTC (‘EOT classic’) fonts, such that

2) EOTL fonts will be backwards compatible with EOTC handling in IE7–8 but EOTC fonts will not be forwards compatible with EOTL handling in browsers.

There's also generally agreement that EOTL should be renamed in some way that does not reference EOT, specifically so that browsers are not led to believe that they need to do anything with existing EOTC fonts.

I was contacted a few weeks back by a web developer who wanted permission to convert one of my freeware fonts into the Cufón format for web display. After receiving a bit of "edumacation" on the subject, I said OK. Cufón is NOT a font format, per se: it uses Javascript to build the font outlines.

The Cufón "system" uses one Javascript file to perform swaps with HTML tags (<h1> through <h6>, <p>, etc.), and separate Javascript files contain the font data. Theoretically, you can domain-restrict use of Cufón font data but, since the Javascript file can be edited in any simple text editor, it's not a terribly secure system; on the other hand, Cufón can ONLY be used on web pages, so that's an upside.

KL>[How to close the “strong” tag? Just the end tag does not seem to work.]

I coded it properly, previewed it as per my way. Saw no problem and went back to the beach.
Sorry for any apparent neglect on my part for the perfect appearance of my post.

Kent>... Guess we need a moderator in this case.

Kent you ignorant stencil, I think we only need moderators when two or more members erupt into personal, rather that issue-related spitballing. ;)

John>David, why are you talking about EOT?

John you ignorant bitmap, ;) I am talking about EOT because your last post linked to the W3C's/EOT specification without warning, exposing my gentle nature to the aggravated assault of their logo, colors and fonts, not the mention the EOT specification itself.

I am also talking about EOT because it's only proposal on the table that, (correct me if I'm wrong), makes 10s of 1000s, perhaps a 100,000 fonts in the field today, legal to serve without the IP owners permission, and with no options, I'm disagreeing with it's further development without substantial change.

Are any of these fonts with embedding set to any form of "yes" yours by the way?

Cheers!