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

Re: CSS21 @font-face removal

From: David Woolley <david@djwhome.demon.co.uk>
Date: Mon, 3 Nov 2003 22:37:28 +0000 (GMT)
Message-Id: <200311032237.hA3MbSV09452@djwhome.demon.co.uk>
To: www-style@w3.org

> As a graduate student in graphic design, please understand that I don't 
> grasp all the nuances of why embedded fonts must be active with a user's 

I didn't understand "active with user's system".

> system when SVG and SWF can embed font sets, but my point is more broad.

The primary problem with SVG is that IE dominates the market but development
has been indefinitely frozen.  I suspect that they never intended to
support SVG even before the freeze.  In addition, the EOLAS patent work
around in IE will make it difficult to use plugins.  Flash will also
be hit by EOLAS, but MS do distribute the plugin.

As regards fonts, the SVG native font system lacks hinting, so is not
suitable for high quality fonts in normal type sizes (based on SVG 1.0
CR02).  As that document says, there was no standardisation of font
formats for CSS fonts.  If you did extract the outline of a high quality
font and encode it as an SVG font, you should expect a cease and
desist order from the font's owners.

Whilst I don't know the exact support in Shockwave Flash, being a closed
format makes it easier to embed quality fonts, as you can make reasonable
claims that you are preventing viewers of the page from extracting the
fonts and using them elsewhere.  This is also why PDF can have embedded
fonts (even though authors often forget to embed them).
The particular problem with CSS fonts is that they are separate from
the document, and in order for the font foundaries to allow their use,
a means has to be provided to stop people simply attaching them to
a completely different document on a completely different web site.
Unfortunately, this also tends to break their use on local copies of
the document or on CD's etc. (although you can probably authorise them
for file:///a:....file:///z:)).

> Most of the work I do with identity systems depends heavily on 
> typographic consistency across all media, and often I start an identity 

This is what page description languages, like PDF, which has had 
embedded fonts since before the web, are intended for.  Using SVG for
this would probably be worse than the current versions of PDF, as they
have accessibility features, to allow the underlying structure to be
represented, that are not present in SVG.  To get accessibility in SVG,
you would have to send as XHTML and use a client side XSLT transformation
to turn it into SVG for rendering.  (SVG does have some accessibility
claims, but I believe they are rather weak in practice.)

HTML was designed for a different environment, where content was more
important than form and where the same document can be used on many
types of media, including those that postdate the document.  (I find it
strange that HTML is used by the marketing department and PDF used by the
technical authoring department, when their target roles are the reverse!
The lack of a vector format may have been an issue, but I suspect it is
more to do with who gets to play with the new toys.)

(A subset of SVG could be considered to be an XMLised version of 
untagged PDF.  Tagging is the feature that allows reflowing, etc. as
needed for accessibility and PDA display.)

> system with the design of a specialized font for the client. It is 
> nearly impossible, without font embedding tools from Microsoft and the 

Are you using these in anger, as my impression is that hardly any
one actually uses font embedding, which is probably why there was
no priority to implement it in Gecko (the core of Netscape 7) and
therefore why it has been dropped from CSS2.1.

Removing it from CSS2.1 will not, of course, remove it from IE.

> Will SVG work to solve this solution, or has the Web taken a huge step 

SVG solves a different problem from that solved by HTML.  It is an
image format, and so, for documents, is only suitable for final form,
print image, documents (one implication of this is that one has to side
scroll them to read them if you need to enlarge the font).

> backward by deprecating @font-src:url? I can't tell if SVG is simply a 

As I understand it, it has not been deprecated, it has simply been
deferred until there is widespread support.  If you could convince people
to use them, embedded fonts would be essential to a proper separation of
form from content, as they allow a very straightforward textual content
to have tightly controlled fonts, and they allow scaling of those fonts.
(The major problems with GIFed fonts is that users cannot override
the size - quite important these days as a large number of sites set
unreasonably small fonts sizes - and can't override the face, in order
to make them easy to read.)

Note that the idea that the end user can reduce a document to its
content and style that for their own convenience may be anathema
to the concept of a house style, but it is, I believe, a fundamental
tennet of the W3C, and even in non-W3C media it is becoming a legal
requirement in many countries, as result of disability discrimination
legislation; this is why tagged PDF was developed.

PS  The SVG people will probably say that I've understated its 
accessibility and ability to handle zooming gracefully.
Received on Monday, 3 November 2003 17:46:09 GMT

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