RE: question
Sylvain Galineau <[email protected]>
| Newsgroups | gmane.comp.web.fonts |
|---|---|
| Message-ID | <045A765940533D4CA4933A4A7E32597E2803F2EE@TK5EX14MBXC111.redmond.corp.microsoft.com> |
There were other issues with EOT. A proprietary patented compression algorithm, same-origin policy enforced by embedding URLs in the file which was problematic for web sites etc. For all the DRM FUD around the latter, WOFF does sidestep a number of real technical quirks in EOT. EOT's major plus was that it was widely deployed. But that doesn't count for much in practice if a technology is not also widely used. What EOT did establish was that obfuscating the raw resource through compression was in fact adequate for a plurality of font vendors. > -----Original Message----- > From: Christopher Slye [mailto:[email protected]] > Sent: Tuesday, October 12, 2010 10:14 PM > To: Sylvain Galineau > Cc: [email protected] > Subject: Re: question > > Some foundries were interested in standardizing EOT and advocated in > unison for it. That was called DRM by some browser developers and other > folks, and rejected partly for that reason. If EOT's mild DRM was DOA, > why consider stronger, newer, or less familiar DRM? > > Thomas's assessment seems accurate to me. > > -C > > On Oct 12, 2010, at 4:53 PM, Sylvain Galineau wrote: > > >> From: [email protected] [mailto:[email protected]] On > >> > >> "We" being the W3C and browser vendors. Of course many font > designers > >> and vendors were very interested in some form of DRM (Digital Rights > >> Management). But ultimately it became clear that browsers weren't > >> going to ever implement anything that even smelled remotely like DRM > >> for fonts, and WOFF emerged as a compromise that delivered useful > >> things for everyone, even if it didn't come anywhere near meeting > the > >> initial desires (DRM) of the folks designing and distributing > >> commercial fonts. > > > > I'm not sure it was that simple. This version of the story assumes > those > > font vendors were willing, able and ready to pay for said DRM systems, > > their deployment and proper management. Something that, imo, is quite > unlikely > > to be affordable to small foundries. (And maybe attractive to the > larger > > ones for that reason ?) > > > > Imo many font vendors who wanted DRM assumed that it would be > reasonably > > effective and cost them very little i.e. browsers would do all the > dirty > > magic and voila ! 'Secure' fonts! All based on the implied assumption > that > > this limited burden would generally result in relatively higher > revenue. > > > > Now, correct me if I'm wrong, but I never noticed the discussion even > getting > > into any kind of depth e.g. to answer the question: which DRM > scheme ? If the > > 'desired' solution is a bunch of foundry coalitions fighting it out > through > > incompatible DRM systems, good luck finding web authors to buy fonts. > Even if > > there were only one such scheme, it would have to be able to work > reliably > > across browsers, operating systems and from smartphone to desktop. > Even without > > the politics, the technical challenge of designing, implementing and > deploying > > such a protocol was orders of magnitude larger than specifying an > encoding like > > WOFF. > > > > Bottom line: yes, there was interest but very little understanding of > what DRM > > meant and what it would have cost. Not just to browser vendors, but > to font vendors. > > > > > > >