Re: hope for a way forward

2009/7/1 Jonathan Kew <jonathan@jfkew.plus.com>:
> On 1 Jul 2009, at 02:38, Thomas Lord wrote:
>
>> You have snuck in a requirement to use non-standard
>> compression for the sole purpose of introducing incompatibility ...
>
> ... The purpose of the proposed compression is not to create
> incompatibility but to improve efficiency (of web transport, in particular).
> The fact that it would also address foundries' concerns about deploying
> "raw" fonts in today's desktop formats is of course a valuable side benefit.
>
> As for "introducing incompatibility", applying a targeted compression method
> will not do this any more than packaging a standard font in some additional
> "wrapper"

Right - TL, you yourself have commented on how your wrapper proposal
has this "side benefit" advantage, and is justified by its primary
purpose (to inform users) so I think that JK's compression proposal is
also justified by its primary purpose (to reduce latency. a top
priority for the web.)

But I think Vladimir has really made a very important point: TL and
JK's proposals are COMPATIBLE.

I too would give my vote to "wrapped(compressed(X))" :-)

> that provides no actual technical benefit; it may contain metadata
> such as copyright and licensing information, but fonts already provide a
> means to include this.

The plain text metadata inside font formats is really not very good at
all for being meaningful to users.

The inGIMP project recently presented their work on making a "typical
boring" EULA actually read by users, which you can watch here:
http://river-valley.tv/ingimp-a-smorgasbord-of-usability-adaptive-uis-and-visually-arresting-graphic-design-for-2009/
(you can skip the first half of this short talk to get to the EULA
stuff.)

So, I think the XHTML+RDF payload TL suggests is the best way to
improve licensing metadata on the web; fonts ought to be part of the
semweb, and font licenses ought to be actually engaging for users to
read and obide by.

> Either the wrapper can be automatically generated by
> a tool (equivalent to applying a simple compression tool), in which case it
> adds no value; or else it requires additional information that is not
> available from the original font, in which case creating it will be a burden
> on authors.

There is no burden if the authors just apply it as a silent part of
the compression tool, but for authors who WANT to improve the semweb
aspects of their sites, this is a boon.

>> You haven't (and probably can't) show the "technical
>> benefit" of using a non-standard compression scheme, or
>> at least you can't show a convincing enough advantage to it.
>
> I will be writing more about a possible approach to font compression, but in
> brief, what I will suggest is an approach that compresses individual font
> tables rather than the file as a whole. The key advantage of this is that
> the user agent can then access a particular table (e.g., the cmap, to check
> character coverage) without having to decompress the entire font. In
> resource-constrained environments such as small mobile devices, this could
> be a significant benefit.

I agree, a MTX _style_ font-tables approach using LZMA seems best of breed.

Would MSIE include LGPL software though? :-)

Received on Friday, 3 July 2009 18:24:38 UTC