Re: display vs text faces

On Fri, 26 Jan 1996, lilley wrote:

> What is needed is 

> 1) agreement on a font interchange specification that has a freely available 
>    specification, and 

What about METAFONT files? While the computational overhead is a bit 
stiff, I don't think your average workstation or PC would have a problem 
with it. It's also (so far as I know) free of troublesome legal problems, 
and already implimented for a variety of machines. It is quite capable of
handling scalable fonts in a wide range of sizes, and several texts are 
apparently available on the WWW in TeX format. [1]

METAFONT, rather than converting to a platform's local format, would run 
a local interpreter. It also has the advantage of a large library of free 
fonts, both general- and special-purpose, available on the Web. (See, for 
example, [2].) For those machines incapable of running METAFONT (i.e. 
PDAs with little memory and/or computation power,) authors could provide 
pre-calculated scaled bitmaps for a few (low) resolutions.

> 2) a mechanism whereby fonts can be downloaded on the fly over the web and
>    if necessary converted to the format required by a particular platform.

The mechanism would rely on HTTP, a list of font/* mime-types, and 
content-negotiation. Client caching woul be highly advantageous.

For example, a transaction initiated by rendering from this fragment of 
CSS-like code:

H1 {
     font-family: "http://zit.font.net/iso8859-1/Remus%20Roman.multi"
}

might initiate an HTTP session like the following:

1. The application builds a list of the font formats it (in conjunction 
   with any rendering plug-ins) is capable of handling, along with their 
   relative desirablility, based on font file size, quality, and speed of 
   rendering for each format. (my grasp of MIME is quite weak; please bear 
   with me when I use unregistered types and bad attributes or syntax.)

   font/truetype; type=win; q=0.5
   font/truetype; type=mac; q=0.3  <-- this has a low q factor 
                                       because a (slow) renderer
   font/raster; type=win; q=0.3        plug-in must be used.

2. The server recieves this list of acceptable formats and compares it to 
   the types of its "Remus Roman" files (i.e., all files in the multitype
   list "Remus Roman" in the "iso8859-1" collection.) It discovers the 
   following types:

     FILE                 TYPE
   Remus Roman		font/adobe; type=1
   Remus		font/metafont
   remus.fnt		font/figlet
   remusroman		font/raster; type=x11
   
   It also lists the following types which are available by running 
   server-side conversion software, but scales down the recieved q factors
   recieved from the client to indicate the speed loss due to conversion.

     FILE                 DEST. TYPE           CONVERTER Q MULTIPLIER
   Remus Roman		font/truetype; type=win		0.8
   remusroman		font/raster; type=win		1.0
   remusroman		font/raster; type=pda		1.0

   So the final list of common types and q-factors looks like this:

     TYPE                                Q
   font/truetype; type=win		0.4
   font/raster; type=win		0.3

3. The highest-scoring resource (Remus Roman converted to windows truetype)
   is returned.

[1] http://www.loria.fr/tex/fontes.html

[2] http://jasper.ora.com/CTAN/tex-archive/macros/mtex/metafont/index.html

Benjamin C. W. Sittler

Received on Friday, 26 January 1996 18:18:34 UTC