Re: [wmvs] Requirements for "Valid" Badges [forwarded from Janet Daly <>]

For some reason, I can't seem to be able to bounce (moderate) this mail.
Thus, forwarding.


Forwarded message 1

  • From: Janet Daly <>
  • Subject: Re: [wmvs] Requirements for "Valid" Badges
  • To: Terje Bless <>
  • Cc: QA Dev <>, olivier Thereaux <>, W3C Communications Team <>
  • Message-ID: <>
Terje Bless wrote:

> Hash: SHA1

>>>4. The fonts used must be embeddable — including optimization for
>>>   download time by removing unused glyphs from badge files — and not
>>>   encumbered by any “Intelectual Property” restrictions (since they
>>>   will be part of the Validator source code and published under an OSS
>>>   License) beyond the normal Logo and Trademark guidelines.
>>What does this mean? Do you mean that you would like us to use only
>>OpenSource fonts in our communications materials? I don't know if I can
>>promise that; I only want to be clear on your request.
> Well, ideally “Open Source” font faces — such as “Bitstream Vera” — would be
> used. This would let us include SVG format masters in the source code for the
> Validator under the same license as the rest of the code.

> Any font with a limitation or encumberance on its distribution would require
> us to go to ridiculous lengths in order to satisfy those limitations, our
> internal development requirements, and external user requirements.
> For instance, any font whose license does not allow us to include the original
> font files themselves in the source distribution is probably out of the
> question. Any font which would not let us embed a few of the glyphs — e.g. in
> an SVG master — would make it very hard to use.
> In addition to the straightforward Copyright-related license issues, I'm told
> some fonts have yet further restrictions in some juridistictions. e.g. while
> the US does not allow restrictions on the “shape” of a font (IIRC), some other
> juridistictions /do/; and thus even a free clone or derivative of such a font
> would become encumbered in those juridistictions.
> And finally, some fonts might be distributed under a license that prohibits
> subsetting of the available glyphs or similar modifications. In a context such
> as providing badges in SVG format, this could lead to the ridiculous situation
> of having to either include the full font in each badge (leading to very large
> file sizes) or not embedding the font at all.
> In any case; our main concern with fonts useage for the badges is not whether
> they're “pretty”, suitable for print or web use, legible, etc. (I expect you
> have all those sorts of issues well in hand). Our requirements stem from the
> fonts being, from the perspective of the Validator, essentially “source code”
> and thus needs to allow modification and redistribution under the same terms
> as the surrounding source code.
> In particular, it's not enough to distribute binary objects (PNG, GIF, SVGz,
> etc.) of the pre-rendered badges. We need to include the “source code” masters
> in a way such that the recipient could conceivably regenerate — using Open
> Source tools —  all the badges from the master templates.
> Typically this would be to implement a new compression algorithm, converting
> PNG alpha channel to simple transparency for MSIE:win (a specific use case
> which has cropped up lately), adding Dublin Core or RDF metadata, adding a
> custom glyph for the checkmark in the badges, or similar purely
> technical/format transformations.
> But do note that this is in regards fonts __as_used_in_the_badges__ and not
> font useage in general. I assume and related sites
> would quickly adopt any general font policy for web pages, but here the
> CSS font fallback mechanism would make any encumbered fonts non-problematic.

> It's specifically the font used for the text in the “Valid This” badges that
> concern us.
> Back in 1998 or thereabouts, my then employer set about on a grand project to
> replace their original web site — which was rather austere and simplistic, but
> Valid HTML 3.2; guess who designed it? :-) — with one designed by a local ad
> agency. When the time came for the launch, every employee computer had one of
> the “Copperplate” (98BC?) fonts installed so the site would “look right”...
> It was quite amusing to hear the complaints of the marketing department, upon
> returning from a customer and having demonstrated our shiny new web site, that
> the pages looked horribly ugly and the pretty font didn't show up. Not quite
> as amusing when the proposed workaround was to turn the pages into a single
> large image with an imagemap for links.
> The moral of the story? Font useage needs to be _useable_ first, and æstethic
> second; and in our case, we have some additional use requirements above what
> is normally necessary for design for web publishing.

Terje, thank you very much for this helpful and detailed description. 
Just as I would have a question, the next paragraph would address it.

I'll bring your requests back to the Comm Team, and hope to have a 
response by the start of next week.

Best regards,


> - -- 
> My mom is a professional botanist, or, as her spousal equivalent described
> it, they'll be out hiking in the woods, she'll see a plant off by the side
> of the trail, run up to it, bend down, and start talking Latin at it.
>                                                       -- Steve VanDevender
> Version: PGP SDK 3.2.2
> iQA/AwUBQoMCj6PyPrIkdfXsEQJ69ACfY6IxAUfJc6s5T1t85B74q/9Df8EAmweW
> t1DNOBMjRqnE4/mP2elreEe7
> =d7nW


World Wide Web Consortium (W3C)

Janet Daly, Global Communications Officer
MIT/CSAIL, Building 32-G518
32 Vassar Street
Cambridge, MA 02139

voice: 617.253.5884
fax:   617.258.5999

Received on Wednesday, 18 May 2005 09:22:19 UTC