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

Miss Tiffany's picture

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

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

Rob O. Font's picture

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!

Richard Fink's picture

@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

John Hudson's picture

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.

Rob O. Font's picture

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!

Thomas Phinney's picture

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

outrasfontes's picture

@ Richard Fink

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

John Hudson's picture

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.

Thomas Phinney's picture

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

Christopher Slye's picture

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

Richard Fink's picture

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

dezcom's picture

...and MUCH more hinting to be done.

ChrisL

Richard Fink's picture

@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

hoefler's picture

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

Rob O. Font's picture

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!

John Hudson's picture

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

Nick Shinn's picture

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 Slye's picture

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.

hoefler's picture

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?

Christopher Slye's picture

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

Rob O. Font's picture

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.

Richard Fink's picture

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

Richard Fink's picture

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

Vlad Levantovsky's picture

@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

Richard Fink's picture

@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

John Hudson's picture

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.

John Hudson's picture

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.

Rob O. Font's picture

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!

John Hudson's picture

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.

Thomas Phinney's picture

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

John Hudson's picture

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.

Rob O. Font's picture

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!

John Hudson's picture

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.

Rob O. Font's picture

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!

k.l.'s picture

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

kentlew's picture

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

nina's picture


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

paul d hunt's picture

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

John Hudson's picture

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.

TheOtherNick's picture

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.

Rob O. Font's picture

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!

John Hudson's picture

David, I linked to the EOT spec in order to point out that the OS/2 embedding bits were explicitly specified in terms of what we now call web linking, not document embedding. You can say that EOT incorrectly interprets these embedding bits as permitting web linking, but one could just as easily say that font makers have incorrectly interpreted them as permitting document embedding as something distinct from web linking. Best, perhaps, to say that the embedding bits were poorly and ambiguously specified in both the OT and EOT specs.

I think this ambiguity should be addressed in the new EOT-derived web font format. But how to do this? The easiest way would be to simply state that the OS/2 embedding bits are irrelevant to web linking in the new format, and should be taken neither as permission to link nor as denial of permission. In other words, for the purpose of web linking, these bits are ignorable. This is easiest because it is what the non-IE browsers are already doing with regard to embedding bits in naked font linking.

How about if the text of the EOTL proposal is changed to specify that the embedding bits are not indicative of permitting web font linking, and that fonts should only be converted to EOTL -- i.e. whatever it ends up being called -- if the license explicitly permits this. Does that resolve the problem? So long as the functional compatibility of EOTL, i.e. the ability of these new format fonts to function like EOT in IE6–8, is not affected (because that would render the format pointless), there is nothing in the EOTL proposal that isn't open to revision.

Thomas Phinney's picture

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

I remember a TypeCon where Kent and I tied for second place in the Type Quiz. I don't think that one can reasonably call him ignorant, even if a wink is involved.

Cheers,

T

Thomas Phinney's picture

John: Your proposal sounds reasonable to me.

T

Rob O. Font's picture

John> Best, perhaps, to say that the embedding bits were poorly and ambiguously specified in both the OT and EOT specs.

Agreed. What's in a name, you asked? What sin a name, I answer. TrueType became TrueType Open, became OpenType, became Open Font Format (did I miss TrueOpen, somewhere). All are extensions to one expendable format. When I ask(ed) MS people about why: "We know its confusing," they said, period, i.e. no but, no sorry, nothing. It all makes perfect sense to me now. I just have to explain to everyone else, costing extra time and money, and that must suit someone, right? The world is massively confused about his format. That must suit someone, right?

John>I think this ambiguity should be addressed in the new EOT-derived web font format.

I think this long-running history of ambiguity should be snuffed out. It is a strategy based, IMHO, on a childhood that's over.

Thomas> John: Your proposal sounds reasonable to me.

Funny, so did 'your' proposal of around 2002, Thomas, to use these bits for document embedding permissions. Actually, we had no choice, PDF was a loaded gun, put to our heads, and founders were 'given' an offer we couldn't refuse. But it must seem funny now to someone.

I, at least however, went on stage, and gave a presentation called, "Email; Type into the breach". I said we were missing a mechanism. Now, I can't wait anymore for the names to be straightened out, I'm doin' it myself.

Cheers!

Nick Shinn's picture

David, I've found it useful to upgrade my typefaces as OpenType (.otf).
That way, it signals users that they're getting something with different capabilities.
More features and characters, hence the higher price.
An alternative would be to give the fonts version numbers or big cat names.

Richard Fink's picture

@davidberlow

"TrueType became TrueType Open, became OpenType, became Open Font Format (did I miss TrueOpen, somewhere). All are extensions to one expendable format. When I ask(ed) MS people about why: “We know its confusing,” they said, period, i.e. no but, no sorry, nothing. It all makes perfect sense to me now. I just have to explain to everyone else, costing extra time and money, and that must suit someone, right? The world is massively confused about his format. That must suit someone, right?"

I'm always entertained, but when I can actually figure out what you're trying to say, I usually disagree with you.
Not with this. Pawns on a chessboard we are, for sure.
Crafters of the software components like you and guys with the rubber mallets trying to get them to work, like me.

That said, there are decisions to be made regarding font-linking. It's been reported that Font Bureau is going to be offering web font licenses shortly. True?

John Hudson's picture

David: I think this long-running history of ambiguity should be snuffed out. It is a strategy based, IMHO, on a childhood that’s over.

I agree. My concern now is that since EOTL seems to be moving toward at least interim support as an interoperable web font format whether we like it or not, it should not, in your words, get in the way of something like EPAR. So I want to figure out how to revise the EOTL proposal such that the ambiguity over embedding bit meaning is removed. And the best way to do that seems to be to explicitly state that the embedding bits should not be regarded as either permitting or denying web font linking, i.e. that they should be ignored for this purpose. This seems to me to suit everyone: it gives the okay to the non-IE browsers to do what they are going to do anyway, while removing the ambiguity that causes concern to font makers, and pointing users toward the license agreement rather than possible misinterpretation of the embedding bits. Does this make sense to you, David? Is this something I can usefully push on the W3C list as a means to ensure that EOTL doesn't get in your way?

John Hudson's picture

Pawns on a chessboard we are, for sure.

It must be a chaturanga board, because there are definitely more than two players. :)

Richard Fink's picture

@johnhudson

"definitely more than two players"
That's for sure. Let's check with Phinney, I just discovered he's a board game aficionado and collector.

John Hudson's picture

Speaking of Thomas, the point he has just raised on the W3C list should be given some attention:

http://lists.w3.org/Archives/Public/www-font/2009JulSep/1328.html

Syndicate content Syndicate content