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