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

Re: [css3-webfonts] Proposal-in-progress for cross site font sharing [was "Downloaded fonts should not..."]

From: David Woolley <forums@david-woolley.me.uk>
Date: Fri, 18 Apr 2008 08:56:36 +0100
Message-ID: <48085434.1060303@david-woolley.me.uk>
To: www-style mailing list <www-style@w3.org>

John Daggett wrote:
> 
> 1. General use for alphabetic scripts - this is probably what most
+ people thinking about this are interested in, the use of downloaded
+ fonts throughout a site, both for display and body text. Size of the

I don't think that there is much demand for true display contexts, as 
the image replacement genie has been let out of the bag and allows much 
more control; pixelation on printing doesn't seem to be much of concern 
(printing isn't often a big concern, anyway).

I suspect the biggest potential demand is for display fonts in body 
text, as typical in advertising.  Most distinctive freeware fonts are 
display fonts.
> 
> 2. Use in display elements in CJK sites - for Asian languages like Chinese, 

Another use with CJK is to include CJK characters in market areas where 
standard CJK fonts may not be installed.  I've done this (not for a 
commercial site), but I suspect that most authors in this position would 
be unaware of the option and would use image replacement.  This was 
particularly relevant for Windows 95/98/ME, but was also somewhat 
relevant to XP, as most people don't know how to install the CJK fonts, 
there is some risk that OEMs may not include them (although I've not 
confirmed that to he the case), and internet cafes and libraries may not 
have them installed.  I haven't tried to install Vista, but modern 
machines sizes mean that there is no real justification in making CJK 
font installation optional.

 > 3. Use with complex or rare scripts.  This is a big issue in India,
+ where EOT fonts are used as a way of overcoming the lack of fonts that
+ support specific scripts. Concurrent with the increased interest in

I think you may be referring to the abuse of glyph sets with bogus 
character encodings.  I think this is more a legacy issue; i.e. it 
continues to be used because it is a technique that still "works" (in a 
WYSIWYG sense, and supports people with old browsers/font engines), even 
though systems like XP now come with properly encoded fonts, and fonts 
engines that can support them, even for the less commercially attractive 
Indic scripts.

The original problem with Indic fonts, as well as being a low commercial 
priority, was the complexity of ligatures, with, for example a short i 
vowel appearing before the base character and overlapping it, and 
adjacent consonants being merged.  Current font engines can cope with 
those ligatures, whereas the EOT hacks used a preprocessor to choose 
appropriate glyphs and to re-order them as necessary, then sent them as 
claiming they were windows-1252, or in more enlightened cases, declaring 
a character set of "user defined".

In terms of supporting legacy content, I think one would actually have 
to support EOT, as, in most cases, it would be easier to use the proper 
character code (rather than mapping the glyphs onto ISO 8859/1) and 
platform fonts, for material targetted at new browsers.

+ non-Latin fonts within the type design world, this is where downloadable
+ fonts could have a *huge* impact. This is also one area where I think
+ alternative font formats like Graphite could potentially have a big
+ impact, supporting languages and scripts that most big software and font
+ vendors would generally overlook.

Even five years ago, I might have agreed, but not now.  In any case, 
most freeware fonts are convertible to EOT, using WEFT.

> 
> While the first usage is wonderful, the latter two I think would end
+ up having a much broader impact on web design internationally!

I think the second one would, but I think that the third is now legacy 
bahaviour.

Not that this has much to do with the concept of operating font library 
sites, or deep linking fonts from other sites.

I believe properly authored fonts already have an internal unique 
identifier, which might well be used as the resource name on such a site.

I'm curious, though, as to why anyone should run a site for free 
downloading of fonts, or encourage deep linking of fonts on their sites. 
  Both seem to involve bandwidth costs without any compensating revenue 
stream.  A library might generate revenue from authors searching for a 
font to use, but cut and paste coders would bypass that, and the only 
thing you know about the author is that they are interested in fonts, so 
about the only targetted advertising you could do is for commercial 
fonts, but we are hypothesizing that there is no demand for commercial 
fonts.

I'm afraid this doesn't really come under technical discussion of CSS, 
but I think that is only a recent restriction and I think that CSS 
priorities are mainly driven by non-technical issues, so I don't believe 
it is possible to have a sensible discussion about CSS which is confined 
to purely technical issues.  Technically ignoring the site restriction 
in EOT is very easy.  There are no technical barriers to supporting 
non-EOT fonts - that's already done for local fonts.  Font uniqueness 
can be handled outside of CSS by appropriate use of unique names.  The 
real questions are about prioritisation and about whether less 
restrictive font access on market leaders would result in fonts becoming 
more available, or whether countermeasures to abuse of the mechanism 
might actually make them less available.

-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.
Received on Friday, 18 April 2008 07:57:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT