The customer reports and I've verified that Ghostscript 8.61 and head (r8477) render the attached PDF file without the text at the top of the page, both Acrobat Reader 8.0 and Apple Preview 4.0 include the text. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -sOutputFile=test.pdf ./transfu.pdf Note that Acrobat and Preview both display the missing characters as outlined with hairlines, independent of magnification.
Created attachment 3706 [details] transfu.pdf
Acrobat 5 doesn't display the text. Acrobat 8 doesn't display the text when "Smooth line art" option is off. Some of the lines in the text disappear at certain zoom and translation. This looks like an anti-aliasing artifact in Acrobat. Ghostscript doesn't have this bug even with anti-aliasing on.
The customer responds: I'd like to respond to Alex Cherepanov's comment about this being an "anti-aliasing artifact in Acrobat." The person who made the PDF *expected* to see the faint text; i wouldn't have reported this otherwise. HOWEVER, Apple's Preview program ALSO shows outlines for the "invisible" color blocks on the bottom of the page (Ghostscript only shows the entire blocks, and only with the -dNOTRANSPARENCY option). Clearly, this is a discrepancy over how to render some kind of transparency info in the PDF. Isn't "The latest Acrobat," by default, always "right?" ;-)
Note that with Acrobat 7 I see solid filled text, with 8 I see the characters with a faint outline. This is clearly a strange file. Assigning to Alex to see if he can track it down -- if it's a transparency or graphics library bug, please reassign.
Created attachment 3740 [details] simplified sample file This sample file is simplified to a single letter H drawn as a path. The file draws the letter 2 times using exactly the same path and all other graphic state parameters except the color and color space. This is clearly a rendering artifact.
AR8 with Overprint Preview option shows the same blocks as Ghostscript (on CMYK device, with -dNOTRANSPARENCY). The outlines of the blocks may be Apple Preview's issue. The real problem in Ghostscript is the conflict between transparency and overprint features. It looks like the overprint flag has no effect on transparent objects.
reassign to color group.
Evince also shows a faint outline. Michael's theory is that it's just depending on antialiasing to make these outlines. They disappear in AR around 6400% scaling. We currently turn off antialiasing when doing transparent compositing.
The simplified sample file doesn't read on the original problem. Rendering it with anti-aliasing shows a faint 'H' outline, even in 8.57: bin/gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -ofoo-aa.png Bug689657-simple.pdf
This file has overprint with transparency with spot colors. I am currently fixing issues related to this and will add this to my testing.
Making some progress on this. The file has CMYK + 6 spot colors. For some reason the alpha channel is not being properly handled in the pdf14 device even with my fixes with overprint in transparency. The seps look correct going into gx_put_blended_image_cmykspot except for the alpha channel, which is all 0 hence we get only the background in those parts. Should have something soon on this.
OK. So I spent sometime with this file. I am a bit confused about the original bug comment that came from support so I am reassiging it to support to get clarification. This file has 9 colors (CMYK plus 5 spot colors) overprint and transparency. The proper way to preview the file is to use a separation device or to view it with AR using overprint preview. The text at the top of the page is generated by drawing a path and filling with black ink. For some reason, the same path is then filled with 0% tint of one of the spot colors. Without overprint preview (or a sep device), this draws white into the same path, blowing away the old text. It is likely that for performance reasons, AR does anti-aliasing of fills that are NOT 0% tint and does NOT do anti-aliasing of fills that are white. This is the source of the halo that is seen in AR. If you turn off line-art smoothing in AR, the text will be missing when you are not doing overprint preview, just like ghostscript. That said, I am working on a patch to achieve proper seperation overprint with transparency. If that is the issue that the customer has, then I should have a fix soon. If they want to see the text halo outline (which I would be very surprised if this was the case) then that is a seperate issue, as we would need to have anti-aliasing turned on during line-art drawing and off when we do white fills.
An additional note. When I first looked at this file, I compared ghostscript's x11 and tiff24nc output with evince and Adobe Reader; the noticeable difference was the 'halo' text at the top. However, there's a lot more missing. The labels are green all the way across (not just behind the image) with white text and black barcodes, as can be seen in adobe reader with overprint preview on. I think it's likely this is the actual complaint, but the description and comment #3 only mentions the text at the top of the page. It would be good to have confirmation of what the customer's actual problem was.
Here's the text from the customer's original email: There's some "light" text (made from extremely thin outlines) that does not show up in a Ghostscript-rendered version of the attached PDF. There's a line of it at the top of the page and some more in with the rest of the graphics. If you run gs with "-dNOTRANSPARENCY", the text does show up, but it's filled in, not outlines, and other things also show up that do not in AR6.
Please see my comment 12 with respect to this thin outline. The thin outline is an artifact from viewing an overprint file without overprint preview due to a mismatch of anti-aliasing for the white fill that occurs over the black. When overprint preview is not enabled, the white fill blows away the black fill. Turning off the line art smoothing in AR and you will see that the thin line goes away since there will no longer be differences between the AA fill with the black and white. I do not believe there is a bug here.
Changing customer bugs that have been resolved more than a year ago to closed.