Re: 8r encoding + xdvi :-(

[David Aspinall <da@dcs.ed.ac.uk>]

Like Karl, I hope we can fix gsftopk, if indeed that is where the
problem lies...

To help isolate the problem some more, Joachim Schnitter sensibly
suggested that I should try `tex testfont' on one of the troublesome
fonts to see whether the problem lies in the TFM's,VF's or elsewhere.

So I ran `tex testfont.tex' to generate a table, using the font
"pbkl8r", and I renamed the resulting file pbkl8r.dvi.  When I viewed
pbkl8r.dvi with xdvi, my MakeTeXPK ran `gsftopk pbkl8r 300'.  I have
this line in my psfonts.map file:

pbkl8r 	Bookman-Light "TeXBase1Encoding ReEncodeFont" <8r.enc

And I have version 0.6 of 8r.enc installed.  (I notice that the latest
release of psfonts.beta has two different versions of 8r.enc, the
version under fontname-1.94 has gone to 0.7).  

VF's are immediately eliminated, since the "8r" fonts are now our
"raw" fonts, albeit reencoded.

Results:

1.  Running dvips and printing pbkl8r.ps on a postscript printer, the
    font table is correct and complete wrt 8r.enc.  (it has all the
    characters named in 8r.enc, save the "special" /dotlessj, /ff,
    /ffi, /ffl).  [I take this to mean that the .tfm file is correct,
    at least as far as character position is concerned]

2.  In my xdvi window, /fi and /fl appear as short lines (about a
    quarter of the width of an underscore, a little bit above the base
    line). 
    These characters are missing: /Zcaron /zcaron.  Apart from this,
    the table is correct up to 0x80.
    Above 0x80, there are many omissions (and poorly rendered
    characters).   For example, /endash and /emdash are missing, 
    and in most of the accented uppercase characters, the accents
    appear a little to the left of the character instead of above it.
    0xBF shows /question instead of /questiondown.

3.  When I view pbkl8r.ps in Ghostview, things are a little bit
    different, but not perfect.
    /fi, /fl, /endash and /emdash are present (but /endash and /emdash
    appear as multiple hyphens).  Spacing of the characters above 0x80
    seems suspect.
    
I'm using Aladdin Ghostscript 3.33.

I suspect all this indicates that the problem is within gs.  Perhaps
the .gsf files are rather incomplete (not implementing the full set of
characters), so gs takes special action to construct the unimplemented
characters.  But this action is not taken when gsftopk calls gs to
render characters.  

Somebody that knows ghostscript better than I can probably say whether
this is the case or not.

 - David.