Re: .webfont Proposal

That's an interesting idea.  I'm glad that
you are in a position to carry it to foundries
and that you found them warm to the idea.

Three technical nits:

1. An "XML wrapper" is a little bit sketchy of
an idea since what is to be wrapped here is
binary data.   That's why I suggested, instead,
to use MIME.

The "right thing" here would be, I think, to 
develop an XML ontology that is independent
of the representation of the file.  That is,
you can define elements like "sourcename" and
"sourceurl" just as you've done, but we can 
separate concerns and worry how those look in
a file separately.

2. "licenseurl" is a bit redundant, kinda sorta.

I refer you to "ccREL":

http://www.w3.org/Submission/2008/02/
  is the record of the submission and

http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/
  is the document of interest.  Note especially
  the section "7.3 How Tool Builders Can Use ccREL"

They offer, there, a kind of XML ontology for
precisely such purposes.  ccREL has already found
some implementation support both from content
providers and browser implementers.  I suggest
your proposal would be stronger if it drew on 
that work.   (In practice, almost nothing needs
to change about your proposal in that regard.
You would just use their vocabulary instead of making
up a new one.  It should be an easy change to 
make.)

3. About that "allow" tag...

If you have a look at the ccREL submission, please
consider instead using the cc:permits and cc:prohibits
relations.   Those may have the values:

   cc:Reproduction  cc:Distribution cc:DerivativeWorks

For a restricted license font, all three of those may
be declared as prohibited.  User agents are not expected
to enforce such prohibition (for they can not even 
reliably recognize violations) but the notion of ccREL is
that users should be informed.  Again, see section 7.3
of the ccREL submission.

-------------------------------

Suppose that all of that is fine with you
and Erik and the font vendors.  You can separate
representation from logical structure and have a more binary
friendly format such as MIME.  You can work with,
perhaps extending, the ccREL vocabulary.

What then of the actual file format itself?

As I said, I suggest something based on MIME
because it can work with binary data nicely
(MIME as used in email does not ordinarily 
include raw binary data but MIME itself can 
handle it.)

And, because I think it's better to do something
simpler yet more general than to do something
more complicated yet limited, I would suggest that
the meta-data should be HTML.

A nice side effect of that is that ccREL data has a
standard representation in HTML, thanks to the
W3C recommendation for RDFa:

http://www.w3.org/TR/xhtml-rdfa-primer/


Regards,
-t








On Wed, 2009-07-08 at 16:42 -0400, Tal Leming wrote:
> We (Erik van Blokland and myself) have been thinking about the various  
> proposals that have been put forward on this list and elsewhere. The  
> CORS proposal sounded interesting, but with Bert Bos' doubt[1] we went  
> back to the drawing board. We had already been thinking about a light  
> XML wrapper around font data as an alternative to a new binary format.  
> We went back to that and incorporated some of the recent ideas. There  
> is no encryption or obfuscation. The markup is very light and,  
> hopefully, easy to understand. A demo file is attached. The details:
> 
> Required Element:
> - The font data is contained in a <font> element. There are two  
> attributes: format and compression. The format attribute addresses one  
> of the concerns that we have had about the various options being  
> discussed: OpenType is the main font format right now, but that may  
> change in the future. There are no other formats on the horizon, but  
> history tells us that there will be a new format someday. The format  
> attribute allows us to anticipate that. The data inside of the element  
> is the raw font data. It can be compressed and the compression format  
> is specified with the compression attribute.
> 
> Optional Elements:
> - The <allow> element would list domains that are licensed to use the  
> font. A meta URL, "any", would signify that the font could be used on  
> all domains. If a browser encounters a mismatch between the listed  
> URLs and the URL that is trying to use the font, the browser would  
> still render the page with the font. We would like for the browser to  
> display some kind of simple, unobtrusive alert or indicator to the  
> user about the discrepancies in the font's domain information. We  
> think this is similar to Thomas Lord's "Digital Rights Assistance"[2].
> - The <sourcename> and <sourceurl> elements would define where the  
> font came from. This could be a foundry, an open font initiative or  
> anything else. This data could be used for displaying the alert to the  
> user.
> - The <licenseurl> would point to a full text description of the  
> license agreement. The font binary may contain this URL, but it might  
> be easier for the browsers to get it without digging deeply into the  
> file.
> 
> That's it. We have talked to several prominent font foundries about  
> this proposal and it was met with support. There are many things that  
> we font makers would like to see in a format, but we feel that this is  
> a good middle ground for all parties. The browsers are not forced to  
> reject data. Font makers have some basic safeguards for our font  
> data[3]. Font licensees have some protections for their investments.  
> The viewers of sites have no interference to their viewing experience.
> 
> We'd love to know what you think. We're especially interested in  
> hearing from the browser makers. Could you support something like this?
> 
> Tal (and Erik)
> 
> [1] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0273.html
> [2] http://noeot.com/dre-drm-dra.html
> [3] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0359.html
>

Received on Wednesday, 8 July 2009 22:09:11 UTC