W3C home > Mailing lists > Public > www-font@w3.org > January to March 1996

Re: display vs text faces

From: lilley <lilley@afs.mcc.ac.uk>
Date: Sat, 27 Jan 1996 00:16:54 +0000 (GMT)
Message-Id: <9554.9601270016@cguhpa.cgu.mcc.ac.uk>
To: bsittler@mailhost.nmt.edu (Benjamin C. W. Sittler)
Cc: www-font@w3.org
Benjamin C. W. Sittler writes:

> On Fri, 26 Jan 1996, lilley wrote:
> > 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, 

More so than other vector formats such as Trutype, Adobe Type 1?

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

are you alluding to problems with one of the other suggestions? I don't 
think Adobe Type 1 has any problems as long as you call it 
ISO/IEC 9541-3: 1991

> and already implimented for a variety of machines.

Perhaps we could compile a list of possible formats and the platforms
that can handle each, plus the availability of export options to that
format from font design applications and any other considerations such
as availability of hinting and so on.

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

That is a separate issue, as far as I can see.

> METAFONT, rather than converting to a platform's local format, would run 
> a local interpreter.
 
That is one way. Conversion is another. If a platform already has high 
quality rendering code it seems pointless to duplicate it. 

> 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 

or indeed any other vector format

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

Your description was fine, although there seems to be a trend for servers
to advertise what they have in stock rather than for clients to enumerate
everything they can handle.

What is missing from your description, and the much harder part, is
avoiding the single point of failure, and handling payment and
licensing.

-- 
Chris Lilley, Technical Author and JISC representative to W3C 
+-------------------------------------------------------------------+
|  Manchester and North Training & Education Centre   ( MAN T&EC )  |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
| Timezone: UTC        URI: http://info.mcc.ac.uk/CGU/staff/lilley/ | 
+-------------------------------------------------------------------+
Received on Friday, 26 January 1996 19:26:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:37 UTC