[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ps2pk vs. gsftopk

> This is a good opportunity for me to confirm that I have used all sorts
> of non-standard encoding vectors, including one that I am making up
> for polytonic accented Greek, with really loooooonng names.  
> /omegaasperperispomeneisub
> and the like.  I have never had any problem with any encoding vector
> that was acceptable to the PostScript system.  ps2pk has taken them
> all so far.  

As far as I understand (so very near :-) some encoding vectors contain
postscript code that are beyond T1 specifications. It seems to be the
case with Bakoma fonts because they use TeX's native  encoding thus put
charachters at `control slots' which would make them unusable under
windows but use a trick to duplicate these at a place windows can see it:

dup dup 161 10 getinterval 0 exch putinterval dup dup 173 23 getinterval
10 exch
 putinterval dup dup 127 exch 196 get put readonly def

If you rasterize with 	a full PS interpreter like gs handy, or if you
print, you won't see the problem, but ATM or ps2pk seem to be killed by
these. (I guess I have not too much deformed bkph's entry on this). For
instance I tried to view the outlines of bakoma fonts with Type
Designer, but it could not load the fonts.

This is also a good opportunity for me to ask you if you have type1 
polytonic accented Greek fonts !? as I used a few weeks ago the ibygreek
fonts/packages but had problems compiling them with mf (very strange
problem indeed as I use exactly the same sources (from teTeX) under
solaris and linux, and the mf code compiled fine under sunos but yielded
a `incomplete if at line 6' error under linux !$?). BTW I updated the
nfss stuff from ibygreek I found on ctan for latex2e, if you're interested.

> Secondly, I have absolutely no complaints with ps2pk handling of
> t1 rasterization.  I use it only for the screen, where in xdvi it
> gives images of very satisfactory clarity.  It is entirely possible
> that I am using ghostscript in an inadequately sophisticated way, but
> if I take a text in timesroman and display it at near normal size in
> xdvi using ps2pk, I can actually read the contents.  If I pass the
> same text through dvips and read it in a gs display, I can read
> no more than half the content, and that only when I have a pretty 
> good idea what it is going to say. 

This is absolutely true but gs window is smaller, if you use ghostview
at magstep 2 or 3 you achieve a very similar quality (you do use the
magnifying glass tool / shrink buttons in xdvi, do you?). but xdvi is
much faster. A current reason of insatisfaction with gs comes also from
the fact that many people seem to use the `gsf' versions of Times Roman,
not the pfb/a. (but then what do they use with ps2pk?).

> I don't know whether that is more a tribute to the ps2pk rasterizing
> engine or to xdvi itself, but I like the combination.  
> Maybe gsftopk fonts look better in xdvi than in gs.  There was a

yes. I don't know why, but shrunken bitmaps look better in xdvi than
100dpi bitmaps in gs. This said, the citation from P Deutsch seems to
imply that bitmaps are device-dependant in gs as in mf (as anti-aliasing
requires a color device) so my initial question still holds: am I sure
that the bitmaps generated with gsftopk will be as good as the ones
gs would actually print on some device? -- or is it possible to achieve


PS bitmaps comparisons should be made at low resolution such as 100 or

PPS I don't know if the guy who had problems with overstrike charachters
is listening this   thread, but I noticed they almost disappear if you
don't use the xdvi*grey: true mode.