[comp.fonts] Standard font formats.

candy@umb.umb.edu (declarer/Karl B./dummy) (04/08/88)

The gf (generic font) and tfm (TeX font metric) font formats developed
as part of the TeX project are standards to a certain extent. Such
files do not depend on the host architecture, are completely in the
public domain, along with code that reads and writes them, and were
developed over a period of about eight years (for gf) and four (for
tfm). In particular, tfm files are more general and technically
superior to afm (Adobe font metric) files, except (possibly) for being
binary instead of ASCII. (I personally don't read AFM files for
entertainment very often, so it doesn't matter much to me; I'd rather
be able to read binary files faster. Font files are never going to be
on the bestseller list.) Perhaps the biggest problem with tfm files is
that they are limited to 256 characters; many programs like having a
few fonts that are huge (e.g., Interleaf and Bitstream) instead of
many fonts that are relatively small.

Karl.    karl@umb.edu     ...!harvard!umb!karl

ken@cs.rochester.edu (Ken Yap) (04/08/88)

Actually it is more correct to say that tfm files hold 256 distinct
sets of metrics. TeX software assumes that characters with the same
residue modulo 256 have the same dimensions. As Knuth explains, this is
intended for oriental languages with many characters but few distinct
widths.

	Ken

robert@pyr.gatech.EDU (Robert Viduya) (04/08/88)

[ My apologies if this gets posted twice; our spool system filled up
  just as I posted the original and I'm not sure if it got out there or
  not.]

My personal opinion about standard font formats is that they shouldn't
use a bitmap representation.  Bitmaps are tied to a particular device
resolution and are difficult to scale properly to other resolutions.
I've had to maintain TeX fonts (using the gf format) on some of our
local machines and having to keep multiple copies of the same font on
disk to support various devices at 100 dpi and 300 dpi (not to mention
write-white vs write-black or various orientations) is rather
time-consuming and disk-consuming especially if one considers that the
information is identical in all aspects save quality.

A spline/vector outline that is filled in is better.  They can be scaled
and rotated to any resolution or orientation by simply applying standard
graphics transformation formulas.  The Hershey fonts are encoded in this
manner and PostScript allows fonts to be encoded in this manner as well
(PostScript allows one to be quite imaginative in what one can do with
an outline font).  A METAFONT input file (which is the only truely
device independent font description in the TeX system) is fairly close
to this model, but not quite exact (the METAFONT model doesn't use
outlines).

			robert


-- 
Robert Viduya						  robert@pyr.gatech.edu
Office of Computing Services
Georgia Institute of Technology					 (404) 894-6296
Atlanta, Georgia	30332-0275

ken@cs.rochester.edu (Ken Yap) (04/08/88)

|My personal opinion about standard font formats is that they shouldn't
|use a bitmap representation.  Bitmaps are tied to a particular device
|resolution and are difficult to scale properly to other resolutions.

Most high resolution fonts are stored as outlines. Storing them as
bitmaps would require too much space anyway.

The problem with storing low resolution fonts as outlines is
quantization error. If the font is to look decent, some manual tuning
may be necessary. In that case you have added information that can't be
recovered by rasterizing the outline.

The Hershey fonts aren't that great on paper if you look closely. You
can see the articulation points.  I once tried generating METAFONT from
the Hershey fonts and did persuade METAFONT to smooth the edges.
Unfortunately some manual editing is required to tell METAFONT where
paths begin and end.  In the Hershey data, unrelated curves are stored
in sequence because the plotter pen doesn't care. But these have to be
broken up for METAFONT or the spline routines go wild. Too much work so
I shelved that idea. If you want to give it a shot, you're welcome to
my code.

PostScript seems to be quite successful at automatic smoothing at low
resolution, I wonder how they do it. It's all hidden in their firmware,
no doubt.

Incidentally, it is straightforward in principle (if not in practice)
to generate outline fonts with METAFONT.  Simply ask for an adequately
high resolution, then convert the rasters to outlines.

	Ken

nrh@hjuxa.UUCP (HASLOCK) (04/09/88)

In article <5352@pyr.gatech.EDU>, robert@pyr.gatech.EDU (Robert Viduya)writes:
> My personal opinion about standard font formats is that they shouldn't
> use a bitmap representation.  Bitmaps are tied to a particular device
> resolution and are difficult to scale properly to other resolutions.
 ...
> A spline/vector outline that is filled in is better.  They can be scaled
> and rotated to any resolution or orientation by simply applying standard
> graphics transformation formulas.

I just completed a training course in PostScript and the point was made
repeatedly that simply scaling a font is not good enough. Adobe has designed
it's fonts to work best at around 12pt. Scaling to below 6pt gives results
in a poor balance between thick and thin strokes especially on high
resolution printers. 300dpi printers simply distort the image because of dot
placement. Scaling to more than 24pt shows up imperfections in the baseline.

I guess that I am trying to say that our standard must include an 'optimal
appearance' range of point sizes. Beyond that, I beleive that this style of
description is the best.

	Nigel
	...!rutgers!hjuxa!nrh

doug@eris (Doug Merritt) (04/09/88)

In article <8421@sol.ARPA> ken@cs.rochester.edu (Ken Yap) writes:
>The problem with storing low resolution fonts as outlines is
>quantization error. [...]
>PostScript seems to be quite successful at automatic smoothing at low
>resolution, I wonder how they do it. It's all hidden in their firmware,
>no doubt.

On a slightly different subject, last week I posted an article to
an Amiga newsgroup in response to a question about how to algorithmically
smooth enlargements of low resolution *bitmap* fonts. There is a
definite connection with non-bitmap formats, although I didn't address
that (it's a conceptual "how to" about low pass spatial filtering).

If there's sufficient interest I could post it (actually a pair
of articles) here, or otherwise mail it to interested parties.

	Doug Merritt		doug@mica.berkeley.edu (ucbvax!mica!doug)
			or	ucbvax!unisoft!certes!doug