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.
> >
> >
> >
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.