W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: hope for a way forward

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 30 Jun 2009 20:14:52 -0500
Message-ID: <dd0fbad0906301814p79664ce1sbf43c2ced49ecc2c@mail.gmail.com>
To: Jonathan Kew <jonathan@jfkew.plus.com>
Cc: www-font@w3.org
On Tue, Jun 30, 2009 at 5:50 PM, Jonathan Kew<jonathan@jfkew.plus.com> wrote:
> Having watched the web-fonts debate for a while now, I'd like to take a
> fresh shot at presenting a way forward that I hope (in my naivety) might be
> acceptable to the various parties involved. There's nothing really new here,
> but as I've tried to listen to the various viewpoints and concerns, it seems
> to me that we should be able to find some common ground.
>
> Given that:
>
> * major foundries are justifiably concerned about the use of "raw" TTF and
> OTF as web font formats, because this is perceived as making license
> violations - even inadvertent ones - too easy;
>
> * defining a new format whose main purpose appears to be to hinder font
> interoperability between browsers and desktop operating systems may be
> perceived negatively; and
>
> * a "wrapper" such as EOT serves no essential purpose if root-string
> restrictions (or equivalent) are not used, as TTF/OTF fonts already provide
> a standard means to include informative licensing metadata that could be
> presented to users if desired;
>
> I find it difficult to be enthusiastic about simple "obfuscation" or about a
> "font wrapper" that merely encapsulates the font file in some additional
> metadata.
>
> Further, given that:
>
> * typical font data is quite compressible, and using a compressed format
> could provide significant benefits to users (and especially to users with
> low-bandwidth connections/devices);
>
> * applying standard "whole-file" compression such as gzip does not address
> the foundries' concerns, because linked fonts would be trivially (quite
> likely even transparently) decompressed on downloading; and
>
> * a compression scheme designed specifically for fonts could offer tangible
> benefits, which might include better compression and/or more efficient
> access to the data;
>
> I'd like to suggest that a solution is to adopt a compressed-font format as
> the recommended standard for web fonts. Such a format would be designed
> specifically for use with TrueType and OpenType fonts, free of any licensing
> or patent limitations, and simple for browser vendors to incorporate.
> Browsers would be expected to implement default same-origin restrictions for
> such fonts, so that cross-site linking will not work unless the site hosting
> the font specifically chooses to allow it (having checked that the font
> license permits this, of course, and having decided that the potential
> bandwidth use is acceptable).
>
> If we expect (or hope) that the use of linked fonts will become widespread
> on the web, applying compression to all that data is beneficial to everyone.
> And it should not seem strange if there is a font-specific approach to
> compression; just as distinct compression techniques have been designed for
> graphics, video, and audio, a technique designed for font data makes sense.
>
> While it is true that using a compressed-font format will differentiate web
> fonts from desktop fonts, preventing "drag and drop" installation on current
> operating systems, it is important to note that what I am suggesting is not
> "obfuscation", rather it is compression for the sake of more efficient
> transmission.
>
> For the foundries that are concerned about "raw" TTF/OTF fonts being
> deployed on web servers, it provides the same benefit as obfuscation
> proposals - but with a positive technical benefit instead of the negative
> image that obfuscation carries in some quarters.
>
> For browser vendors, the aim is to have a format that all - both proprietary
> and free/open - can agree to implement without compromising either
> principles or commercial interests, and that can be implemented with minimal
> effort and extra code.
>
> Being simply a compressed form of the existing font files, carrying exactly
> the same information, it cannot be perceived as even a potential vehicle for
> any form of DRM, any more than the license field or the embedding bits
> already present in the fonts.
>
> What might such a compressed font format look like? A few days ago, I was on
> the verge of writing a message specifically proposing the adoption of
> "unwrapped" (non-EOT) MTX, with extensions to support OpenType/CFF, as the
> recommended web font format. However, I've been having second thoughts about
> this, and have an alternative approach to suggest that I believe would offer
> some technical benefits. But I will save that for a separate message.
>
> Of course, I don't expect that IE will drop support for EOT, but I'd like to
> think that Microsoft would be willing to add support for
> same-origin/CORS-controlled compressed fonts if foundries indicate their
> readiness to license fonts on this basis. And similarly, I don't expect the
> other browser vendors to remove their current support for TTF/OTF, which
> offers the simplest route for authors (using the exact same font files on
> the desktop and the web server) in cases where licenses permit it. But
> perhaps all parties could agree to also support a common compressed format -
> and vendors agree to license fonts for deployment in this format - so that
> in due course authors will have the option of serving a single compact font
> for use by all browsers.

