Re: ps2pk vs. gsftopk

[Thierry Bouche <texadmin@puccini.ujf-grenoble.fr>]

> 
> 
> 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
3.53!
My conclusion was rather: ps2pk was better, and now worse. There are
rendering problems with ps2pk, but they are not as important as with
pre-3.53 gs(ftopk) [in this case, you had sometimes straight lines not
correctly rendered as in AGaramond's H]. After some testing, I would say
that you can see some differences at 600dpi, but they are not harmfull,
and probably, as noted bkph, it is a question of taste. But, at 300dpi
(an other cause of fuzzyness in my declarations com from the fact that I
switched from 300 to 600 dpi recently) you can see actual differences
for instance in Adobe Minion's e: the almost horizontal stem is not
rendered the same way (matter of taste...) but there misses a pixel at
the  angle that ends it on the right, the gsftopk version is more legible.

>  - 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.
> 

I gave the precise description. The problem is not in the virtual font
as the same virtual font yields perfect printing on any PS interpreter
(including gs) and is correctly treated by gsftopk. This said, I have
found the reason: I used a modified afm for padra in order to have
fontinst put the ligature ct in the place of the missing char Ng in T1
encoding (I have since this changed my mind, and modified latin.mtx/T1.etx
instead, but didn't reinitialize the afm...). 
Thus there is a mismatch between padra.pfb and padra.afm. As
gsftopk reads the tfm instead, it isn't affected, although ps2pk is (but
why?).  

However, you should try ps2pk on bakoma fonts (try at least 
some symbols such as msam10
cmsy10 and text fonts including the now obsolete dcr10) I had many
problems with it until I switched back to gsftopk (but never actual
problems in the ps file) -- maybe the problem comes also from non
standard afm files... 

As a conclusion, my question *was* a question. I would be happy if
someone could do real comparisons between bitmaps, I simply outlined my
point of vue.

Thierry