Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.text
Subject: Re: SliTeX fonts
Keywords: TeX, Metafont
Message-ID: <12635@mimsy.UUCP>
Date: 22 Jul 88 15:05:35 GMT
References: <330@marob.MASA.COM> <12395@mimsy.UUCP> <177@infovax.lan.informatik.tu-muenchen.dbp.de>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

>In article <12395@mimsy.UUCP> I claimed that
>>[Invisible fonts do not need a PK or GF or PXL file ....]

In article <177@infovax.lan.informatik.tu-muenchen.dbp.de>
schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) writes:
>This is not quite right.
>
>METAFONT occasionally creates character bitmaps whose dimensions do
>not match the (rounded) ideal measurements given in the TFM file. ...
>Information about the bitmap size for a certain resolution is
>contained in PK, GF, or PXL files.  Device drivers should base their
>character positioning on the bitmap size as well as the TFM size of
>each character (the max_drift algorithm), and thus the bitmap size is
>required even for invisible fonts.

This is indeed true.  In many (not all!) cases, however, the drift
slack will not affect those printing color slides.  Since my invisible
TFM `fonts' are easily configured out, and since I wanted various
options for handling missing fonts (a variant of the `invisible' font
is the `box' font, which prints a square box where TeX thinks the
character goes) it cost essentially nothing to allow it as an option.

>I wish more device drivers would actually use the max_drift algorithm!

Mine do---indeed, I first noted the need for the drift algorithm with
some text printed on a Versatec electrostatic printer (200 dpi).

One of these days I shall have to write documentation for my code....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris