Customer reports that after distilling the attached ps file, the resulting pdf
displays fine in Ghostscript, but spaces are replaced by boxes in Acrobat Reader
6.0.1 on Windows. I've confirmed in 6.0.0 on Windows as well, but 6.0.1 on Mac
OS X seems to display the file correctly.
Created attachment 587 [details]
Can't reproduce with Adobe reader 6.0.0, 6.0.1 and the current HEAD.
Likely it's a duplicate of the Bug 687351, which was fixed 10 days ago.
I've downloaded the src from HEAD, and built it and is still seeing the problem
with Adobe Reader 6.0.1 on Windows 2000.
I wonder if the fonts set I have been using is one of the factor. BTW we are
using fonts from soft horizons.
Anyhow here is how I have been invoking gs.
gs -q -dDEBUG -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -I../fonts/Soft_Horizons -
I../lib -sOutputFile=test.pdf 3pageportrait.ps
Please let me know if I am doing something wrong.
Please give me an URL for Soft Horizons fonts, exactly the version you're using.
Also please attach the PDF created with GS in your environment.
Created attachment 609 [details]
Attaching a PDF created by the user. It displays fine. Thus the problem is not
related to Ghostscript, something is wrong in the user's system. I intend to
close the bug.
No responce from the user.
I guess this issue is either an user error or a non-Ghostscript problem in his
Rather I can't reproduce boxes, now I can see an unpleasant thing in the
generated PDF :
24 0 obj
With some viewers/fonts it may cause boxes instead spaces. Likely the user's
system implements .notdef as a box, and my one as a space.
Created attachment 615 [details]
Attaching a reduced test, which reproduces the problem.
Pay attention to the line
CharCol256Encoding 32 get =
It prints .notdef .
Thus the problem is caused by Adobe's Pscript.dll Version 5.0 bug, which puts
/.notdef instead /space . There is no Ghostscript bug. The problem to be
reported to Adobe.
Adobe Distiller replaces the buggy encoding with WinAnsiEncoding. It looks as a
special workaround for the buggy CharCol256Encoding. Once again we can see that
Adobe products are bug to bug compatible. We could provide a workaround
specific to CharCol256Encoding. Customers are welcome with a NRE proposal.
I also recommed the customer to analyze where the CharCol256Encoding encoding
comes from, and how to configure his system with a better encoding.
I close this bug as invalid, because it doesn't need more engineering effort
unless the customer orders a special workaround for it.
*** Bug 688315 has been marked as a duplicate of this bug. ***