W3C home > Mailing lists > Public > www-style@w3.org > November 2008

RE: CSS3 @font-face / EOT Fonts - new compromise proposal

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Thu, 13 Nov 2008 17:50:48 -0500
Message-ID: <E955AA200CF46842B46F49B0BBB83FF2767DA4@wil-email-01.agfamonotype.org>
To: "Mikko Rantalainen" <mikko.rantalainen@peda.net>, <www-style@w3.org>

 
On Thursday, November 13, 2008 7:32 AM Mikko Rantalainen wrote:
> 
> Levantovsky, Vladimir wrote:
> > 
> > Yes, I agree that access control gives more flexibility to web 
> > developer, even though it does weaken a level of font protection to 
> > some extent. I think I could live with it given that the 
> font data is 
> > still protected by reasonably strong obfuscation mechanism, and I 
> > believe that the proposed 
> > 'obfuscation-though-font-specific-compression' would be an ideal 
> > solution - it would provide both the sufficient level of protection 
> > and the high efficiency of font compression.
> 
> What does "reasonably strong obfuscation mechanism" mean? If 
> it means MTX compression that is licensed without 
> field-of-use restrictions what does it really accomplish over 
> plain gzip compression?
> 
> Something to think about: if the compression is lossless and 
> it can be legally implemented in free (as in open source) 
> operating systems, I'd assume that font format to be used as 
> native format in no time. That's because if it allows all the 
> same features and requires less disk space, there's no reason 
> not to use it all the time.

Well, yes, the compression is lossless but I am not sure if compressed font as a native OS format is a good idea (and disk space is relatively cheep) - you would constantly need to "decompress-use-discard" font data every time an application starts or when a user selects a new font. In this case, I think it's worth keeping raw data on disk to speed up the OS and apps. However, it's a different situation when you need to store and transmit the data, especially if bandwidth is expensive or low or both (mobile?) - you are much better off compressing the font on a server (once), sending compressed data (as many times as necessary) and decompressing it back to raw data (once).

> 
> However, if the compression cannot be used all the time 
> because it cannot be legally implemented in the operating 
> system, then it also cannot be used in free (again, as in 
> open source) web browsers (e.g.
> Mozilla) either.
> 
> You cannot have it both ways: either the same font file can 
> be used both as a system font and web font or it cannot be 
> used at all (in browser or in the system). That is, unless 
> you decide that you're not interested in free software 
> (operating systems or browsers) users. In that case, I 
> wouldn't count on broad implementation.
> 
> The point is that *you cannot have free DRM system*.
> 

I realize this, and like I said, I am all for allowing any legitimate use - it's the 'illegitimate use' that I am concerned about. The big question is whether there is a chance to draw the line between them.

> 
> >> I don't think there is conceptually anything wrong with 
> the idea of 
> >> compressing the fonts beyond what is available via gzip. 
> However, you 
> >> also want it to be something that a browser can do and a desktop 
> >> application can't, correct? This is where you run into a problem. 
> >> [...]
> > 
> > It is indeed very interesting perspective and I agree with you - I 
> > don't see any problem here. Thinking out loud - I would 
> consider any 
> > such use to be legitimate, if its implemented according to W3C 
> > Recommendation. I see no need to disallow style sheets link to any 
> > fonts - either local or linked from a remote server (assuming that 
> > they are properly licensed).
> 
> Are you okay with assumed "properly licensed" status or do 
> you require some technological "protection" with machine 
> checked licensing? (The protection in quotes because we're 
> delaing with some kind of DRM system which *cannot* prevent 
> copyright violantions.)
> 

I am okay with assumed properly licensed status. I strongly believe that content authors are the kind of people who know and respect the copyrights of others because they expect others to respect their rights. At the risk of repeating myself - I am also okay knowing that those who are determined to rip a font will be able to do it, no matter what we do to prevent it. As soon as relatively simple technical barriers (access control and compression) are in place to prevent "unintentional misuse". 
For example, if you happen to come across and click on this link (sorry, Håkon, I promise I won't use it again ): http://www.princexml.com/fonts/larabie/kimberle.ttf
you (or someone else) may not even be aware that agreeing to save the file is wrong - this is why allowing the use of raw font data is not an option for font foundries - it makes font piracy way too easy.
And, please, let's stop using "DRM" term - there is nothing left in my proposal that can even remotely be considered a DRM. Access control is not DRM, and compression is just that - a compression (albeit a good one ;-)

> 
> > Local fonts are stored in the raw format anyway, and the 
> fonts from a 
> > remote server would be downloaded and decompressed by UA, and made 
> > available for temporary use (e.g. while you are using 
> Google Docs). I 
> > don't see any problem with it.
> 
> How about an UA that makes the fonts available for permanent 
> use despite the *recommended* behavior? Will the fonts be 
> licensed with a clause that prevent serving the font to UAs 
> outside a given list (say "Mozilla Firefox 3 or later, 
> Microsoft Internet Explorer 8 or later) and other UAs will 
> just have to deal without those fonts or lie in their UA string?
> 

I would just trust the UA would do what it's supposed to do (unless a hacker modified Firefox, but that's a different story). I don't think we can prevent this with font licensing - a hacked Firefox version would still be seen as Firefox, licensing restrictions won't help.

Regards,
Vlad

> --
> Mikko
> 
> 
> 
Received on Thursday, 13 November 2008 22:50:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:17 GMT