Web Embedding Allowed

Joe Pemberton's picture

Help create the list of pioneering foundries who are not afraid of the digital future. (Did that sound like an agenda? Oops.)

Shout out the type foundries that allow web and other digital embedding (@font-face, sIFR, Cufon, Flash, etc.

_ It's time to put an end to the ugliness of the web.
_ Time to change the licensing model: sell fonts to designers and web hosts and not to every single reader/device owner.
_ Time to let the desktop publishing mindset die like rubylith and the linotype.

Note: Tiffany started a list here, but it quickly became a discussion. (A discussion worth reading, but it wasn't a list.)

I'll start the list:

Type Together: http://www.type-together.com/

Vlad Levantovsky's picture

@dberlow
>Monotype wants to see high quality typography and fonts on the web and we did go all the way

Really!? Then start at the beginning, not in the middle and explain how your plan will help see high quality typography and fonts on the web.

I hope you did read the rest of my original post. Monotype started by joining W3C and donating our IP and technology for free (http://www.w3.org/Submission/2008/01/).
The fact that some browser vendors decided to stick it to Microsoft (http://www.w3.org/Fonts/Misc/minutes-2008-10#summary) and throw EOT proposal and font vendors under a bus isn't a good enough reason for me to go along and agree to support raw font linking - like I mentioned in the previous post this is not a good solution for the web for a number of reasons, which has already become evident for early adopters.

Successful web font solution needs the following technical components in place:
- it must allow direct font linking using @font-face and at the same time prevent unauthorized cross-origin requests;
- it should protect font vendors IP (and, at the same time, protect web designers who licensed that IP from inadvertently violating their licenses);
- it should deliver compressed font data to minimize bandwidth consumption, speed up page download and improve user experience at the same time and, ideally,
- it should allow font data be streamed so that a browser can start processing the page layout without waiting for a complete font download.

Raw font solution doesn't go beyond direct font linking, EOT successfully addresses first three points, and the very nature of the MicroType Express compression (separating font data into different functional blocks) is an ideal fit for implementing font streaming. Work in W3C is not over - it's in the very beginning(see http://lists.w3.org/Archives/Public/www-style/2009May/0092.html), and developing a new web font solution in W3C will take time - but it's not completely out of the question. At the risk of repeating myself, I am reluctant to support raw font embedding but I am perfectly willing to spend time and efforts to develop a good web font solution for the benefit of all parties involved.

However, your skepticism in the outcome of such initiative and your willingness to go along and allow your fonts be used in raw format "as is" only hampering these efforts and delaying the creation of the new W3C web font solution that will be universally supported by all browser vendors. I would like to respectfully ask you to reconsider your position.

With kind regards

dberlow's picture

Vlad >your willingness to go along and allow your fonts be used in raw format “as is”....

...this is, with all due respect, an incorrect statement about my position. No 'as is' works for me or my clients as I have said many times.

In supporting our position, I've said EOT can easily be one of the formats approved for conversion to in our table, in our fonts.

Cheers!

Richard Fink's picture

@vlad
I've been following the @font-face issue for a really long time now. It was clear to me from the beginning that the legal issues were at the heart of the thing even though those issues were deliberately being kept out of discussions held publicly.
I'm glad that charade is over and we are finally telling it like it is.
When you take into account all of Wium-Lee's public pronouncements on this issue it's not unfair to say that a desire to "stick it to Microsoft" plays a large part.
I've had some back-and-forth with the developers at Mozilla, and I've read some of their public correspondence about support for @font-face, and I think their view of this is more a philosophical thing. They don't want to be seen as IP cops. A commitment to the "Open Web", whatever that may mean to them.
Now, I think they're being pig-headed and knee-jerk about it, I think they're not assessing the issues accurately, but I don't think they are specifically looking to stick it to MS.
I can understand your frustration in paying the W3C - what is the yearly now - $65,000.00? only to have to Wium-Lee act like he knows what he's talking about when he talks about fonts. He doesn't. His doctoral thesis was on - big surprise - Cascading Style Sheets. On that subject, I'll take him seriously. Not a lot else.
However, let's move on. The first chapter in this story has already been written. Safari, and soon FireFox and Opera will support linking to font-files. Internet Explorer has supported it for many years, only they implemented it using a different kind of file format - one that enables you to tie the file to the domain name (and local drive letters too, BTW), provides compression to reduce the file size and thus download time, and allows for subsetting, and is not natively installable as a font file in the operating system.
The "DRM effect" of not being able to transplant the file to another domain or install it in the operating system is incidental to this approach. There are perfectly legitimate reasons for these features that have nothing to do with heavy-handed DRM schemes.

But please, talking about "DRM" is just bad PR and won't get you anywhere - IMHO.
Try using some marketing smarts, that will work much better.

Make the fonts you sell for screen use within the browser as well-suited for that purpose as possible. Pay attention to sub-setted variations of those fonts. Make yourselves the authentic, trustworthy alternative to the "drive-by" download that may or may not be missing characters, or suffer from other hidden problems.

Everybody succumbs to flattery: marketing directly to web developers with fonts for THEM, helpful information for THEM, will help you a lot more than flapping EULA's around that are all about YOU, and YOUR rights.

You will simply be ignored.

In a larger sense, start paying attention to browsers and how they handle fonts. Why do I have to pre-process a font in Photoshop, or render it using a text-replacement technique like Cufon to get a headline with the right kerning and smoothing?

Why hasn't the font industry, as a whole, been more vocal and involved in the development of browser technology? (Hey, maybe I'm wrong, but I sure haven't felt any kind of a presence. Some individuals, yes. But not spokespersons.)

If font-linking leads, as some fear it might, to the death of the industry as a viable money-making entity, you should at least take part in and try to manage your own demise.

But you ain't dead yet.

Enough. For now.

Regards,

rich

Vlad Levantovsky's picture

@dberlow
> No ’as is’ works for me or my clients as I have said many times.

> In supporting our position, I’ve said EOT can easily be one of the formats approved for conversion to in our table, in our fonts.

My apologies if my choice of words was ambiguous, by 'as is' I simply meant fonts in raw format. I just cannot see how addition of a table that is not recognized by any existing application (and not processed by a browser) would make a difference. I did try hard to understand what it is that you are proposing, but I just don't see how the new permission table is going to change things. Any permissions and limitations that you want to express in this new table I can put in plain English in the existing "License Description" field (see http://www.microsoft.com/typography/otspec/name.htm, nameID=13). This information could be used for tracking purposes but I just don't see how it will protect your IP. And, because we already have the "License Description" and "License Info URL" fields in a font, I don't see why you believe a new table is even necessary.

Now back to my original point - raw font linking on the web is not good for a number of reasons, and by allowing it (if you plan to allow it) you may be putting the development of a new solution in jeopardy.

abattis's picture

@dberlow: Where can we read about the technical details of this table you mention? Is there a spec?

dberlow's picture

Vlad, a lot of people are writing and reading ambiguously. That's why it takes so long to craft something clear here.
Are you supporting only unembedded Embeddable Open Type font linking on the web with fonts identical in content to your print/pdf permitted products?

Richard the legal issues are not at the heart of @font-face, but on one surface out of six. W3C is distracting and could be ignored on this issue if not for all those ugly little formats they support around the big one that everybody has access to now. With W3C's baby step-only approach, a PERM table could stay ahead of that organization for years.

Dave, I am designing, through text, tables and diagrams, one surface of a box from which the other 5 can be developed as the world needs them. I can tell you ahead of the second version in 10 days, that two main areas of this solution; permissions and recommendations, contain Bundling, Compressing, Converting, Embedding, Installing, Linking, Modifying, Serving, Siting, Subsetting, Transferring, &... 1D Scaling, Bolding, Baseline Curving, Decontextualizing, Letter-Spacing, Obliquing, Over Scaling, Striking Through, Stroking, Unhinting, Unkerning, and Underscoring, respectively.

Each of these will have conditions after a binary choice and the conditions in permissions will be clearly represented and may be echoed in the license. In recommendations, standard units, percentages of standard units and ranges of the same will be defined for the points, pixels and seconds involved. The definitions for each is either found in CSS, or a typographer's dictionary, to be plain.

If we've left out anything anyone else's print or web clients, or client's clients, client's client's clients have asked permission or recommendation for, please give give me a direct shout.

We are all approximately one Apple white paper away from possibility for an open solution that might eventually lead to completeness — aka a long way from last year. :-)

Cheers!

abattis's picture

@dberlow: Thanks for the summary, I look forward to 10 days time :-) I wonder if, with your preference for clarity, you'd consider rephrasing "permissions" as "restrictions," though.

dberlow's picture

Dave, I think we've got to accentuate the positive, we are not actually in the business of restricting anything and permissions are already very popular.

Cheers!

Richard Fink's picture

@dberlow
>we are not actually in the business of restricting

Good. Now get rid of the word "actually" in that sentence and we've made progress.

Anybody who delivers their work product in digital form cannot demand "restrictions". You cannot even grant "permissions" and enforce them in any meaningful way.

But you CAN ask politely and if you want to call them "permissions", fine. And many will abide by your request as long as it not unreasonable and does not impose an unreasonable cost.

Stop waving the EULA flag. Web developers will look at you like you've got two heads. They will not even comprehend what you're talking about.
"What do you mean I can't..., well, to hell with them", is what you're going to get in response.

Christopher Slye's picture

What is "waving the EULA flag"?

The EULA is important, and as much as people would like to ignore it, they can't. Ignoring the EULA is actually going to create demand for more DRM as foundries try to protect their products by other, more aggressive means.

Remember that "web developers" are not just a bunch of pirates running free on the Internet. Many of them own or work for companies which must follow the law if they want to survive and succeed. They want a font EULA which lets them do what they need to do, but they are not going to say "to hell with them". There are even plenty of people who who have no particular business interests but are still interested in their EULA and doing the right thing by it.

Richard, I think we're saying similar things, but software developers can indeed "demand restrictions" with their EULA. The law will back them up when necessary. It might be difficult or undesirable to enforce at a micro-level, but you can bet that if Nike or Target or the New York Times ignored their font EULA on a large scale, it would be enforced in a "meaningful way". And I bet even "Bob's Widget Company" doesn't want to willfully violate the terms of any software EULA they have.

Obviously it's in a foundry's interest to create a EULA that is easy to understand and has sensible restrictions, but I don't think EULAs are going away anytime soon. They are a fundamental part of the digital font business, for better or worse.

Richard Fink's picture

@christopher
You sense, rightly, that I'm on YOUR side. If anything is deserving of the protection the US constitution empowers Congress to give "the useful arts", it's fonts.
It's both knowledge and labor intensive. A craft.
But I'm also a realist. And I'm telling you that you'll get farther faster if you adopt a humbler and more market-oriented approach.
(All due respect to Dave Berlow, but there's nothing vague about that.)
Try asking, "Oh, you want to use different fonts in your web pages. How can we help?"
Over the next few years, a huge market will open up for screen fonts. And for the first time, many people who ordinarily don't know a serif from a hole in the wall will become potential customers. For the first time they will have to really think about what font they are going to use and where they are going to get it.
Look, nobody wants to be reduced to saying, on bended knee, "Please, mister, please respect the work that went into my product and pay me my fee." But the Internet has turned copyright law upside down on its head and those much more powerful than you or I have been put in exactly that position.
Look at what a big help legal bravado was to the recording industry.
You can make demands, but who will comply?

Thanks for explaining your position. I've been telling you some things on this thread that you don't want to hear, I know. But that's exactly why I'm telling you.

rich

Vlad Levantovsky's picture

@dberlow
>Are you supporting only unembedded Embeddable Open Type font linking on the web with fonts identical in content to your print/pdf permitted products?

I am sorry I am not sure what “unembedded Embeddable OpenType” is. When I say “Embedded OpenType” I refer to the data format that is specified here: http://www.w3.org/Submission/2008/01/. The font in EOT format can be directly linked by a webpage using the CSS @font-face. An EOT file can also be linked back to a webpage (or a domain, a local drive, a file, etc.) using “root string” – sometimes this feature is what people refer to when they differentiate ‘web font linking’ from ‘web font embedding’. The EOT specification doesn’t require this bi-directional linking (i.e. a root string can be empty) but our license does make it a requirement.
Having said this, I do understand that the future web font file format will be something other than EOT, and that the ability to restrict the use of a font resource to a particular webpage or a domain isn’t a new concept for web designers (e.g. see sIFR spec http://wiki.novemberborn.net/sifr/Protecting+Commercial+Fonts), and can be implemented using different tools such as CORS http://www.w3.org/TR/access-control/.

To answer the second part of your question – yes, any font from Monotype, Linotype, ITC or Image Club libraries can now be licensed for use on the web in EOT format. The fonts you get are exactly the same as you would get if you license them for use in print or PDF.

dberlow's picture

@richard> Now get rid of the word “actually” in that sentence and we’ve made progress.

No actually, now that 'permissions' is a word okay with you, we can make progress.

>“Oh, you want to use different fonts in your web pages. How can we help?”

Exactly, and this never will happen without recommendations built-in. One thing I don't think anyone's gonna argue with, is that the W3C opened the doors to the largest school of typography in history.

@Vlad>I am sorry I am not sure what “unembedded Embeddable OpenType” is.

We here consider 'to embed' and 'to link' to be nearly opposite actions with regards to digital data.

>The fonts you get are exactly the same as you would get if you license them for use in print or PDF.

No founders that I have spoken to are going to allow this. It precludes the fundamental course we have all taken that says our print and PDF licensed fonts are not linkable, ever, according to the terms under which they were licensed.

Thus, the need for marks in the font to allow other things. And the need for more information in fonts as to their best uses, recommendations, might not look like a big deal here, but 'out there' it is huge. What few people here consider, for example, is that all the 'web fonts' to date, have been 'cherry-picked' from 'all time' to yield a set of practically indestructible choices. That's all about to end.

Back@Richard>...Bitmap representations of fonts are horribly inaccurate when it comes to assessing how the font will actually look when used to present normal HTML text within the browser.

Actually look? Look — for the first time in history licensees can see exactly what a font will look like on *their screen* before they license to link to it. Presenting a specimen, and allowing the user to see actual @ff results is easy. But still and forever, the shopping user can only make informed decisions about their own view. Assessing how the font will actually look when used to present 'normal HTML text' within ANY browser by ANY user employing ANY machine... how?

Cheers!

Richard Fink's picture

@david

>We are all approximately one Apple white paper away from
>possibility for an open solution that might eventually
>lead to completeness — aka a long way from last year. :-)

What do you mean? Talk to me.

>Assessing how the font will actually look when used to
>present ’normal HTML text’ within ANY browser by ANY user
>employing ANY machine... how?

I'm working on an article about this complete with real-world examples. Title: How To Lose Money On Screen Fonts
Maybe it will shed some light. I'll get word to you as soon as it's posted.

apankrat's picture

4.b.III. Cufon

No additional license is required. Security: you MUST restrict usage (via the Security setting) to one SINGLE domain. You may not reduce the Units Per Em (UPM) quality of the fonts generated by Cufon below 360 UPM

Courtesy of exljbris and Jos, the adventurer :-)

Marisol83's picture

thank you for the the terminal design link! I have a little crisis right now so it may freshen up my mind.
and graphic and type designers are better to work together - i agree

Syndicate content Syndicate content