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

Re: Downloadable fonts and image replacement

From: Joshua RANDALL FTRD/DIH/BOS <joshua.randall@francetelecom.com>
Date: Wed, 26 Apr 2006 16:30:36 -0400
Message-Id: <35863416-B247-4E7B-9DF9-0A8E81BD6FA6@francetelecom.com>
Cc: Joshua RANDALL FTRD/DIH/BOS <joshua.randall@francetelecom.com>, www-style@w3.org
To: Håkon Wium Lie <howcome@opera.com>

On Apr 26, 2006, at 3:45 AM, Håkon Wium Lie wrote:

> You're right. Just like CSS doesn't dictate which formats can be used
> as backgrounds or what formats the 'cursor' property accepts, the
> specification itself should not prescribe which font formats to
> support. As such, the CSS specification doesn't need to change, only
> implementations do.
Agreed. .

> (However, the specification needs to change if we want to webfonts to
> coexist gracefully with pictorial text replacements.)
Yes.  I think the order-of-preference propert(y/ies) for webfonts to  
work alongside generated/replaced content should be able to express  
an order that goes: svg webfont, svg image, raster image, truetype  
webfont, system font, generic font.  This would rule out the third  
possibility you listed "Use 'content' and 'font-family'" since the  
'webfont' keyword would not be sufficient to describe how two  
different webfonts fell in non-sequentially in the list.  A use case  
for this type or ordering could be that an author has created a  
highly stylized company font in SVG, which they prefer to use  
directly to render text contents.  This is efficient because the font  
can be downloaded once and then used all over the doucment to render  
text.  In the event that a user agent doesn't support SVG fonts, but  
does support SVG, they may have also created (probably automatically  
generated by a script) SVG images to be used in place of the  
contents.  These would look identical to the rendered fonts, but as  
each set of text would have to be downloaded individually, it isn't  
as good.  For a user-agent that doesn't support SVG, a rasterized  
image is also provided.  Finally, if the user agent is in text mode  
and images are disabled, the author has specified a preferred  
truetype webfont to be used, followed by a set of system fonts and  
finally generic fonts.

> Yes. It seems, however, that truetype renderers increasingy enter
> these kinds of devices as well -- at least the high end of the range.
> When web fonts were specified in 1998, there was no format that was
> generally available on all desktop systems. That has now changed.
> Despite possible legal problems with TrueType, popular Linux
> distributions include a TrueType renderer and open-source tools can
> generate TTF files (e.g., fontforge).
True, although at least one popular open source TrueType renderer  
(Freetype 2) is by default compiled without the bytecode interpreter,  
so it doesn't support the usual TrueType hinting, although the  
interpreter can be compiled in if for whatever reason the patents  
don't apply to you (see http://freetype.sourceforge.net/ 
patents.html).  The interpreter is replaced in the standard version  
by an 'auto-hinting' module, which ignores the TrueType bytecode and  
instead attempts to achieve the same effect as hinting through  
feature detection and alignment control.

> Certainly, at Opera, we are very proud of our SVG implementation. I
> see some issues wrt. using SVG as a font format, though. First, I
> havn't seen any SVG font families. It would be helpful if someone
> could take an existing font family (I suggest Bitstream's Vera) and
> convert it to SVG for comparison purposes.
The Apache XML (Batik) project has a TrueType to SVG converter (Java)  
that could be used to convert (level 4) truetype fonts to SVG (http:// 
xmlgraphics.apache.org/batik/ttf2svg.html).  There are also a  
converted version of the Bitstream Vera fonts (created by the W3C SVG  
group) that have been converted using Batik (http://www.w3.org/ 
2003/08/sera/).

> Second, AFAIK, SVG fonts
> cannot hold TrueTypes's embedding information (or equivalent).
While it is true that SVG fonts don't have embedding levels, but the  
SVG recommendation seems to me to effectively state that _all_ SVG  
fonts are in effect level two:

"The purpose of SVG fonts is to allow for delivery of glyph outlines  
in display-only environments. SVG fonts that accompany Web pages must  
be supported only in browsing and viewing situations. Graphics  
editing applications or file translation tools must not attempt to  
convert SVG fonts into system fonts." (http://www.w3.org/TR/SVG/ 
fonts.html#SVGFontsOverview)


> Third,
> AFAIK, SVG fonts don't contain hinting information.
True, they don't contain hinting at all.  However, the solution that  
the freetype folks have come up with to avoid legal issues ('auto- 
hinting') doesn't actually use "hinting" either (in the sense that no  
information from the font author is required for it to work).   
Neither is it specific to TrueType -- one of the design goals they  
list is that it should work with any outline fonts and another is  
that the code be independent enough to reuse in other projects  
(http://freetype.sourceforge.net/autohinting/hinter.html#goals).  It  
seems like a user-agent with a high quality SVG fonts implementation  
could make use of the freetype auto-hinter (or something like it),  
and get the same quality our of SVG fonts as truetype fonts have on a  
system that uses the "legal" version of freetype.
Received on Wednesday, 26 April 2006 20:31:06 GMT

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