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] 3pageportrait.ps
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. Thanks. --Chi-To
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] test.pdf 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 system.
Rather I can't reproduce boxes, now I can see an unpleasant thing in the generated PDF : 24 0 obj <</Type/Encoding/Differences[ 32/.notdef]>> endobj 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] 3pageportrait-.ps 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. ***