RE: EOT-Lite File Format

Thursday, July 30, 2009 John Daggett <jdaggett@mozilla.com>:

>This is exactly the kind of thing (meaning embedding bits) we should be getting far, far away
>from. Things like editable vs. non-editable fonts have no place on the
>web, period.

John,

Indeed, absolutely right. When I quizzed Bill Davis about EOT classic's reliance on these bits to allow or disallow the creation of an EOT CL file at TypeCon, the answer turned into a group explanation - by several people - that the embedding bits WERE PRE-WEB and were not to be taken as reliable indicators of licensing restrictions. I was told unequivocally the EULA was primary. (Roll the audio tape!)
No steps backwards. I agree.

Regards,

rich 

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Daggett
Sent: Thursday, July 30, 2009 8:05 PM
To: www-font
Subject: Re: EOT-Lite File Format

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:18:05 UTC