restarting discussion

To restate my position:

1. Proposals to "xor a few bits" are wrong.

  One idea that makes the rounds is to take an existing
  font format but "XOR a few bits" so that the new
  format will be recognized by web browsers but not
  by existing desktop applications.  The rationale for
  this approach is create a new format which is not
  recognized by existing desktop applications.

  Such a proposal is anathema to W3Cs mission because
  it gratuitously proliferates font formats for the 
  specific goal of breaking interoperability between
  programs.  The idea should be regarded by all as a 
  non-starter.

2. Proposals for novel applications of MTX are wrong.

  MTX compression is offered for the purpose of making
  a new font format that will not be recognized by existing 
  desktop and that will allegedly offer advantages in
  font file size.  MTX is a "font specific" compression
  method.

  Preliminary empirical investigation calls into substantial
  doubt the compression advantages of MTX compared to 
  generic compression methods such as bzip2.  See: 

    http://lists.w3.org/Archives/Public/www-font/2009AprJun/0002.html

  Relying on generic compression has the advantage of 
  minimizing the "feature bloat" of clients.

  We should be left with the impression that the primary
  rationale for MTX is to have a compression format unrecognized
  by both common desktop applications and common decompression
  programs.  As with the proposal to "XOR a few bits" we
  should reject this out of hand.

3. Proposals to steamroll Microsoft are wrong.

  A proposal makes the rounds to standardize on TT and OT
  over the objections of Microsoft and in spite of a 
  likely outcome in which IE does not conform to the standard.

  It is one thing to settle on a Recommendation to which
  IE never comforms if the Recommendations answers the 
  legitimate concerns of Microsoft, quite another if the
  Recommendation fails to recognize Microsoft's legitimate
  concerns.   Such a "screw MSFT" proposal should be rejected
  out of hand in order to protect and preserve the legitimate
  authority of W3C Recommendations generally.

4. Proposals for "root strings" are wrong.

  Proposals are floated in which a conforming browser
  MUST NOT render using a font file which is perfectly
  capable of being rendered if, say, a root string 
  fails to match.

  Aside from the inherent RISKS to life and limb such
  proposal entails, it would impose a conformance
  requirement that deprives users of a useful function
  and contributes nothing to interoperability between
  programs.  The rationale for this would refer to particular
  legal theories, held by a few, applicable in but a few
  jurisdictions.   Such proposals are anathema to W3C's
  role.

What are we left with?

A "wrapper format" can be constructed which can 
embed TT and OT, bundling such font files with 
arbitrary, HTML-formatted meta-data for user 
consumption.  By convention, font vendors can use
that meta-data to include licensing information in 
an accessible format, perhaps using ccREL and RDFa
to make the licensing information machine readable.

With such a mechanism, fonts can be conveyed with
complete licensing information in a form that users
can see.

By coincidence, not rationale, existing desktop 
programs won't recognize the new format however it
is quite reasonable to extend them to recognize the 
new format provided they are able to display and 
preserve the meta-data.

The "wrapper format" is most simply defined in a way
that is not "font specific" and in the future the
same wrapper format might be applied to video, 
audio, pdfs and other media types.   Just as UAs have generic
ways of handling compression, they can have generic
ways of handling this wrapper format and offering 
the meta-data for display to users.  In that way, 
this wrapper format would be a significant step to
improving the architecture of the web generally.

Finally, the implementation burden of the wrapper format
is certainly greater than just decoding a new font 
format (for the display of meta-data must be arranged)
and yet, not a huge burden.  Indeed, the implementation
burden here can be somewhat amortized when it is regarded
as a way to further the work already started by 
RDFa and ccREL.

It seems a clear matter to me that a wrapper format ought
to be adopted along side "raw" OT and TT.  It seems 
clear to me that this proposal satisfies all of the stated
goals of those concerned about restricted-license fonts.

Matters such as subset fonts can be (best) handled 
orthogonally, in the context of TT and OT directly.

Regards,
-t

Received on Monday, 29 June 2009 19:44:28 UTC