Entirely as an author (I don't do any dev work on browsers, and though
I have my preferred browsers, I still need to develop sites that are
attractive in all modern ones), I really, truly, honestly don't care
about the font format decided upon.  My *only* requirements are:

1. Must be trivial to use or convert from existing TTF/OTF files.
2. Must be at least marginally acceptable to some significant fraction
of the foundries, so I can use commercial fonts in my work.

Regarding (1):
--------------
* I would *prefer* bare TTF/OTF, as that's the most trivial conversion
of all - I don't do anything.

* I would be perfectly fine with a compressed format, as long as the
program to do the compression was freely available and trivial to use
(preferably drag-and-drop, or shell integration - right click and get
a "Convert to webfont" option).  Compression at least gets me some
nice benefits, if it's quality.

* I would dislike modern EOT, but rootstrings are barely acceptable.
They require more than trivial work, and make it more difficult to
move between servers (or at least require more forethought).  I'd
prefer this be avoided as a consensus solution.

Regarding (2):
--------------
* I really don't care all that much for foundries crying about piracy.
 Every other industry that produces infinite-free-copies (that is,
digital) goods is going through the exact same 'problems', and the
marketplace is adjusting to deal with the new reality.  It's not very
pretty, and many businesses are unable to readjust, but economic
reality truly has changed forever.  I prefer embracing it over holding
it back.

* That said, I like pretty fonts, and our Advertising department tries
to use them constantly in designs.  So far I've gotten away with
making them use reasonably-common fonts for body text (and accept that
fallback to common fonts may happen), and using PIR (an automatic
image generator I wrote for jQuery/PHP that has some decent exposure,
and is still under semi-active development) to handle rare fonts for
headline text.  I'd prefer to not have to do this at all,  of course.

* I'm given to understand that at least some foundries would be
accepting of essentially *any* solution that isn't raw TTF/OTF, and
that in particular a non-ZIP compression method would be acceptable.
I'm fine with this.


My ultimate wishlist, as an author who has a demanding Advertising
department on my back, is for two font formats to be supported: raw
TTF/OTF and an efficient compressed font format.

Raw TTF/OTF is, as noted, already implemented by at least four UAs
(grats to Moz for releasing 3.5 for real today!).  It's the easiest
possible format for me to use, as it requires no effort at all on my
part.  And for free fonts, it doesn't cause me to have to jump through
*any* hoops, no matter how easy.

A compressed format, on the other hand, would apparently be acceptable
to at least some commercial foundries that wouldn't accept raw TTF on
the web.  A good compression format actually gives some nice benefits
to me as an author in terms of bandwidth/storage savings, which makes
it a decent thing independent of any fretting about copyright
violation.

A hybrid approach like this ensures that I'm troubled as little as
possible (none at all, actually) for fonts that don't have onerous
restrictions, and makes the 'restriction' needed for to get
permissions from some font foundries as insignificant as possible,
while actually giving us a benefit that may make the format a
legitimate preferred standard on its own in the future.  It also means
that we gain a staggered approach to functionality deployment, with
some functionality usable *right now* in several browsers.  By the
time the new format gets agreed upon and deployed, hopefully IE can
have put in TTF linking and the new format both, so that in 5 years or
less we'll have complete interop for both formats.

(I have no opinion whatsoever on which compression technology is used.
 I think the MTX technology is sufficiently free at this point to be
used, but anything else would be fine as long as it is minimally
acceptable to the foundries and is a trivial process for me to apply.)

~TJ
Received on Wednesday, 1 July 2009 01:15:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:02 GMT