- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 30 Jul 2009 17:05:08 -0700 (PDT)
- To: www-font <www-font@w3.org>
John Hudson wrote: > > 3. Set the embedding level to one of 0x0000 (installable), 0x0004 > > (preview and print), 0x0008 (editable), 0x0100 (no subsetting) > > > Seems to me it would be simplest to require the EOTL embedding level > > bits to be exactly 0x0008. The other values don't make sense for Web fonts. > > 'Editable' implies that the content of the website set using this font > is editable by the user. This is certainly the case with much web text > -- even posting comments to a blog would qualify --, and will probably > become more common, so I'm inclined to agree that 0x0008 meakes sense as > a default embedding bit for web fonts. > > However, the print and preview embedding level also makes sense in the > context of served content that is not editable by the user, and this > setting is pretty standard for non-web fonts from many foundries. If > editable embedding is to be standard for web fonts, it will have to be > explained to foundries why this is so. This is exactly the kind of thing we should be getting far, far away from. Things like editable vs. non-editable fonts have no place on the web, period. I see no reason to alter the CSS font matching algorithm to support the concept of "fallback in cases where a textrun exists in an 'editable' context and the font is readonly". Defining 'editable' in the context of the web would be a huge pain. The embedding bits are for embedding, they have no role in web usage.
Received on Friday, 31 July 2009 00:05:51 UTC