[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ps2pk vs. gsftopk
Well, sorry if you felt my mail aggressive, it was not meant so.
In fact, I am an end user somewhat involved in typography. What I say is
only my feeling , with my eyes.
I used formerly gsftopk, and was quite happy with it, later on I tried
ps2pk & was impressed by its quickness & lightness in memory, so used it
by default. At this time (gs 3.13-3.51) I found quality comparable, but
gs had some actual problems with hints: for instance, the horizontal
stem of H in AGaramond or the slightly slanted stems like e in Minion
were not rendered correctly with gs. A bug was found by P.D. at this
time, and he included the patches in version 3.53. All the above
mentionnend problems disappeared. I have thus switched back to gsftopk.
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.
> > Of course, if you never download bitmaps, ps2pk is faster and consumes
> > less memory, but you are sometimes disturbed by distorted stems.
> As we (!) have the code of the rasterizer we could try to solve this
> problem. But first you need to make an exact description of the problem
> you mention here. Can you make your claims about the lack of quality of
> different renderers (ghostscript, ps2pk, ATM) vissible?
> Changes made to the type1 rasterizer for ps2pk are mostly bugfixes and
> some generalizations needed to cope with slanting, extending and
> reencoding. And I try to keep up with improvements made by the
> X-consortium people (and vice/versa).