Re: Downloadable fonts and image replacement

Also sprach Joshua RANDALL FTRD/DIH/BOS:

 > > 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.)
 >
 > Yes, and while obviously you could just set it by ID instead, it  
 > would be kind of irritating that you would have to list the whole  
 > order-of-preferences each time rather than somehow being able to just  
 > add the images to each element.

Right. It could be done on the style attribute, but you would still
need to repeat the whole list.

 > It just doesn't quite seem right to  
 > have the replacement images as part of the font-family property.   
 > However, using more than one property, it would be hard to specify  
 > arbitrary orderings.

This is a good summary of a design issue we're facing. It might be
possible to fullfill both requirements (one property, being able to
"just add the images to each element") by using an attribute. Here's a
(slightly edited) snippet from an earlier message in this debate:

  <p src="holiday.png" srctype="image/png">
      An image of us on holiday.
  </p>

You could pick up the value of the src attribute with this code [1]:

  p { font-family: url(fonts/svg), attr(src, url), serif }

Or, perhaps:

  p { content: url(fonts/svg), attr(src, url), serif }

[1] http://www.w3.org/TR/css3-content/

 > It might work to group all the replaced content  
 > together and have a keyword in the font-family list that specified  
 > where the replaced content goes, although then wouldn't we also need  
 > a way to select the content based on the activation of that keyword?   
 > Something like this might work:
 > 
 > .company {
 > 	font-family: url(fonts/company.svg#companyfont), fallbackimage, url 
 > (fonts/goodfish.zip), "Impact", serif;
 > }
 > 
 > #companyname:fallbackimage {
 > 	content: url(img/companyname.svg), url(img/companyname.png), contents;
 > }

The idea of using a pseudo-class is interesting. It gives you a new
set of property values to play with. For example, you may want to set
a different value on the 'width' and 'height' properties for the image
than for the text. 

 > #divisionname:fallbackimage {
 > 	content: url(img/divisionname.svg), url(img/divisionname.png),  
 > contents;
 > }
 > 
 > I suppose the way to implement that would be to have the font engine  
 > activate the fallbackimage psuedo-class if it encounters the  
 > fallbackimage keyword in the font-family, and then continue down the  
 > list until it successfully gets a font it can render.  Then, the  
 > fallbackimage psuedo-class selector is used to activate the  

I can already hear people saying that selectors should never *do*
anything, just passively select what's already there...

 > replacement content (which in this example would have to all fall in  
 > one position in the font list), which ends with the "contents"  
 > keyword in case the images all fail, which would then be rendered in  
 > whatever font was successfully loaded.
 > 
 > This is sort of the inverse of your previous #3 suggestion "Use  
 > 'content' and 'font-family'".  The earlier one limited the webfonts  
 > to one region of the ordering, this version instead limits the  
 > replacement content to one position in the ordering.

Right.

 > To make an arbitrary ordering possible, perhaps a pseudo-class that  
 > selects based on the rank number of the font that has successfully  
 > been loaded (or the first that failed to load) would work.  In that  
 > case, no explicit keyword would be necessary since the rank order  
 > could implicitly set a keyword for each position.  To clarify, in the  
 > font family property, the list of n fonts could be numbered  
 > 1,2,3,4,5,..n and in the example:
 > 
 > .company {
 > 	font-family: url(fonts/company.svg#companyfont), url(fonts/ 
 > goodfish.zip), "Impact", serif;
 > }
 > 
 > If the SVG font url(fonts/company.svg#companyfont) were loaded  
 > successfully, then the psuedo-class ":font-family-fail(0)" would be  

I once proposed something similar in order to have arbitrary chunks of
generated content attached to an element, not just one befor and one
after. The syntax was deemed to ugly, and I think your proposal risks
the same fate :)

 > > 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.
 > 
 > At least some system font APIs do not require a font to be  
 > "installed" in order to use it or allow an application to specify  
 > that a font should only be installed for use by a particular  
 > process.  Freetype is happy to load a font from memory or from a file  
 > specified by an application.  On WinXP, you can call  
 > AddFontResourceEx with the FR_PRIVATE flag, which should limit access  
 > to the font.

One may get away with that, although one technically still "convert
SVG fonts into system fonts".

 > I had thought that one of the benefits of SVG fonts was that all the  
 > work in rendering them would be done by the browser's internal SVG  
 > engine, such that the rendering would be handled the same way on all  
 > platforms.  I suppose the problem with that is that the layout code  
 > in most browsers is probably tightly tied to system font engines, and  
 > doesn't have appropriate hooks with which to support multiple font  
 > engines simultaneously?

Exactly.

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

Received on Thursday, 27 April 2006 21:31:44 UTC