W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: CSS3 @font-face / EOT Fonts

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 7 Nov 2008 11:23:54 -0600
Message-ID: <dd0fbad0811070923p49296ba2ha13311d6ed657d2f@mail.gmail.com>
To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
Cc: "Thomas Phinney" <tphinney@adobe.com>, "www-style@w3.org" <www-style@w3.org>
On Fri, Nov 7, 2008 at 11:07 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au>wrote:

> Thomas Phinney wrote:
>> With regards to root strings and staging servers, why not simply specify
>> *both* the staging URL(s) and the real ones in the root string field?
> Speaking with my web developer hat on, having to do that for each and every
> domain I test a site on during development would be a huge inconvenience.
> I have a webserver running on several of my machines (Desktops and
> laptops), each of which I often use at different times and places while
> working on the same site.  Depending on which machine I have the site
> running on at a given time and which machine or virtual I'm accessing it
> from, the domain used to access it could be any one of the following:
> * localhost or
> * Each machine's LAN IP at home, for accessing from the others
> * ComputerName.local - The names each of the machines on the LAN at home.
> * My Laptop's LAN IP at work, which changes relatively frequently
> * - The IP needed to access the local web server from within a
> virtual machine (sometimes this changes, depending on how the network is
> configured).
> * Other staging servers
> * Production server
> I've probably missed some, but to be forced to include each potential
> domain or ip address that I may test a site from within the font file would
> be a huge inconvenience, especially if I missed one and needed to get it
> added.  This would get even worse in a team environment where each developer
> is running a copy of the site on their own local machine for testing their
> changes before checking them into the central repository.

As a web developer myself, I am in a nearly identical situation to Lachlan,
and derive the same conclusions.

> The fact is the DRM will do nothing to prevent piracy, but will still get
> in the way of honest developers.

Note as well that the DRM in question *isn't intended to stop piracy*.  The
measures being discussed are purposely trivial to get around.  Their purpose
is literally to inconvenience people, to provide a small hurdle that has to
be jumped over before one can install a font that they downloaded from the
web.  The issue is that the vast majority of web users would never even
*try* to do such a thing - it wouldn't even occur to them, and just having
to View Source, find where the font is linked from, and then download it
provides a sufficient hurdle for the vast majority of people.  Most of the
inconvenience will be born by people who are doing nothing wrong - browser
developers who have to implement it, and us web developers who have to
conform to it - and existing copyright law is sufficient to prosecute people
who *would* infringe on font copyrights.

This does nothing more than give us honest developers busy work while making
the font foundries have warm fuzzy feelings knowing their fonts are 'safe',
when they are anything but no matter *what* we do (short of
cryptographically signing the fonts...).

Received on Friday, 7 November 2008 17:24:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC