Re: Downloadable fonts and image replacement

Also sprach Joshua RANDALL FTRD/DIH/BOS:

 > > (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.

Right. You could possibly introduce more keywords to achieve the
resolution you need, but it's cumbersome. I agree that using one
property is better.

 > 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.

So, something like this:

   .company { 
     font-family: url(fonts/company.svg), url(img/company.svg), 
        url(img/companty.png), url(fonts/goodfish.zip), "Impact", serif;
   }

(It doesn't quite do what you want it to as the images (svg and png)
are generic to the whole class.)

 > > 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/).

I was happy to see this. Great minds think alike! (Except that my
not-so-great version is three years behind ;)

Sizewise, the SVG fonts are actually slightly smaller than the TTF
equivalents. The size of the three Vera fonts in TTF tarred/gzipped is
350465 bytes. The same fonts (I trust the conversion) in SVG
tarred/zipped is 279478 bytes. The difference is probably due to the
missing hinting information. And the missing embedding bits :-)

 > 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)

Hmm, this could be troublesome. From discussion with our engineers, it
seems clear that we want to convert all webfonts to system fonts and
inject them into the system. This way, the browser's display engine
only have to relate to one font API. So, an incoming SVG font would be
converted to a format the system can accept. This would be
TrueType/OpenType, in most cases. So, if this conversion is
discouraged, adding support for SVG fonts could require more work than
we want to do. The restriction only applies to "Graphics editing
applications or file translation tools" so it may still be possible
for a browser to convert, as long as the "system fonts" are not
exposed to other applications. A clarification would be helpful.

Has anyone written the SVG-to-TTF converter?

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 27 April 2006 09:08:58 UTC