RE: New work on fonts at W3C

On Monday, June 22, 2009 5:49 PM Jonathan Kew wrote:
> In regard to your last comment:
> > I am afraid to do what John proposed would be absolutely impractical
> > and
> > prohibitively expensive from the production process point of view. I
> > cannot see how we can put this burden on our customers, and I don't
> > think that modifying every single copy of a font licensed for web
> > use by
> > changing its name will work, especially because I'd imagine that
> > font EULAs would also allow non-web use where normal, full-featured
> > font
> > versions with proper names and styles have to be supported.
> I'm not sure this is as impractical as you suggest. Vendors such as
> Monotype would continue to deliver "normal" fonts, but customers
> wishing to use those fonts on a web server would be required (by the
> EULA) to use a tool that replaces the names with "No Trespassing"
> signs -- how is this more burdensome than having to use a tool that
> converts the OTF font to EOT? 

I find it even hard to imagine that we would ever "ask" our customers to
do this. In essence, it can only be done by hand, so that the customer
would be required to obtain or create a font editing tool and manually
modify the copy of the font.
To the contrary, conversion to EOT is an automated process, and if EOT,
or a similar solution, becomes a W3C recommendation, I expect that there
will be plenty of tools available for web designers to use, possibly
integrated with CMS so that the font subsetting, EOT conversion and
compression can all happen behind the scenes when the content is ready
for production (similar to how it happens with PDF today when you click
"convert to PDF" button).

> Either way, the customer has to use a
> tool that readies the font for web-server deployment. Such a font-
> renaming tool would be easy to create, using any of several existing
> (free) font-processing toolkits -- allowing this technique to be
> widely deployed in a fraction of the time it will take to implement
> any other option that involves significant modifications to browser
> code.

... and still leaving the raw font data out in the open, without a
license, eating the bandwidth that a site owner is paying for, and
having to support EOT for IE in addition to raw data? If I were a web
designer, I would rather use sIFR or Cufon (although I like sIFR better
for a number of reasons, including selectable text and SEO).


> Regards,
> Jonathan

Received on Monday, 22 June 2009 22:56:25 UTC