> How about downloading each char once and caching each char separately?
> Lots of initial up front costs, but doable now...
> <Img src=/chem/alpha.gif><img src=/chem/omega.gif> etc.
> Daniel W. Connolly writes:
> > Ok... so use xbm, or any other bitmap format. I don't care. The point
> > is that you can GET one image with a whole bunch of glyphs in it.
Perhaps it would be wise to use an existing font format rather than
inventing a specific hack on an image format.
application/x-bdf
springs to mind, using the documented binary distribution format. So you
get all the characters of one font in one file, without having to carve
up an image. Plus you get and encoding vector and kerning info, too.
> Well - no!
> This is a general problem - how to distribute font info reliably.
Agreed.
> Postscript is one answer - except it isn't used by any rendering
> system except the NeXT.
Not so, O NeXT-centric one ;-) PostScript Type 1 fonts can be used by X11R5 and
up systems that have the IBM contributed Type 1 rasteriser built in. Admittedly,
few do. There are also some GNU font utilities though I have not used them
myself. Or did you mean sending the entire document as PostScript? In which
case, workstations from Sun, SGI, DEC, IBM etc all have Display PostScript built
in. Inline EPS anyone? [Note HP workstations are a notable omission from that
list, the only major workstation manufacturer not to provide DPS.]
An advantage of distributing scalable fonts is of course that you get all the
sizes of that font. Sending bitmapped fonts that look OK on, say, a 640 by 480
PC screen look pretty odd on a 1280 by 1024 workstation screen, or when you
choose a different sized set of fonts next week.
> ATM fonts are ok - but X and most Macs
> don't deal.
Sigh. 'ATM' fonts *are* PostScript Type 1 fonts
[Dan again:]
> > No, no, no. It's used just like IMG SRC=... is used, for example,
> > by the LaTeX2HTML translation tools -- to incorporate little images
> > into the flow of text as a hack for characters that are not part
> > of HTML.
Trouble with this is, html file 1 from site A references /chars/alpha.xbm
and this goes in your cache. Then, later, html file 2 from site B
references /fonts/Alpha.gif and you go and fetch that, and so on...
If a single URL was used, sites without a proxy cache would see
tremendous slowdown due to the bottleneck referencing a single site.
URIs URNs or whatever may offer some help in the 22nd century, but
until then ... grin
The solution for the application areas that have been under discussion
is, of course, HTML 3.1, assuming it has enough expressive power to
handle a single inline alpha as well as a fullblown displayed equation.
But the problem then reappears for music notation, astrological symbols,
warning icons ad anything else that doesn't fall under mathematical
notation. So we still need to solve it, I guess.
-- Chris Lilley +--------------------------------------------------------------------------+ |Technical Author, ITTI Computer Graphics & Visualisation Training Project | +--------------------------------------------------------------------------+ | Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc | | Oxford Road, | Voice: +44 61 275 6045 | | Manchester, UK. M13 9PL | Fax: +44 61 275 6040 | | X400: /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/| | <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +--------------------------------------------------------------------------+