RE: Fonts WG Charter feedback

>-----Original Message-----
>From: Jonathan Kew [mailto:jonathan@jfkew.plus.com]


>On 1 Jul 2009, at 16:07, Sylvain Galineau wrote:
>
>> Ascender's proposal does not wrap anything. EOT did for compression
>> purposes, as well as to
>> embed a root string for same-origin check purposes (the feature some
>> renamed 'DRM').
>
>Right. Personally, I have no objection to Ascender's proposal, but I
>would suggest that the approach I have recently outlined would offer
>two major advantages (and no significant drawbacks) in comparison: (1)
>because it is primarily a targeted compression format, it cannot be
>branded as "obfuscation merely for the sake of breaking
>interoperability"; and (2) making font compression standard on the web
>will reduce bandwidth requirements associated with using linked fonts.

Such rhetorical 'branding' cannot constitute a technical argument or a requirement.
One cannot both be OK with Ascender's proposal and against obfuscation. Since we
seem to have cautious approval of the former - or something similar to it - I'm not going to worry
about the latter too much.

EOT includes some compression through Monotype's MTX. John Daggett has been busy comparing
it to transport compression alternatives. So we'd essentially need to decide whether
the latter is good enough, what other features we might want e.g. as with MTX,
do we want to reorder the font data so the metrics come before the much large glyphs ?
Is that helpful for layout ? Etc. It'd be nice to let the HTTP stack do the work but applying
extra optional transformations to the font file may remain beneficial. I'll let the true experts
argue this one though.


>
>>
>> The goal and benefit are web font interoperability across all
>> browsers and enabling
>> authors to use any font licensed for web use, whether free or
>> commercial. Compared
>> to the current situation, this is *very* tangible !
>>
>> And yes, this is well beyond the scope of this mailing list (and
>> group). Such an effort
>> could also take a substantial amount of time to specify and deploy
>> compared to a focused lightweight alternative.
>> I personally do not want to see the 'perfect' or ideal generic
>> solution delay the good working one.
>
>Likewise. What I have tried to do is to offer a solution that I
>believe could be deployed rapidly, addresses the legitimate concerns
>of the various stakeholders, provides users with tangible benefits of
>both compression (efficiency) and interoperability, and that if
>accepted on its merits need not suffer the negativity associated in
>some quarters with "obfuscation".
>
>JK
If universal interoperability and maximum user choice cannot trump any negativity around obfuscation, then
we have a much bigger problem imo. I'm also honestly doubtful that solving the problem generally
would be so quick. It's simple in principle but once we get into the details I feel like it'd turn
into what people around here call a major rathole. But that is just my opinion.

Received on Wednesday, 1 July 2009 15:47:59 UTC