W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: EOT-Lite File Format

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 30 Jul 2009 17:05:08 -0700 (PDT)
To: www-font <www-font@w3.org>
Message-ID: <13244264.197321248998708191.JavaMail.root@cm-mail02.mozilla.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:40 UTC