• To: TeX Fonts <tex-fonts@math.utah.edu>
• From: Louis Vosloo <71172.524@compuserve.com>
• Date: 09 Sep 95 16:01:11 EDT

```From: dhosek@quixote.com (Don Hosek)
To: tex-fonts@math.utah.edu
X-Mailer: PMMail v1.1 UNREGISTERED SHAREWARE

pitfalls.

Yes indeed!
Which is perhaps one reason why DVIPSONE has been the only program supporting
it
(aside from the complexities of having to deal with all sorts of weird font
formats and
unexpected stuff in the encrypted section).

> Many programs which create EPS files will NOT
> include the fonts in the EPS files. This is in fact legal EPS  behavior.

Yes, but then they are *supposed* to include %%IncludeResource: font .... (or
the outdated
%%IncludeFont: ....) DSC comments, *and* the DVI driver is supposed to `expand'
these
by inserting the corresponding font at that point.

> and recognizes that fonts A, B and C are required (which I know dvips does
not),

DVIPSONE does (assuming the required DSC comments are there).

>then the only way to get the fonts into the TeX-generated
>PostScript file is to print something in the required fonts (one
> letter NORMALLY suffices) in white off the edge of the page.
>Bingo, the font is now included and all works.

Ugh, what a kludge (although it reminds me of some other DVI driver that does
this as
a matter of course :=).  The right way to do this is indicated above.

Also, use of \special{header=myfont.pfa} is slightly less kludgy method.

Yes, and if you implement things the obvious way, they will indeed fail in the
obvious
way.  In fact you have a problem any time an EPS file uses a font that is also
used in
the document itself!  But note that this works just fine in DVIPSONE :=)

I always appreciate it when you notice how complicated something really is
(such as not so long ago in the brief discussion about `on the fly' reencoding
:=).

Regards, Berthold.

```