[4258] in SIPB bug reports
Re: tex fonts
daemon@ATHENA.MIT.EDU (John T. Kohl)
Wed Nov 17 22:33:02 1993
Date: Wed, 17 Nov 1993 22:31:06 -0500
From: "John T. Kohl" <jtk@atria.com>
To: jh@MIT.EDU
Cc: jtkohl@MIT.EDU, ckclark@MIT.EDU, bug-sipb@MIT.EDU, jh@MIT.EDU,
bert@MIT.EDU
In-Reply-To: Joe Harrington's message of Wed, 17 Nov 1993 22:10:26 -0500,
<9311180310.AA04891@oobleck.mit.edu>
I don't know the details of xdvi's internals, but the main thing is that
xdvi has to do font substitution for PS fonts, displaying CM fonts in
place of the document's PS fonts. Since the two have different
encodings, you're basically scrod.
One potential way around it is to cook up virtual fonts which use TeX
standard encoding, and translate it to PS on the back end [the dvi->foo
processor is responsible for looking at a givent font requested in a DVI
file, and making its glyphs appear. A virtual font looks like any other
font to TeX, but dvi->foo translators treat them specially. The .vf
file contains mappings from characters in the "virtual" font to some
character (maybe even composites? I forget) in some other "real" font.
The .vf can also specify transformations (shrinking, rotation, slanting,
...). The dvi->foo translator must then understand how to use the
"real" font (or fonts) refereced by the virtual font.]
So, in theory, you could set up a PostScript virtual font which just
shuffles the encoding around so that TeX sees a normal encoding. Then
teach xdvi to font substitute for that virtual font directly from CM*,
so that the "right" glyphs show up.
Now, of course, there is one catch; dvi2ps does not understand VFs. The
DVIPS in /mit/sipb/$bindir/dvips is of sufficiently recent vintage that
it should understand them. I don't know what (if any) VFs are set up in
the SIPB locker or on athena.
Your best bet on hacking this is to start with a recent TeX (3.141 or
later, if there is a later one) and the LaTeX NFSS.
==John
