W3C home > Mailing lists > Public > www-font@w3.org > April to June 2009

Re: restarting discussion

From: Thomas Lord <lord@emf.net>
Date: Mon, 29 Jun 2009 16:37:16 -0700
To: Håkon Wium Lie <howcome@stans.no>
Cc: www-font <www-font@w3.org>
Message-Id: <1246318636.7452.133.camel@dell-desktop.example.com>
On Tue, 2009-06-30 at 01:04 +0200, Håkon Wium Lie wrote:

> The W3C specification must remain format-agnostic: any attempt to
> favor a certain format will lead to uproar from one camp or the other.

Where do you think there would be uproar against:

  1. Defining the wrapper I've described.
  2. Requiring that if a UA support font format X,
     it must support X-within-that-wrapper
  3. Saying UAs MUST support OT and/or TT, and 
     consequently MUST support the wrapped version
     of same.

I can see that it isn't a "done deal" but I see
cautious warming to the idea, not uproar.  Where
do you see uproar?  Can we hear from those who 
would roar as to why?  (Note, I don't think minor
complaints count as roars but, of course, the line
between the two is partly subjective.)

> (Ideally, web specifications should indicate preference for certain
> formats over others. Supporting the same format is a crucial part of
> interoperability. However, the CSS specs started out being
> format-agnostic, and it's pointless to try change that now).

I'm pretty sure that archivists and content creators
around the world would disagree rather strongly.
It would benefit the majority to have a "MUST" statement
about formats.

> Also, outside the spec one can still argue that browsers should
> support one format or the other. For example, I personally recommend
> that browsers support TT/OT because there are som many TT/OT
> (especially TT) files on the web already.

Of course.  I agree.

>  > On the one hand, you are in effect calling for a
>  > "mod_font" plugin for Apache that autoconverts to 
>  > EOT if it guesses the UA is IE.  

> That's a decent way of dealing with the fact that there's roughly a
> billion IE browsers out there, and that other browsers support TT/OT
> linking.

It is a detriment to W3C's standing if that's the
result we get stuck on.  That's part of what I mean 
by "adults in the room".   The "mod_font" solution is not
decent if you think about how it multiplies and distributes
labor costs and diminishes the quality of the result.

>  > On the other hand, you are leaving a big mess for anyone who wants
>  > to author cleanly archivable web content.

> Is it that bad? 


> One <link> element is all that must be added to use
> webfonts this way. We dealt with PNG in its introductory phase, and
> fonts seem easier: no content is lost if the font can't be reached.

I wonder about what the next Donal Knuth might
think of that.

>  > > This is a slippery slope into DMCA-land. How will browser vendors that
>  > > do not honor this meta-data be treated in the US legal system?
>  > Not so and for a very specific reason:
>  > There should be no normative language that requires
>  > display of the meta-data ("SHOULD", not "MUST").  

> Even so, I'm afraid the courts may rule differently.

Can you substantiate that fear or is it purely
your own issue?  Should *anyone* share that fear
for good reason?  If so, what reason?

>  > By convention it can be used for licensing data but by no means
>  > does the presence or absence of the data or its presentation
>  > comprise an enforcement mechanism or its circumvention.

> Would I feel safe going through US immigration with this assurance?
> Probably not.

Your comment is inappropriate to the forum, even
if it is politically astute in drawing attention
to the alarming level of infringements upon civil rights
that we see in the security apparatus of the US, not 
least at airport and immigration security.  In other 
words, I'm not sorry you said that but it was formally
wrong of you to say it here, in this forum, in this context
and so I won't directly respond to it.

Received on Monday, 29 June 2009 23:38:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:39 UTC