Re: Web font linking progress summary

On Thu, Jul 9, 2009 at 7:26 AM, Ben Weiner<ben@readingtype.org.uk> wrote:
> There /is/ a need for a wrapper. ...
> There /is/ a need to find a way to express the rights of use which allow the
> users of a web page to enjoy the enrichment of linked media.

I admit that I've been skimming details of this discussion for the
past few days, but
I worry that perhaps the pendulum has swung too far in one direction.
I haven't heard
a single browser implementor agree that these are desirable features,
and I have no reason to
believe that users are asking for these features, either. This
suggests to me that you
will have a hard time getting people to implement support for this.
Apart from that, haven't
many people pointed out that you can do this today inside OTF without
modifications
(although perhaps not in a machine-readable way)?

> I think we are all slowly coming to see that the question of people
> downloading the font files to the desktop and disregarding any licensing
> terms is a total red herring.

Did I miss something? I don't think there's agreeement on this at all.

The three concrete requirements I've seeming heard from the foundry
representatives are:

1) A solution MUST optionally prevent casual
cross-linking/deep-linking (perhaps solved by CORS, also solved by EOT
w/ root strings),
2) A solution MUST optionally prevent casual user download (which CORS
doesn't address but maybe EOT + root strings do)
3) A solution MUST optionally prevent trivial interop between web
fonts and desktop fonts (which EOT and the other variants do address,
at least until EOT gets baked into the O/S)

Granted, we've all acknowledged that we can't actually prevent any of
these by the determined pirate, but
that we are close to agreeing that they might be good enough
"bulkheads". Note also that the presence of "optionally" is there
to appease those font implementors that do not have any licensing
restrictions or concerns and do not want to enforce any DRE.

I have also heard seemingly heard:

4) All browsers SHOULD support raw .OTF
5) All browsers SHOULD support existing EOT (or EOT "lite")
6) All browsers SHOULD support one common container format, so that
content authors and site admins don't have to
   maintain multiple copies of the font
7) Any container format SHOULD not require modification when content
is promoted between environments

I think we can all see that we the combinations of (4) - (7) may be
mutually impossible, and may conflict with (1) - (3), suggesting
that we can't come up with a solution that meets all 7 requirements.

Recently we've heard that:

8) A container format SHOULD optionally contain machine-readable license info.

However, I've not seen anyone suggest that (8) is an acceptable
alternative to (1)-(3), only that it was an
additional "nice to have". Did I miss something?

Also, if there is an:


8.1) License info either MUST or SHOULD be displayed to the user

I think the browser vendors will balk completely. If the suggestion is
a softer:

8.2) License info "SHOULD be available to the user" (through a
getInfo() / properties() type function)

that might be okay, but I would think it would be pretty low priority
on the implementation queue ...

-- Dirk

(not speaking for Chromium here)

Received on Thursday, 9 July 2009 22:10:46 UTC