- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Tue, 11 May 2010 14:27:23 -0400
- To: Thomas Phinney <tphinney@cal.berkeley.edu>, John Hudson <tiro@tiro.com>
- CC: John Daggett <jdaggett@mozilla.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, www-font <www-font@w3.org>
On Tuesday, May 11, 2010 1:54 PM Thomas Phinney wrote: > > On Tue, May 11, 2010 at 10:38 AM, John Hudson <tiro@tiro.com> wrote: > > Levantovsky, Vladimir wrote: > > > >> Regarding the proposed new bit setting and description: The default > >> setting for all reserved bits is currently 'zero'. I am concerned > that > >> defining the new bit as proposed ("No web use allowed") would > automatically > >> make all existing fonts 'allowed' for web use, which I doubt has > ever been > >> an intent. The reversed interpretation "Web use allowed" would be > safe with > >> regard to existing fonts, and it would also play nicely with the > existing > >> definition of other embedding restrictions, including "Restricted > License > >> Embedding" - if both bits are set it would be clearly understood > that > >> document embedding is restricted while web use is allowed. > > > > Yes, that is a better idea. > > > > JH > > Hurm. I have a practical concern with that. What would we expect UAs > to do with fonts they encounter that don't have that bit set? Reject > them all? That hardly seems practical, and I would expect the browser > folks to object strenuously to this if that was the expectation. If > that was *not* the expectation, I don't see much use for the bit. > We have already agreed that UAs in general should not check *any* embedding restrictions - it is expected that a web author has made all necessary checks and once a font resource is served UA should simply use it according to CSS definitions. The flag in question would only be checked when a font resource is created. > In fact, the only obvious ways I see out of that are to either: > > 1) Bump the OS/2 table version so that UAs can know the bit means > something > > 2) have TWO mutually exclusive bits for this new function. One > explicitly says web use allowed, the other explicitly says it's > disallowed. > > I also have an independent concern: what *kind* of web use is implied > by the bit. It seems like foundries are all over the place today in > what kind(s) of web use they are okay with (if/when they allow any). > Does this bit mean WOFF is okay? What about EOT? Cufon? Flash? SVG? > Naked fonts? > Thomas, you bring up very good points. I am not even sure we want to go this route and introduce a new flag. However, the question that I would like to have answered in the first place is regarding the current definition of "Restricted License Embedding". I always understood it to be the only one that clearly and unambiguously limits the use of a font to the licensed copy you have installed locally, with no embedding or any kind of font data exchange allowed. In my opinion, this is the only time when we can rely on fsType restrictions to make a conclusive determination. I've rarely seen the fonts that have this level of restriction, and it would be safe to assume that if properly licensed font has this "Restricted License Embedding" bit set, the licensee can always request a font vendor to supply another copy of the font with the embedding restrictions that correspond to a licensed use. Thank you and regards, Vlad
Received on Tuesday, 11 May 2010 18:26:51 UTC