Bug 691218

Summary:	pdf with shading is missing parts when run through ps2pdf and viewed with gs
Product:	Ghostscript	Reporter:	William Bader <williambader>
Component:	Images	Assignee:	Ken Sharp <ken.sharp>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ken.sharp
Priority:	P4
Version:	8.71
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---
Attachments:	the original pdf output of ps2pdf with the missing banner when viewed with gs

Description William Bader 2010-03-26 04:37:15 UTC

I am using gs 8.71 on Fedora 8 Linux.
I have a pdf file with shading that some pdf viewers don't handle right.
gs displays it correctly, but when I run it through ps2pdf and view the result with gs, the "customer appreciation" banner at the top is a white hole.
The ps2pdf output looks correct with xpdf, so the problem might be viewing in gs rather than the pdf writer.
William
williambader@hotmail.com

Comment 1 William Bader 2010-03-26 04:40:49 UTC

Created attachment 6130 [details]
the original pdf

Comment 2 William Bader 2010-03-26 04:42:26 UTC

Created attachment 6131 [details]
output of ps2pdf with the missing banner when viewed with gs

Comment 3 Ken Sharp 2010-03-26 08:06:54 UTC

Acrobat 9 doesn't display the 'text' either. I doubt this is anything to do with shadings, the text appears to be image data overlaid on a white softmask and is therefore most likely a transparency issue.

IIRC xpdf has problems with transparency, so I suspect that it is xpdf in error, not GS. Which means the problem is something to do with pdfwrite.

A simpler sample file would help if possible, it will take some time to reduce this one to a workable size.

Comment 4 William Bader 2010-03-26 14:55:42 UTC

I'm sorry that I don't have a simpler file.  I was sent this file in May 2009 because it didn't work in an application, and the problem was with how pdftops from xpdf handled shading.  I just tested with pdftops from a poppler snapshot from Jan 12, 2010, and the ps generated from either of the pdf files looks correct in gs.
I have been testing pdf compression tools like http://code.google.com/p/pdfsizeopt/ I gathered a bunch of old test files, and I noticed the problem with this file.

Comment 5 Ken Sharp 2010-09-27 12:28:55 UTC

This appears to have been fixed sometime in the last 6 months, almost certainly as a result of Michael's hard work on transparency.

I'm afraid I don't have a revision number where it was resolved, but I believe the 9.0 release should work correctly with this file.

Comment 6 William Bader 2010-09-30 22:58:11 UTC

I confirmed that it works with gs9.00.

The only problem is that if I run the resulting pdf through pdftops from poppler, I get a bunch of messages "Error: Illegal entry in bfrange block in ToUnicode CMap" because a character table has 16 bits but has ranges like <45> <46>, while poppler expects that a 16 bit range should have numbers with four digits like <0045> <0046>.  The test is around line 300 of poppler/CharCodeToUnicode.cc.  I suspect that gs is right, and poppler needs a small change.

William