The customer reports but I've not been able to duplicate an issue with the tiffsep device. When the convert the attached input file to tiffsep the barcode nearest the top of the image is rendered incorrectly (see attached barcode.jpg file). When converting the document to JPEG the file is rendered correctly. The command line they are using: bin/gs -sDEVICE=tiffsep -dSAFER -r300x300 -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -o test ./605649_GB_CoS_CC605-12G4_1.1.pdf
Created attachment 8119 [details] barcode.jpg
Note that the customer is using gs9.04 with the patch that fixed Bug 692378.
(In reply to comment #0) > The customer reports but I've not been able to duplicate an issue with the > tiffsep device. When the convert the attached input file to tiffsep the > barcode nearest the top of the image is rendered incorrectly (see attached > barcode.jpg file). When converting the document to JPEG the file is rendered > correctly. I can reproduce the issue very easily on a 32-bit Windows debug build. The result isn't exactly the same (in fact its worse) but its clearly the same problem.
Created attachment 8120 [details] much reduced sample file Sample file cut down to just the offending text. The file still contains a lot of junk which is not actually used. The file does *not* open correctly in Acrobat (I've no idea why but it displays blank), but does exhibit the problem in GS for me. As an additional clue, if I significantly further reduce the page size, then the problem goes away......
Created attachment 8470 [details] 692688.AR9.tif Screen capture from Acrobat 9 shows that the JPEG Marcos posted is bad. This is not a tiffsep problem. I will also post screen captures of the relevant section of output from gs png16m and tiffsep Black separation. Problem differs, probably due to the BandHeight chosen. On Windows with the supplied parameters, the png16m uses 10 lines per band and tiffsep uses 8. That this is a clist problem is supported by Ken's observation that the problem goes away if the resolution is reduced -- that will have all of the numbers in a single band (or so I presume).
Created attachment 8471 [details] 692688.png.tif Output from gswin32c to png16m (screen capture)
Created attachment 8472 [details] 692688.Black.tif Output from gswin32c to tiffsep (screen capture of Black separation).
The problem occurred due to the confluence of three conditions: 1) Glyphs are rendered with anti-aliasing (TextAlphaBits>1) 2) glyphs are painted into a transparency buffer 3) the glyphs overlap a band boundary The result is that the pdf14_copy_alpha would restart from the top of the glyph in every band. For the conditions given in the command line, the band height with the tiffsep device is 8 raster lines resulting in the 'stutter' effect observed. The 1 line fix is to adjust the start position to the correct line in the data (aa_row pointer) when adjusting the y position to the rect.p.y (and also reducing the h to reflect the lines past the rect.p.y). Yet another case where the fix is simple once the problem is understood. Fixed in commit aa9f730.
*** Bug 692759 has been marked as a duplicate of this bug. ***
It's great! Thank you, Ray! When we can wait the release with this fix included?
9.06 is scheduled for release in August (we generally do a release every six months - February and August).
(In reply to comment #12) Is there any possibility to get the beta or a nightly build of GhostScript before August?
We don't distribute builds in general (other than the release versions). I REALLY think you folks should consider building ghostscript from sources. We include a Visual Studio project file that makes it really simple. The Visual Studio Express C++ free from Microsoft can be used for 32-bit binaries. 64-bit builds requires Visual Studio Professional (at least for x64 The Express C++ can be downloaded from: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Currently Michael Vrhel is working on a SUBSTANTIAL change to the tiffsep rendering to improve performance and eliminate some other problems your company is having. If our management agrees to it, we might be able to provide Windows binaries after those changes are finished.
(In reply to comment #14) OK, I've compiled GS with Visual C++ 2008 Express Edition with SP1: http://www.microsoft.com/visualstudio/en-us/products/2008-editions/express Now the issue is gone and GS works as expected. Thank you all so much! Best regards, Delphian