Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!elroy.jpl.nasa.gov!jarthur!sif.claremont.edu
From: dhosek@sif.claremont.edu (Hosek, Donald A.)
Newsgroups: comp.text.tex
Subject: Re: Using invisible fonts in slitex
Message-ID: <8258@jarthur.Claremont.EDU>
Date: 4 Sep 90 00:17:11 GMT
Sender: news@jarthur.Claremont.EDU
Reply-To: dhosek@sif.claremont.edu
Organization: Harvey Mudd College
Lines: 54

In article <583@eba.eb.ele.tue.nl>, robert@eb10.eb.ele.tue.nl (Robert Huis in 't Veld ) writes...
>Recently, I started using the EMTEX 3.0 package.
>In general the program runs beautifully. 
>However, I encountered a problem  that I wishes to present to you. 
>The problem is related to the use of fonts, and if I'm not totally
>mistaken it is not only restricted to EMTEX.

>	If one wishes to make overlays with slitex and one uses
>	the \invisible command an error-message occurrs while previewing
>	or printing the slides. This error-message is about slitex not being 
>	able to find the invisible fonts. Since I didn 't generate these fonts
>	I find the error message understandable. One way of solving the problem
>	is by generating the fonts, but I find this an unsatisfactorary
>	solution. The invisible .fmt fonts should be sufficient since they 
>	contain the size information of the printer, which is all that is
>	needed to print the "invisible characters". Can anyone tell me how
>	the latter solution can be  implemented.

Generate the fonts. In PK format, they take up maybe 512 bytes
each, maybe a little more (I don't know since on the disk where
we keep our TeX fonts, files are allocated 5 512byte blocks at a
time).

The width information in the FMT file is available only to TeX,
not to the drivers; the only way for the drivers to handle the
solution you would want is to either (a) have the driver insert
blank space for all missing characters (which is a reasonable
solution, but I wouldn't want a driver doing this without
warnings and I wouldn't want to get warnings about every
invisible font I use) or (b) give the driver an auxiliary file
listing all the invisible fonts so it knows to read the TFM data
and just leave space for those fonts (and yes, reading the TFM
files would be necessary to avoid having PKs since that
information is not in the DVI file).

From an implementor's standpoint, the best solution is to simply
have PK files with empty rasters; yes, it takes up a bit more
space, but there are certain pieces of code in the driver that
this will encourage (the most notable of which is detection of a
character with an empty raster. The Chess fonts on
ymir.claremont.edu, for example, have a single character which is
an empty glyph which causes grief for more than one driver that
I've had experience with (the only one that comes to mind off
hand is dvidis which may or may not have been fixed in the
intervening time since I last used it)).

-dh

---
Don Hosek                       TeX, LaTeX, and Metafont support, consulting 
dhosek@ymir.claremont.edu       installation and production work. 
dhosek@ymir.bitnet              Free Estimates.
uunet!jarthur!ymir              Phone: 714-625-0147
                                finger dhosek@ymir.claremont.edu for more info