RE: New work on fonts at W3C

On Wednesday, June 24, 2009 5:41 PM Aryeh Gregor wrote:
> 
> On Wed, Jun 24, 2009 at 10:42 AM, Levantovsky,
> Vladimir wrote:
> > I think we constantly get side-tracked by EOT (and WEFT), although
> the proposal we have on the table has evolved considerably since then.
> The options that we are considering are same-origin restriction and a
> font wrapper that implements simple-obfuscation and targeted font
> compression (as outlined by http://lists.w3.org/Archives/Public/www-

> style/2008Nov/0412.html).
> 
> Chris Wilson has said that he disagrees with two of the three points
> in that post:
> 

Agreeing or disagreeing on a specific points of a proposal is what I consider a normal part of the development process where a consensus can be reached. What's important is that the IE team seem to be willing to be part of the Fonts WG discussion and to support implementation of the future web font solution (assuming we will get there eventually). I wish other browser vendors will adopt the same open-minded approach.

> On Tue, Jun 23, 2009 at 12:33 PM, Chris
> Wilson<Chris.Wilson@microsoft.com> wrote:
> > 1. I don't think CORS is a good application here, as it seems much
> more destructive to workflow than generating EOT files.
> > ...
> > 3. (linking to "standard" TTF/OTF files)  As previously indicated, I
> don't see any way to make this palatable (without requiring additional
> bits in the TTF/OTF that say this usage is allowed, that would not be
> set in most commercial fonts - e.g. "does not work with any current
> fonts, freeware fonts would have to be updated.")
> 
> Do you even agree with point 3 of the post you link to, that browsers
> should support raw TTF/OTF in addition to the obfuscated format?
> 

I see nothing wrong if (and only if) *all* browsers would support both raw TTF/OTF linking and the new web font solution designed along the lines outlined in point 2). This in turn would leave the choice of a particular solution to use in the hands of web authors (based on their choice of fonts and the specific conditions of the font license they acquired). But, the important part is that both solutions would have to be universally supported for web authors to really have a choice of tools in their possession.

> 
> Anyway.  Let's assume, for a moment, that our main goal is to get one
> format that's universally supported by browsers.  There are three
> possible routes:
> 
> 1) Get all vendors to agree on a new format, which is not usable by
> any existing browser.
> 

I think this would be very desirable outcome that would benefit all users.

> 2) Get Microsoft to agree to ship some subset of OTF/TTF (i.e., such
> that whatever IE supports the others will support, although perhaps
> not conversely).
> 

I am not sure if subsetting/profiling of the OTF/TTF would help here. The reduced feature set will likely hurt some web authors / users who need the full-featured solution to support their native languages.

> 3) Get the other major browser vendors to agree to ship some subset of
> EOT (i.e., such that whatever the other browsers support IE will
> support, although perhaps not conversely).
> 

This would be very desirable. I would support an EOT subset that eliminates root string in favor of same-origin restriction, and I don't think that XOR obfuscation is really necessary if MTX decompression is universally supported by all browsers. 

We can also consider deprecating embedding bits in EOT header. The embedding permissions (encoded in the original TTF/OTF file) should be checked by authoring tool that creates EOT file and, if EOT is created, it means that embedding was allowed - there is no need for UA to verify it again.
 
> Discussion seems to primarily be focusing on (1) and (2).  However,
> these have problems.  (1) requires everyone to agree, which so far has
> proven hard.  It also loses all compatibility with old browsers, so
> there would be a large window when authors would have to support at
> least two font formats.  (2) seems like it's not going to happen,
> since if a font file will work with existing non-IE browsers, it will
> work on desktops too, and Microsoft appears to be against that.
> 

I agree with your conclusions on (1) although I hoped it would not be as hard as it turned out to be. (2) as a subset isn't likely to happen.

> (3), on the other hand, has two major advantages.  The killer
> advantage is that you'll instantly get support from all versions of IE
> dating back to IE4 (?), i.e., a majority of the web from day one.

Absolutely agree.

> This is vastly more valuable than compatibility with Fx3.5, Safari 3
> (4?), etc., for two reasons: IE has a much bigger market share, and it
> has a much slower rate of uptake for new versions.  Users of Firefox <
> 3 are pretty much negligible, and Firefox 3 is barely a year old.  On
> the other hand, everyone still has to cater to IE6, and that's almost
> eight years old.
> 
> The second advantage is that it seems a lot more practical to get all
> the non-IE browsers to implement a subset of EOT than to get everyone
> to agree on a totally new format, 

Yes, this would seem to be the most practical and pragmatic approach, if other browser vendors can agree on a specific subset of EOT.

> or to get Microsoft to ship some
> variant of raw TTF/OTF.  All the objections to EOT look like they're
> easily surmountable by just not supporting the features you don't
> like.
> 

I think it's vital to agree on the subset of features to be supported, otherwise we may end up in a really messy situation with no interoperability between browsers.

> Specifically, if a browser vendor doesn't like RootStrings, they can
> just refuse to process any EOT file with a non-null RootString.  If
> they don't like XOR obfuscation, they can refuse to process any EOT
> file with XOR obfuscation.  If they don't like MTX compression --
> maybe because there's been no official release of the patents yet but
> only promises, 

At Monotype, a promise is *a promise* - this literally defines us as a company; this is who we are: http://www.monotypeimaging.com/aboutus/missionhistory.aspx

I promised to work with Mozilla to come up with the GPL-compatible license, and if I say something - I mean it. Rob, Zack and John have been loud and clear on the importance of Monotype Imaging agreeing to such license; now that the agreement is in place - their silence is deafening!
Our offer is contingent upon the adoption of the technology. I am reluctant to spend company money for legal counsel to draft a patent license until I hear that MTX compression is going to be part of the future web font solution.

> or because they don't want to bother supporting yet
> another compression algorithm -- then they can refuse to process fonts
> using MTX compression.
> 
> The result would be that there would be some font format that would
> work in all browsers.  That format might be, for instance, EOT with no
> RootString and no XOR obfuscation, or something like that.  It
> wouldn't really matter which browsers chose to implement which
> features; authors would just be able to use the intersection of all of
> them, so you'd have a single font format regardless.  

In my opinion, this is the key (if we ever come this far). Authors have to know what format is supported universally.

> Of course, if
> you really want RootStrings and they don't end up supported, you'll be
> unhappy, but I don't think anything will make everyone happy here.
> 
> Are there any objections to or comments on this?  Especially from
> Firefox/Safari/Chrome/Opera people?  I don't think I've seen anyone
> suggesting support for a non-objectionable subset of EOT before, but
> it seems to have clear advantages in terms of getting things to
> actually work, soon.

Received on Thursday, 25 June 2009 04:04:20 UTC