This PDF shows black lines in section "7" of the page. At up to 296 dpi, it looks OK. After that more and more black lines appear in the section until it completely blacks out the image at 400 dpi. Note that at higher than 400 the underlying images show through again, with black lines. For example 500 dpi. This section 7 is painted with a bunch of small 'strips' of Image data, then a rectangle filled with black. An excerpt from PDFSTEP shows: Also note that Acrobat 7 shows this section strangely -- zoomed out to fit on the screen, section 7 is almost entirely empty. As you zoom in, the data appears, then at high zoom factors the data appears to be made of separated lines. This is probably an issue of our image scaling not matching Adobe's but this is clearly a strangely constructed PDF file. This shows up on the tiffg3 and g4 devices, but also on the Windows 'display' device with or without -dDisplayFormat=16#20102. The command line used was: gs -r400 -sDEVICE=tiffg3 -o x.tif 7734.pdf
Customer bug
Created attachment 3202 [details] 7734.pdf PDF showing the strange behavior in section 7
Excerpt of relevant section of PDFSTEP output: 0 0 0 scn step # 101000 ? 110.49 410.55 528.6 0.12 re step # 101001 ? f step # 101002 ? 1 1 1 scn step # 101003 ? q step # 101004 ? 528.66 0 0 0.18 110.46003 410.520111 cm step # 101005 ? /Im620 Do step # 101006 ? %Resolving: [9 0] %Resolving: [861 0] Q step # 101007 ? where Im620 is defined in object 861 as: %Resolving: [861 0] << /Subtype /Image /Length 30 /Filter /FlateDecode /ImageMask true /BitsPerComponent 1 /Width 2937 /Height 1 /Type /XObject >> stream %FilePosition: 727512 endobj ----------- So it seems that this is being painted by filling a rectangle with black, then painting white through the image mask to erase the black areas. Surely a screwy way of doing a negative image!!! When Ghostscript fills the rectangle with black at 400 dpi, we are completely overwriting the previous image line.
Created attachment 3203 [details] 7733.pdf Another PDF that has some extra black lines at 400 dpi. Note: When Acrobat 7 paints this image to my display at the 'fit to window' scale factor of 19%, I see black lines appear, then get erased, and similar to the other 7734.pdf file, when I zoom in with Acrobat, I see white spaces in the black area (as if the image extends past the filled black rectangle).
This is not a PDF interpreter problem. A vector object marks more pixels than the image of the same size. The following program shows a black frame around the image at 400 dpi. %! <</PageSize [30 30]>>setpagedevice 10 10 moveto 10 20 lineto 20 20 lineto 20 10 lineto closepath fill 10 10 translate 10 10 scale <</ImageType 1 /Width 1 /Height 1 /DataSource <FF> /Decode [0 1] /ImageMatrix [1 0 0 1 0 0] /BitsPerComponent 8 >> image showpage
I agree that this is not a PDF interpreter problem, but rather _may_ be a problem in Ghostscript's sizing of images vs. Adobe Acrobat. Inferring from the white lines that appear at high zoom factors with Acrobat, this may be point to Acrobat making image sizes "round up" or possibly follow an 'any part of pixel' rule rather than the PS specification (as the test example in comment #5). This may also be the underlying root cause of bug 688543. The patch made to "fix" this bug caused regressions, whereas making the image larger that is painted in the transparency bbox (I am supposing) would be an alternate way to get rid of the 1 pixel wide lines that are visible with Ghostscript at certain resolutions (the location of the lines varies left, right, top, bottom with resolution). Note that Tim Osborn developed a test that fills and area with black, then paints an all white image on top that shows that CPSI and Ghostscript sometimes differ depending on the size and location of the image (difference is never more than a single pixel). This is PostScript, NOT PDF. I think that more investigation, particularly to see if Acrobat has a different image painting rule than PostScript.
I've determined that the root cause of the problem here is that our fill areas are too large, due to the fill_adjust setting being 0.5 instead of 0.25. Unfortunately, changing this causes MANY differences in the comparefiles suite that must be examined. From the 200 files that I have initially examined the changes are all trivial or progressions (i.e., we are closer to Adobe). Once the remaining differences are examined, looking carefully for dropout, the patch will be committed and the baselines will be updated. Note that the patch also fixes bug 688543 and does not require the rev 7904 change that caused regressions. Assigning to ray.johnston@artifex.com since I (or TIm) will review the remaining differences.
To further clarify, I initially tested expanding our image area to cover the pixels touched by the image. This fixed the subject files, but after examining the MANY differences, I determined that this was NOT the real problem (the fix created other problems, just as the patch 7904 did). The fill_adjust value of 0.5 adds 0.5 to BOTH edges of an object, making some of our fills/strokes bigger than Adobe's. Since Ghostscript uses a "center of pixel" filling rule, a smaller fill to either side will insure that the center of the pixel in one direction or the other will be filled, preventing dropout. This is compounded by 'fudges and hacks' at various places in the code. After the testing is completed, I will commit this change if it looks reasonable, but suggest that someone (Igor?) go through the fill/stroke fill adjust logic, analyzing for fixed precision to make sure that we are getting what we expect. NOTE: The 'tweaking' of fill_adjust for feature enhancement is STRONGLY DISCOURAGED. While we've had some success with this on many files, these test cases and the one in bug 688543 show the sensitivity of some files to variations from the Adobe rendering rules (not that Adobe doesn't have problems as well, such as the white lines seen at high zoom factors).
I'm not clear what happens here. To emulate the "any part of pixel inside" we need to set fill_adjust to 0.5 . From last comments I guess Ray wants to set 0.25 . Is it true ? Why ? Ray, have you got any proof for that, or just an imperic data from experimenting with Adobe Reader ? What's about other Adobe interpreters ? I agree that our vector objects paint more than inages due to fill_adjust. But I think it is correct behavior according to PLRM. Also I think that we don't observe it with Adobe due to trapping in rip. Thus what we need here is to emulate "trapping in the rip", which is a patented thing. Well I did a workaround for shadings, and there exists a theoretical possibility to implement same for images.
*** Bug 689519 has been marked as a duplicate of this bug. ***
I doubt that 'trapping' is being used in the Adobe Reader to viewing to the display, which is what is being used as the reference. In-rip trapping usually is only implemented (with specific trap zone control) for printers that have several differnt inks that may be mis-aligned, and usually is implemented so that 'spread' only occurs when there are two adjacent regions filled with (nearly saturated) *different* inks. Then the one of the inks is 'spread' to prevent a sliver of white. These examples are totally black and white images (also see 689519) and the problem is that the Adobe implementations manages to make the fill area small enough that it does not overwrite an area written by a previous 'imagemask' operation. Ghostscript is writing a larger black 'fill' area (or at least one that overwrites "behind" the progressive fill/imagemask sequences and thus leaves black lines "behind" the sequence (depending on the resolution and the coordinates for the operations). I defer to Igor to dig into this. This was created by a Windows app, using PSCRIPT5.DLL to Adobe Distiller, so the issue is not likely to go away by asking the creator to "change the way they create the PDF".
Regarding Comment #1 "I doubt that 'trapping' is being used in the Adobe Reader to viewing to the display" : The file comparefiles/gradmesh.ai defines tensor patches with 1/2 pixel gaps between them, but Acrobat renders it with no dropouts. I believe it's a trapping. One zone may be installed by default across entire page.
Thank you, Igor, for the information that leads you to suspect that AR is doing trapping on gradmesh.ai. This _might_ be the case, or it might be some other type of detailed action of the AR filling. Not withstanding the possible use of trapping by AR, the black fill and white overpaint through an imagemask is not actually a candidate region (zone) for trapping since trapping occurs between adjacent non-white areas, expanding one or both to overlap so that unintended offsets between inks do not result in white 'slivers' (I mentioned this in my comment #11, but that may not have been clear). This remains an open customer issue with several files that use similar methods to paint an 'inverse' image.
Created attachment 3757 [details] CPSI.zip Attaching a raster of 7734.pdf made with CPSI 3010.105 at 300 dpi. It demonstrates same problem as Ghostscript.
I believe that Ghostscript and CPSI 105 correctly renders the document, but the document is not well designed for rendering at high resolution. From Comment 3 one can see that it renders a black rectangle within Y=[110.46003, 110.64003] and a white image over it within [110.49, 110.61]. With 300 dpi it gives a 0.5 pixel height for black, and 0.18 pixel height for white. The first is rendered with "aany part of pixel inside" and always give a 1 pixel covered. It is not clear what filling rule to be applied to images, but from CPSI output ine can conclude that it is "center pixel inside" because each 3d line appears unpaunted. Adobe Acrobat 8 renders it with 'linear' artifacts with zoom=1200% and near it, which on my display (which has 200dpi resolution) appears close to 600 dpi CPSI raster, and the artifacts depend on "smooth line art" and "smooth images" options.
Created attachment 3758 [details] Acrobat8.zip A rendering to display with Acrobat 8 with 1200% zoom.
I think Ray should re-test it with a newer CPSI and close as invalid if same result is obtained. Passing to Ray.
Per request I'm retesting this customer's bugs: this one still occurs with r8596.
I confirmed that this file also has black lines when rendered using a newer CPSI (3017.102). Attaching the output from that CPSI for file 7734.pdf I guess there isn't really any solution to this that doesn't make Ghostscript incompatible with Adobe.
Created attachment 4019 [details] 7734_from_CPSI.pdf This PDF file is actually a single image in a PDF wrapper. The image was rendered at 600 dpi by CPSI.
*** Bug 689932 has been marked as a duplicate of this bug. ***