Although the core dump and preview bugs of ps2epsi (e.g., 686909) have been fixed in gs 8.14, there are ps files which fail in the preview part, outputting the message "blank page!!". The resulting epsi file then lacks the whole initial part up to (and including) the %%EndPreview line. The first example I found contained nothing but several equal lines of red text, made by xfig. Manually editing this and other files, I found that the bug occurs whenever all parts of the image have a "red" component equal to 1 (the green and blue values are unimportant): these are treated as "white" in the bitmap. If other colors are present (which prevent total failure), the BoundingBox may be too small, if such "red=1" colors were present near the margin. Thus the color quantization of the preview bitmap seems to be the reason.
The bug is not due to the color quantization but to the color-to-gray conversion. Closer inspection of the preview bitmap shows that the gray value is simply formed from the red-component value alone, completely neglecting the green and blue components. It would not help to use "bg" and "bb" in addition to "br" for a better gray estimate in src/gdevmem.c, mem_mapped_map_rgb_color(), "Gray scale conversion", since bg and bb have no reasonable values there. Obviously, the color-to-gray conversion happens somewhere before the call to mem_mapped_map_rgb_color(). When the lib/ps2epsi.ps from gs8.14 is used with gs7.04, it works correctly!
Please attach the sample files that you are trying to convert.
Created attachment 520 [details] PS file with 12 equal red text lines Here is a PS file with all red text content. Will be treated as blank (all white) by ps2epsi of 8.14.
Created attachment 521 [details] PS file with 12 text lines of different color This is hand-edited from the previous attachment "allred.ps", showing the effect of different colors. All text with red component 1 is treated like white in the preview (gray) bitmap, thus the bounding box is too small and the epsi file truncated.
Created attachment 522 [details] PS file with 12 text lines of different color Correction: the last two lines of attachment 521 [details] should read "RGB: 1 0 0"; here comes a correction.
Took a quick look with gs 8.51 - the submitted description of the bug is somewhat vague and incorrect. The problem here is that ghostscript doesn't seen to be able to calculate the bounding box parameter in the DSC comment, nor generate the embedded eps preview bitmap.
The incorrect bounding box or - in the extreme case - a totally missing ("blank") preview bitmap are what I realized first, too. But from my described experiments I concluded that these effects are *caused* by the misintepretation of red as white and ignoring the green and blue components. Thus an all-red image is seen as "blank." What is "vague" here?
(comment 7) - my comment 6 was mostly referring to comment 1 being misleading. The boundbox and preview are both calculated in lib/ps2epsi.ps.
I have verified that this problem still occurs in the latest build (r8191).
The actual problem is with the memory device (gsdevmem.c), when set to produce gray scale output (gdevmem.c & gdevm8.c). The device sets dev->color_info.num_components to 1, interestingly the memory device's mem_mapped_map_rgb_color method uses the num_components field to decide whether its getting an RGB or gray scale value from the interpreter. This seems odd to me, since it has already set num_components to 1, it will never see RGB values... Indeed, this is the problem, gxcmap.c determines that the device has set num_components to 1 and so, on receiving a RGB colour, only passes the red component to it (this too seems 'odd' behaviour to me, surely this should converrt to gray ?). Since we only ever see the red component, we can only ever use this for conversion to the palette (effectively gray scale). Whenever R=255 this means we set the gray value to 0, white, no matter what the other channel values. A simple fix in gsdevmem.c, gs_initialize_wordimagedevice, removing the code which sets the num_components field to 1 works for me, but this is not my area and I'm unsure what side-effects this might have. As this is not really a ps2epsi problem, but really a colour problem, or possibly a bug in the memory device, I'm re-assigning it to Ralph (having checked with him first).
Reproduced with r9999 on Ubuntu 9.04.
I'm starting work on this as part of the bounty program.
The first thing to do is to see if this is still a problem -- GPL Ghostscript 9.01 was released last week. 9.00 introduced an entirely new color pipeline (ICC profile based), and 9.01 includes some fixes/refinement of parts of it.
I confirmed that this bug still exists with the 9.01 release on my Debian system. I also confirmed that it works in 7.04, as indicated in the original report, on my Debian system.
Please can you confirm the command line and options you are using to reproduce this bug.
Ghostscript works correctly since v. 9.00. Current development version is also OK.