Tried to render the following PDF http://kaiser-edv.de/tmp/c90UgX/GS-Bug-8Rich.pdf with GS 9 (GPL Ghostscript 9.00 (2010-09-14) with the following command line: gs -dUseTrimBox -q -dBATCH -dNOPAUSE -r150 -sDEVICE=tiff32nc -dDOINTERPOLATE -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxBitmap=100000000 -dNumRenderingThreads=2 -dMaxPatternBitmap=2000000 -sOutputFile=ghostscript.tif -c 100000000 setvmthreshold -f GS-Bug-8Rich.pdf As one can see in the comparison image (upper rendering result from GS 9, lower from MacOS X' CoreGraphics -- Acrobat result looks similar) http://kaiser-edv.de/tmp/c90UgX/GS-Rendering-Bug-8.png the gray line surrounding the text disappears nearly on the right side and totally in the lower right corner. This comparison has been renderer at 200 ppi. With 150 ppi or below the line disappears completely. Similar effects (ugly rendering) occur with the circle around the dishwasher's display and the arrow on the right ("Display digital"). As well as the frame around the yellow box on the right. No visible anti-aliasing effect at all. GS rendering results as well as CoreGraphics' are available here: http://kaiser-edv.de/tmp/c90UgX/
As is so common when files are not attached to the bug report, the URL no longer works and the source file is therefore no longer available. So we can't work on the problem.
Sorry Ken, try to get the files from my archive and will assign them to the bug.
If you can find the source file, please do attach it and reopen the bug
Created attachment 9947 [details] source PDF
Created attachment 9948 [details] Rendering result The upper result is from GS9, the lower from OS X' CoreGraphics render engine
Created attachment 9949 [details] CoreGraphic's rendering result
Created attachment 9950 [details] GhostScript rendering without interpolation
Created attachment 9951 [details] GhostScript rendering with interpolation/antialiasing
Created attachment 9952 [details] Tiff of the acrobat display I have a sneaky suspicion this is not an interpolation problem at all. The 'line' being referred to looks like its part of an image, examining both the interpolated and non-interpolated images shows that the line has 'disappeared' in the same places. I suspect that the problem is simply one of resolution. The image is probably quite high resolution, well above that being rendered (150 dpi), and so the image is first downscaled. Image downsampling is fairly crude in PostScript, because its intended to run on printers, and the result is taht fine details can be lost. If these fine details are lost *before* the anti-aliasing is applied, then they remain lost. As a counter example, the same file, opened in Acrobat X, default zoom (142% on my computer) the *top* grey line in the same area has vanished. At 186% the top line is present but the bottom vanishes, and the right edge shows the same same 'partial' rendering as the Ghostscript display. I've attached the result above, please ignore the odd block of colour in the image, these are due to an incompatibility in the screen capture software with Windows 7.
Created attachment 9953 [details] Screenshot from Illustrator Ken, while this might explain some other effects I've seen when comparing render results from different engines this might not apply to this case. The object in question looks to me like a polygon filled with a smooth shade. Acrobat's preflight show that other graphical elements like the circle around the diswasher's display or the arrow right of it are in fact lines filled with smooth shades. Regarding the "first downscale then apply antialiasing approach" for images I have to think about potential consequences if GhostScript really works this way. But in this case it shouldn't matter since I believe we're talking about filled vectors.
In fact the actual problem seems to be the way this page is created. The line is a complex construction primarily consisting of two paths. The paths are used to clip the drawing to a small area, and then a number of shadings are used to fill the area. The area is quite narrow, less than one PostScript unit in some places. At 150 dpi one PostScript unit is 2 pixels, it looks to me like the problem is simply that the area left after clipping is applied degenerates to nothing, when the resolution is sufficiently low. The only solution to this is to render the file at a sufficiently high resolution, so that there is actually some gap between the 2 paths (when converted from user space to device space). Anti-aliasing doesn't work in this case. Normally I would suggest using one of the tiffscaled devices (I've tested tiffscaled24 and it works well), but we don't have a CMYK one I don't think. Thomas, I'm sorry but my internet crashed while I was writing this update, which is why my previous comment doesn't match your observation, it took me a while to get this comment to update.
A tiffscaled32 device would be nice, since we have a tiff32 device. Robin says he will code such a beast, and I've assigned this one to him accordingly
Thanks for your response and explanations. So it seems like the CoreGraphics PDF renderer (we used prior to GhostScript) works the same way as the tiffscaled* devices in GhostScript, rendering at a higher resolution and scaling down in a second step to produce a smooth result... A tiffscaled32 device would be great. The docs mention error diffusion (why that) but not the downscaling algorithm. I assume you use Bicubic downsampling? BTW: The "bug" can be closed since it's mainly an issue of wrong parametrization
(In reply to comment #13) > A tiffscaled32 device would be great. The docs mention error diffusion (why > that) but not the downscaling algorithm. I assume you use Bicubic > downsampling? I think the image downsampling is 'nearest neighbour' but I'm not certain. > BTW: The "bug" can be closed since it's mainly an issue of wrong > parametrization Ah, we want to leave it open so Robin doesn't forget ;-)
Hmm 'nearest neighbour' seems for the specific purpose of antialiasing the wrong choice (it's fast but the results will look somewhat pixelated). Maybe Robin can comment on that when he starts to touch the code :-)
(In reply to comment #13) > A tiffscaled32 device would be great. The docs mention error diffusion (why > that) but not the downscaling algorithm. The initial tiffscaled device was written to go from greyscale rendering to monochrome (1bpp) - hence error diffusion was vital. For 8bpp per component operation, we don't bother with error diffusion. > I assume you use Bicubic downsampling? No. We downsample by integer factors (normally), so bicubic operation would be pointless. In a typical example we might render at 600dpi, and downscale to 200dpi; thus 3x3 groups of pixels are collated together to give 1 output pixel. Any form of filtering would serve only to blur the output.
Thanx Robin for the explanation. I was confused by the documentation. When explaining the -dDownScaleFactor switch it says "the following will produce a 200dpi output png from a 300dpi internal rendering" http://ghostscript.com/doc/current/Devices.htm (now I know it's a typo and should read '600dpi' instead of '300dpi'). Same applies to my question about error diffusion and other colorspaces than bilevel. The docs could be a little bit more precise :-)
(In reply to comment #17) > Thanx Robin for the explanation. I was confused by the documentation. When > explaining the -dDownScaleFactor switch it says "the following will produce > a 200dpi output png from a 300dpi internal rendering" > http://ghostscript.com/doc/current/Devices.htm That's a typo, yes, and I will fix it. It looks to me to only appear in the documentation for the pngmonod device though, not the tiff ones? Have I missed it? > (now I know it's a typo and should read '600dpi' instead of '300dpi'). Same > applies to my question about error diffusion and other colorspaces than > bilevel. The docs could be a little bit more precise :-) The docs read OK to me: : The tiffscaled device renders internally at the specified resolution to an : 8 bit greyscale image. This is then scaled down by an integer scale factor : (set by -dDownScaleFactor= described below) and then error diffused to give : 1bpp output. and : The tiffscaled8 device renders internally at the specified resolution to an : 8 bit greyscale image. This is then scaled down by an integer scale factor : (set by -dDownScaleFactor= described below) and then error diffused to give : 8bpp output (error diffusion at this stage is probably pointless and may : be removed in future versions). Can you be more precise about my lack of precision please? :)
Fixed with the addition of tiffscaled32 in: commit e209e22862bd7af4362e08f1aa8f0025341356f0 Author: Robin Watts <robin.watts@artifex.com> Date: Tue Jun 11 18:51:18 2013 +0100 Add tiffscaled32 device (32bpp CMYK output with downscaling) Update documentation. Let us know how you get on. Thanks!
(In reply to comment #18) > (In reply to comment #17) > > Thanx Robin for the explanation. I was confused by the documentation. When > > explaining the -dDownScaleFactor switch it says "the following will produce > > a 200dpi output png from a 300dpi internal rendering" > > http://ghostscript.com/doc/current/Devices.htm > > That's a typo, yes, and I will fix it. It looks to me to only appear in the > documentation for the pngmonod device though, not the tiff ones? Have I > missed it? Yes, it's in the PNG section (I just searched inside the Devices.htm for the first occurende of '-dDownScaleFactor'). > > (now I know it's a typo and should read '600dpi' instead of '300dpi'). Same > > applies to my question about error diffusion and other colorspaces than > > bilevel. The docs could be a little bit more precise :-) > > The docs read OK to me: > > : The tiffscaled device renders internally at the specified resolution to an > : 8 bit greyscale image. This is then scaled down by an integer scale factor > : (set by -dDownScaleFactor= described below) and then error diffused to give > : 1bpp output. > > and > > : The tiffscaled8 device renders internally at the specified resolution to an > : 8 bit greyscale image. This is then scaled down by an integer scale factor > : (set by -dDownScaleFactor= described below) and then error diffused to give > : 8bpp output (error diffusion at this stage is probably pointless and may > : be removed in future versions). > > Can you be more precise about my lack of precision please? :) I referred to "then error diffused to give 8bpp output (error diffusion at this stage is probably pointless and may be removed in future versions)" which you removed now for 8bpp/24bpp. So everything's alright. Hmm... one final question: In the 'tiffsep' section is written: '2 additional "special" ratios are available, 32 and 34. 32 provides a 3:2 downscale (so from 300 to 200 dpi, say). 34 produces a 3:4 upscale (so from 300 to 400 dpi, say)'. Which down-/upscale algorithm is used in these special cases? Thx -- especially for providing the new CMYK device. I will test it next week. Right now too busy (and the customer in question switched in the meantime to the PDF renderer in Callas' pdfToolbox server -- based on Adobe's PDF library AFAIK)
(In reply to comment #20) > Hmm... one final question: In the 'tiffsep' section is written: '2 > additional "special" ratios are available, 32 and 34. 32 provides a 3:2 > downscale (so from 300 to 200 dpi, say). 34 produces a 3:4 upscale (so from > 300 to 400 dpi, say)'. Which down-/upscale algorithm is used in these > special cases? Those are only available for the tiffsep devices, not for the tiffscaled devices (hence them being documented in that specific section). (More specifically, these are implemented for devices that use planar format internally). Off the top of my head: 3:2 +---+---+---+ | A | B | C | +---+---+ a = (4A+2B+2D+E)/9 +---+---+---+ | a | b | b = (4C+2B+2F+E)/9 | D | E | F | -> +---+---+ c = (4G+2H+2D+E)/9 +---+---+---+ | c | d | d = (4I+2H+2F+E)/9 | G | H | I | +---+---+ +---+---+---+ And 3:4 +---+---+---+---+ +---+---+---+ | A | a | b | C | a = (A+2B)/3 | A | B | C | +---+---+---+---+ c = (A+2D)/3 +---+---+---+ | c | d | e | f | d = (A+2B+2D+4E)/9 | D | E | F | -> +---+---+---+---+ (And the rest by symmetry) +---+---+---+ | g | h | i | j | | G | H | I | +---+---+---+---+ +---+---+---+ | H | k | l | I | +---+---+---+---+