🚀 go-pugleaf

In article <1991Aug27.091718.1073@otago.ac.nz> graeme@otago.ac.nz writes:
>I would like to use LaTeX with PostScript typefaces on the PC (emTeX).
>The standard screen previewer doesn't have bit-maps for these fonts and
>will also not handle characters outside the range 1--128. So, can anyone
>point me to a screen previewer that:
>   * handles fonts with >128 characters.
>   * can use the bit-maps that can come with the PostScript printer
>     for Windows.
>
>Even if the second point can be fulfilled, it would be nice to have a screen
>previwer that handles the PostScript typefaces sensibly.
>
>Regards,
>-- 
>Graeme McKinstry,                graeme@otago.ac.nz
>Computing Services Centre,
>University of Otago,
>Dunedin, New Zealand.

The question of how to preview documents that use Postscript fonts
seems to come up occasionally, so I thought I would describe my
solution to the problem.  I produced my solution before support for
virtual fonts was introduced, but there is a more elegant solution
if your previewer supports these (more below).

Using Postscript fonts in TeX (or LaTeX) is obviously attractive
because of the wealth of typefaces available in that form.  However,
it presents the problem of not being able to preview your documents
before printing unless you have suitable bitmaps (eg. PK files) in the
size required by your previewer.  With the exception of Textures with
Adobe Type Manager on the Macintosh (and perhaps xdvi or similar under
X-Windows), bitmaps for Postscript fonts are not readily available (and
indeed might infringe copyrights if they were, unless they have been 
purchased).  So it seems as though most TeX users are out of luck when
trying to preview documents that use Postscript fonts (or BitStream
fonts, etc.).

However, if you do not particularly need to see an "exact" rendering
of the document -- i.e., if you would be satisfied with an
approximation that shows line breaks, etc., then it may be possible to
substitute existing typefaces for Postscript ones.  (This depends on
the previewer, but many previewers offer some facility for font
subsitution.)  For instance, you could substitute the CM sans serif
fonts for the Times family (ie. cmss10 for Times-Roman, cmssl10 for
Times-Italic, etc.), the CM roman family for Palatino, and so on.
Althought the metrics aren't an exact match, the results are reasonable
and you will at least see the general layout of the pages. 

The main problem with this approach is that Postscript fonts use a
different encoding from the one used in the Computer Modern fonts.  My
solution was to re-arrange the TFM files for the Postscript fonts into
the CM encoding (there are a few characters in the CM encoding which
don't exist in the standard Adobe encoding, such as the slash accent
used by \l and \L, dotless j, and the ffi and ffl ligatures).  This
allows direct substitution with CM fonts for previewing, so that
almost all text appears correctly (including accented characters and
ligatures).  In order to print correctly, I had to modify the code
generated by my DVI-to-Postscript filter to handle the different
encoding, which is not terribly difficult.  With dvitops by James
Clark, there is an option to specify an encoding directly in the
dvitops.fnt file, which maps TeX font names to internal Postscript
names.  With dvips by Tom Rokicki, I wrote a Postscript procedure
called EncodeForTeX that takes a Postscript font and returns another
one with the CM encoding, and put this in the standard texps.pro
header file that dvips includes when Postscript fonts are used.  I
then modified each entry in psfonts.map to execute EncodeForTeX on the
internal Postscript font to produce the one used by dvips.  For
example, I have the line

	t-rom   "/Times-Roman EncodeForTeX"

which causes dvips to define t-rom as the result of executing the code
in quotes (t-rom is the name of the TFM file for Times-Roman).

The main drawbacks of this approach are the need to modify the printer
driver, and the inferior quality of the preview (since the metrics
for subsituted fonts don't match exactly).


A solution using virtual fonts
------------------------------

I mentioned at the beginning of this (rather long) article that there
is an elegant solution using virtual fonts.  This solution is quite
similar to mine, except that the font substitution is done by the
virtual fonts themselves, and no alteration to the printer driver is
needed (assuming it supports virtual fonts).  The added advantage is
that even though the previewer may be using the glyphs from cmss10 for
Times-Roman (say), the spacing will be correct because the virtual
font uses the metrics from Times-Roman.  Incidentally, this procedure
has been described by Donald Knuth himself, in an article appearing in
TeXhax Digest Vol. 90, Issue 11 dated Jan. 14, 1990.  (I have a copy of
this article if any one cannot locate it.)

In order to use this approach, you need a virtual font for each
Postscript font that defines all the ligature and kerning information
necessary to make the font presentable (these are available with Tom
Rokicki's dvips, for example).  Thus you will have a TFM file named
pstmsrm (say) which is actually used by TeX when you want to typeset
in Times-Roman.  Since pstmsrm does not have the same encoding as the
real Times-Roman, there is a file named pstmsrm.vf (a virtual font
file) that instructs dvips to use characters from the font TmsR, which
is marked as an internal Postscript font in psfonts.map.  In essence,
pstmsrm.vf contains a little "program" for each character that tells
dvips to use characters from various other fonts (potentially shifting
the glyphs vertically and horizontally, superimposing several
characters, and even including rules and specials) in order to draw
the glyph for that virtual character.

In order to preview the font pstmsrm, we construct another pstmsrm.vf
file (kept in a separate font hierarchy, used by the previewer) that
tells the previewer to use characters from cmss10 instead of TmsR, as 
the printer does.  Because we can use any character from any font
(including characters from other virtual fonts, if we want to), we
can construct glyphs for characters in pstmsrm that aren't in cmss10.
And even if the glyphs from cmss10 aren't the right shape, the
previewer will leave the right amount of space for it, since it
still uses the metrics from pstmsrm (not cmss10).


---------------------- 
To recap, it is possible to preview documents typeset with non-native
fonts (such as Postscript) without having bitmaps for these fonts, as
long as an exact rendition of the printed appearance is not essential.
Virtual fonts are the ideal mechanism to achieve this but the ability
to substitute fonts is enough to produce useful results, provided the
encoding of the non-native font can be coerced into the CM encoding.
This will typically require modification of the printer filter to
convert from the CM encoding to the real encoding.

--
Andrew Innes (aci10@eng.cam.ac.uk)
Engineering Dept.
Cambridge University