Re: ps2pk vs. gsftopk

[Piet Tutelaers <P.T.H.Tutelaers@urc.tue.nl>]

It is amusing to reread the threath about `ps2pk vs. gsftopk' given
the original question and the last reaction from Thierry Bouche.

Thierry concludes with:
 - ghostscript (and therefore gsftopk) is improved since 3.33 
   regarding the rendering of fonts
 - ps2pk has problems with non-standard encoding vectors (?) using
   `Garamond alternate'.

Of course I want to solve the problems you mention but I need at least
a precise description of the problem.  Are you absolutely sure that
your problem is not caused by a problem in your virtual font? I can
hardly imagine that encoding vectors do play a role here.

The features Pierre MacKay has build into ps2pk14m are now more or
less part of ps2pk15. The only difference is that you have to build a
PostScript resource database with mkpsres (distributed with ps2pk) and
to put that on a place in the PSRESOURCEPATH of ps2pk. Perhaps the
following example of PSres.upr is more convincing:
	PS-Resources-1.0
	Encoding
	FontAFM
	FontOutline
	.
        //usr/local/tex-3.1415
	Encoding
	TeXBase1Encoding=dvips/8r.enc
	.
	FontAFM
	Utopia-Regular=fonts/type1faces/Utupia/Utopia-Regular.afm
	.
	FontOutline
	Utopia-Regular=fonts/type1faces/Utupia/Utopia-Regular.pfa
	.

Ps2pk does use psfonts.map for finding the parameters needed to render
a PS font. But thanks to the resource database and lookup functions
>From Adobe it does not need to analyse the modulo MSDOS `<putr8a.pfb'
constructs in it:
  putr8r Utopia-Regular "TeXBase1Encoding ReEncodeFont" <8r.enc <putr8a.pfb

--Piet

| To be more precise than my previous post, I have printed a page in
| Garamond alternate at 600 dpi on the same printer using its PS mode, gs
| 3.53+pcl mode, and dvips -V +PS mode (download gsftopk's pk instead of
| pfb) and I could not make *any* difference between them (not even
| hardly!). Unfortunately, I could not have printed it with pstopk's
| bitmaps because it does not work with alternate sets (I use pstopkm 1.4
| because I could not live with 2 path searching methods, but I understand
| this does not affect rasterization or reencoding stuff)-- what I call
| garamond alternate is a virtual font using AGAramond as base font +
| expert set for ligatures & old style figures + alternate set for
| additional ligatures, I don't know why, but ps2pk has probably problems
| with non standard encoding vectors, as I get empty spaces instead of the
| alternate ligs in xdvi although it works with gsftopk, I encoutered
| similar problems with the bakoma fonts (yes I tried out this *crime*:
| make cmr10.300pk with gsftopk, not mf!). Also, *to my
| eye*, Minion or Bembo were hardly legible on screen from 300dpi bitmaps
| rendered by pstopk, and slightly better with gsftopk (of course, these
| are not screen fonts, they are too thin at places and their slight
| slopes are a nightmare at a 15 dots or so  size...)
| 
| as I don't use ps2pk anymore, maybe someone else could provide actual
| exemples of distorted stems.
| 
| Best wishes
| Thierry