Re: ps2pk vs. gsftopk

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

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

An AFM file describes the metrics of the corresponding type1 font.
Changing this AFM file is not allowed unless you also adapt the type1
font accordingly. And you have to keep in mind that the PS file derived
>From PK fonts should have exactly the same layout as if type1 fonts
were used (dvips currently does not have features to cope with
individual character scaling).

When ps2pk renders a type1 font it uses the metrics from the AFM file
allowing some slanting and extension (when the psfonts.map does ask for
it). As a consequence the TFM file describing the type1 font should not
change character widths on an individual basis.  To garantee that PK
fonts derived from  AFM + type1 fonts match with the corresponding TFM
the checksums of PK and TFM should match. These checksums are derived
>From the widths of all characters specified by the encoding vector and
should therefore not be ignored when they differ.

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

I would like to ask you to describe the problem here. I don't plan to
use the bakoma fonts in the short term.

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

What do you mean with `real comparisions between bitmaps'? I can
imagine that somebody organises a blind test between several type1
fonts using ps2pk, gsftopk, ATM and Display PostScript at a resolution
of 600 DPI.

--Piet