Re: an easy(?) font solution

Your suggestion seems good at my eyes (but I don't work closely
with any font-related poeple).

The only restriction I would like to put is to use some other format :

    * Compressed using a particular method (but the same for each font)
    * Having two sections (like HTTP response)
            > Headers
                > X-Pack-About: xxxxxx (If present, should be accessible 
somehow in the browser)
                > X-Pack-About-Options: ??? (could be browser-related, or 
left for future update of the spec)
                > X-Pack-Domain-Restriction: *.google.be (if present, 
restrict the content to a site, if the browser support this)
                > Content-Type / Content-Length
                > ...
            > A blank line
            > The Font

Delivered by a server, it could be :

    200 HTTP/1.1 OK
    Header: Value
    Header: Value
    Header: Value

    {RawWrapper}

And {RawWrapper}, uncompressed, would contains

    Header: Value
    Header: Value
    Header: Value

    {RawFont}

And {RawFont} would contains the font.

--------------------------------------------------
From: "Thomas Lord" <lord@emf.net>
Sent: Friday, June 26, 2009 9:32 PM
To: <www-style@w3.org>
Subject: an easy(?) font solution

> I noticed a lot of heat and talking past
> one another in the recent "Re: New work on
> fonts..." thread.
>
> I offer (revive) a straw-man proposal here that
> I think can satisfy nearly all stakeholders in
> the web font work, in a simple way:
>
>
> 1) Define a new file format, using MIME
>   for a file with two sections.  One
>   section is called "ABOUT" and the other
>   section is called "PAYLOAD".  The content
>   of each section may be of any media
>   type.
>
> 2) The W3C font Recommendation should allow
>   ("MAY") user agents to recognize any font
>   format whatsoever, however:
>
> 3) The Recommendation should require ("MUST")
>   that for each and every font format
>   handled, the user agent also supports that
>   format when wrapped in the MIME format.
>   When a font is so wrapped, the user agent
>   should ("SHOULD") prominently display to
>   the user a link, or button which, when activated,
>   displays the contents of the "ABOUT" section
>   of the wrapped font.  The user agent may ("MAY")
>   render using the font in the "PAYLOAD" section.
>
>   When displaying the ABOUT section, user agents
>   should treat the content, for security purposes,
>   as if it had been loaded directly via the URL
>   of the wrapped font file.
>
> 4) The Recommendation should choose one or more
>   font formats which should ("SHOULD") be supported
>   both in raw and MIME-wrapped files.
>
> Period.  The end.  Full stop.
>
> Now, what does this get everyone?
>
> For those opposed to DRM (like me) this is
> satisfactory as DRA (digital rights assistance).
> The "ABOUT" section of a wrapped font may convey
> licensing information and the user has a convenient
> way to see that information.   User agents are not
> required to "refuse" to render with a font so
> this is not a case of digital *restrictions* management.
>
> For those who want their restricted license fonts
> on the web but only in a so-called "obscured" format,
> they can require that their fonts are only used on the
> web while MIME-wrapped as I've described.   Users
> will not, for example, be able to casually or accidentally
> use these fonts directly in existing desktop programs,
> for example.  Future desktop programs would likely come
> to recognize the new font format but hopefully they
> will preserve the ABOUT section and make it apparent
> to users.
>
> For those who implement and maintain browsers, this
> is an easy solution to implement and has the benefit
> of a adding useful functionality.
>
> For those who care about "Libre Fonts" - fonts with
> a very permissive, perhaps "copyleft" license to the
> general public - the "ABOUT" mechanism is a means to
> ensure that licensing information is conveyed along with
> libre fonts.
>
> Perhaps most interestingly of all, the very same
> MIME format can also, in principle, be used for other
> media types.  Linked images, CSS files, XSLT programs,
> audio files, and so forth can all be similarly wrapped
> and it is a simple matter to enhance user agents to
> recognize that wrapping and give users prominent access
> to the "ABOUT" information.
>
> Indeed, other applications (media players, word processors
> and so forth) can eventually learn to handle the same
> wrapper format.  As they do, they should, of course,
> preserve and give the user prominent access to the "ABOUT"
> information.
>
> Most or all persistent concerns of stakeholders thus
> solved, this would seem to be a good idea (though obviously
> I'm naturally biased :-)
>
> Note that nothing in this proposal *precludes*
> the use of same-origin restrictions as a means of limiting
> the propagation of font files.   The key point is that a
> W3C font recommendation should not need to mention same-origin
> restrictions unless in non-normative language for informational
> purposes.
>
> Note that a possible attraction of this proposal is
> that it can unfold, longer term, into similar refinements
> of W3C Recommendations regarding other media types.  Thus,
> we have something useful to offer both users and purveyors
> of audio files, video content, images, and so forth.
>
> Finally note that a separate concern is then the possibility
> of additional recommendations which standardize "what goes
> in the ABOUT section".   In that area, if we were to discuss
> it, I would want to talk about ccRel and RDFa.
>
> -t
>
>
>
>
>
>

Received on Friday, 26 June 2009 20:36:21 UTC