Hello, This is Rahul Sabnis, member of Hewlette-Packard R&D team for HPOS. Our product (HP Output Server or HPOS) uses GhostScript for few document transformations; Postscript->PDF, Postsript->PCL, etc. We have observed a problem in PS to PDF transformation. We suspect this may be there for other transformations also. Here is what we see: In one of the scenarios HPOS transforms the input Unicode Postcript(PS) document to PDF and emails the output document as an attachment to the recipient specified by user. Output PDF is Base64 encoded by HPOS before it is passed to mail program. The mail program can be also configured by user. By default on UNIX sendmail is used as mail program and on Windows minimail is used. Recently we have upgraded from Ghostscript version 8.54 to 8.71. After upgrade we see that the attached document is not correct. But the same worked fine for 8.54. Also I could see that the output document opens fine but has problem only when sent as an attachment to email and try to open from email client. Since the Base64 encoding is done by our product (HPOS), I wanted to isolate whether it is issue with GS output PDF or with HPOS. For this I used the "base64" command (on Linux) to generate Base64 encoded output for the GS output PDF document. This encoded output was sent as an attachment to sendmail. With this also I could see exactly same problem when I opened the document from the email client. When I do the same with GS 8.54 it works fine. From this my conclusion is that there is some problem with the output PDF document generated through GS. Another observation I had was that there is difference in the output PDF file generated with 8.71 and 8.54 although the input PS document is same. Questions which I have: 1) Is the size difference in 8.54 and 8.71 expected ? 2) What is causing this difference and could this issue be because of differences in output file size between 8.54 & 8.71 or are are we missing something in our testing ? I am uploading below files to the FTP location I created (details below): 1) commands.txt => Has all commands I used for testing 2) 871.tar.gz 3) 854.tar.gz 871.tar.gz & 854.tar.gz includes below files: --------------------------------------------- - temp.ps => Input Postscript document - out.pdf => Output PDF document - base64_out => Base64 encoding of out.pdf - attachment_constructed => Attachment prepared using base64_out - mail_example => Example Mail sent from HPOS - mail_with_attachment_constructed => Mail sent using attachment_constructed - FONTS.tar.gz, PS.tar.gz & Resource.tar.gz These tests were done on Linux but we suspect this will exist on all platforms and that is why the case is logged for all. And resolution would be required for all platforms. Could you please give us response ASAP as it is critical escalation for our customer ? Details of the FTP location: ========================================================= FTP System: ftp.usa.hp.com (15.192.32.78) Login: art_gs Password: T3stM3N0 (NOTE: CASE-sensitive) FTP Access: ftp://art_gs:T3stM3N0@ftp.usa.hp.com/ or: ftp://art_gs:T3stM3N0@15.192.32.78/ HTTPS Access: https://ftp.usa.hp.com/hprc ========================================================= Let me know if you need any further clarifications/information from me. Thanks, Rahul.
> Recently we have upgraded from Ghostscript version 8.54 to 8.71. After upgrade > we see that the attached document is not correct. But the same worked fine for > 8.54. Also I could see that the output document opens fine but has problem only > when sent as an attachment to email and try to open from email client. Then this seems pretty clearly a problem with the transmission method, not Ghostscript. > Since the Base64 encoding is done by our product (HPOS), I wanted to isolate > whether it is issue with GS output PDF or with HPOS. For this I used the > "base64" command (on Linux) to generate Base64 encoded output for the GS output > PDF document. This encoded output was sent as an attachment to sendmail. With > this also I could see exactly same problem when I opened the document from the > email client. When I do the same with GS 8.54 it works fine. From this my > conclusion is that there is some problem with the output PDF document generated > through GS. I fail to see any reason why this is the case. A working document is transformed and transmitted by email, then (presumably) transformed back again. The document no longer works. This is pretty obviously a problem with the transformation. > Questions which I have: > 1) Is the size difference in 8.54 and 8.71 expected ? Bugs have been fixed, features have been added. Differences are to be expected. > 2) What is causing this difference and could this issue be because of > differences in output file size between 8.54 & 8.71 or are are we missing > something in our testing ? I don't know. > I am uploading below files to the FTP location I created (details below): Please attach any required files to reproduce a problem in Ghostscript to the relevant bug report. > Details of the FTP location: > ========================================================= > FTP System: ftp.usa.hp.com (15.192.32.78) > Login: art_gs > Password: T3stM3N0 (NOTE: CASE-sensitive) You should probably change this password, since you have posted it to a public forum.
Same procedure is carried out for same input document on the same machine using Ghostscript 8.54 i.e. transform PS->PDF using ghostscript and send the output document as as attachment to email. This works fine but it shows problem for Ghostscript 8.71. I have uploaded all the files generated during my testing including the input file to FTP site. I had the FTP site created as there were many files. Will you be able to download or should I attach to the case ?
(In reply to comment #2) > Same procedure is carried out for same input document on the same machine using > Ghostscript 8.54 i.e. transform PS->PDF using ghostscript and send the output > document as as attachment to email. This works fine but it shows problem for > Ghostscript 8.71. But I do not see why this makes it a Ghostscript problem. The file is OK before mail transmission and not after, this points the finger at the transmission method. The fact that the file content is different seems to me to be irrelevant. Have you binary compared the files before and after transmission ? Are they the same ? If not then you can see immediately where the problem lies. > I have uploaded all the files generated during my testing including the input > file to FTP site. I had the FTP site created as there were many files. Will you > be able to download or should I attach to the case ? The only file of interest is the input PostScript file. You should ideally create an example file which is as simple as possible and does not rely on external fonts. The larger and more complex the file the longer the issue will take to investigate. If you are a commercial Artifex customer please quote your customer number. If you are not an Artifex commercial customer then this is unlikely to get any attention unless you can reproduce it on a reasonably modern version of Ghostscript. 8.71 is out of support now even for commercial customers. We do not have access to your mail system, and so cannot test the round-trip you are using here. You must reproduce the problem in a way that we can mimic or we will be unable to investigate the problem at all.
No evidence this is a GS bug, reducing severity to normal.
this one got me curious. in the 871.tar.gz, the pdf from mail_with_attachment_constructed matches out.pdf exactly, whereas the one from mail_example does not. But the only differences are dates, document ids and the like. poppler’s pdffonts, when run on either of those pdfs, complains: Error: Unknown character collection 'Adobe-Unicode' The commands.txt file seems to have a typo in the 871 section: the 854 section includes: -dSUBSTFONT=/AndaleMonoWTG -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 but 871 says: -dSUBSTFONT=//home/rahul/cert/rahul.pfx/lib/PS -dDEVICEWIDTHPOINTS=AndaleMonoWTG -dDEVICEHEIGHTPOINTS=612 -dPDFSETTINGS=/792 utf-8
I figured out that the problem was with the PDF viewer we were using and nothing to do with the output document. When we opened the document with the upgraded viewer everything seems to be fine. You can close this one. Thanks for you help.