trunk 6706 and 8.53 . ijs device print all black with processingcolormodel=devicegray. (epson epl only does devicegray, and HP color 3550 ijs device can accept either devicegray or devicergb). The pdf is as in bug 688652 (bug 688652 was found while looking into this problem): http://bugs.ghostscript.com/attachment.cgi?id=2155&action=view -sProcessColorModel=DeviceGray -dBitsPerSample=1 - all black -sProcessColorModel=DeviceGray -dBitsPerSample=8 - all black -sProcessColorModel=DeviceRGB -dBitsPerSample=8 - alright not sure if it is related to either bug 686921 or bug 677383.
Created attachment 2156 [details] another pdf from the same source, which doesn't trigger the problem Here is another pdf from the same source, for reference, which does not trigger the problem; the one difference I can see is less colorspace information inside the pdf.
Tried 32-bit GNU Ghostscript 7.07 on x86 linux and 64-bit ESP Ghostscript 815.01 (2005-09-22) on opteron and both of them work correctly, and 32-bit AFPL 8.53 on opteron doesn't. Am going back to AFPL 8.14 and try to track down the change between 8.14 and current that caused the black page. More later.
Regressed through past versions and found the the fix of bug 688113 broke the ijs driver between 8.51 and 8.52. I am not sure why fixing pdf transparency in bug 688113 requires modifying and breaking the ijs driver, but I found I could get the desirable ijs behavior by inserting one line like this: ========================= --- src/gdevijs.c.orig 2006-05-01 03:27:48.000000000 +0100 +++ src/gdevijs.c 2006-05-01 05:01:22.000000000 +0100 @@ -522,6 +522,7 @@ code = gdev_prn_maybe_realloc_memory((gx_device_printer *)ijsdev, &ijsdev->space_params, width, height, ijsdev->page_uses_transparency); + ijsdev->page_uses_transparency = true; ijsdev->is_open = save_is_open; return code; } ========================== Please review and comment.
Hin-Tak, I am unable to reproduce this problem. I am running under WinXP. My command line is: bin/gswin32c -sDEVICE=ijs -sIjsServer=ijs/ijs_server_example.exe - dProcessColorModel=/DeviceGray -dBATCH -dNOPAUSE -sOutputFile=out.ps - dBitsPerSample=1 ../test_files/688652.pdf -c quit
Dan: Thanks for spending time on this. Indeed, ijs_server_example doesn't seem to have this problem, so I'll have to look into why ijs_server_epsonepl have differently and is sensitive to that transparency change.
Hin-Tak, If you can send me a copy of an ijs server that works on WinXP and shows the problem, then I will look at it.
Dan: okay, I'll try making such an executable. Thanks.
Created attachment 2220 [details] win32 ijs_server binary, and other files to reproduce the problem zip file, containing everything to reproduce the problem: (1) ijs_server_epsonepl.exe win32 binary, and srcs to rebuild if needed (sorry it has too much unix-ism and need gcc/mingw to build - just type "mingw32-make" to rebuild) (2) 688652.pdf (same file as in attachement of bug 688652) (3) ijs_exec_win.c.diff, to patch ghostscript's ijs client code (see bug 688714) if debugging a non-MSVC built ghostscript. (4) for reference, {814,850,852,853}.spl , output generated with "C:/Program Files/gs/gs8.53/bin/gswin32c.exe" -sDEVICE=ijs \ -sIjsServer=ijs_server_epsonepl.exe -dProcessColorModel=/DeviceGray \ -dBATCH -dNOPAUSE -sOutputFile=853.spl \ -dBitsPerSample=1 -sDeviceModel=EPL5700L 688652.pdf -c quit and same with other versions of gs, using official binaries. I can't generate an output with the official gs 851 binary, so I suspect that it might have been compiled with borland or non-VC and is affected by bug 688714 . A completely black outcome is about 11k; a correct one is about 500k - 700k (depends on half-toning in ghostscript which seems to have changed from time to time, and paper size), so it should be quite noticeable even without under standing how the ijs server works, and the code is based on ijs_server_example. FYI - in this driver, a completely black outcome is about the same size as a completely white one, but a few hundred bytes bigger. (the compression algrithm is somewhat similiar in principle to tiff ccitt g4).
Been chatting and bouncing ideas with Dan on IRC and just managed with reproduce the bug with ijs_server_example, by specifying -r300x300 (default is 72 for ijs_server_example, but 600x600 for ijs_server_epsonepl). So it seems to be a raster-size related problem.
Unsure who should own this problem.
Marcos to re-test
Re-tested on linux with svn9372 (current svn head) with both ijs_server_example and ijs_server_epsonepl. The problem seems to have gone away in the 2.5 years since it was filed.