Sorry if this bug has already been reported before, but I could not find any similar report in the tracker. Using Ghostscript to convert a b&w eps to png, the png gets a background color of 254,254,254 instead of 255,255,255. Calling command: gswin32c -q -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pngalpha - dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r300x300" -g79x42 - sOutputFile=test.png l2r_0001.eps Using -sDEVICE=png16m gives correct white color. You can download the eps from http://freenet-homepage.de/wh_ew/test/ click on "generated eps picture" (The bug was first experienced calling Ghostscript via ImageMagick's "convert".)
This problem is, in part, the caused by your PNG tools that ignore transparency channel in the PNG image. You can use png device without any perceived loss functionality. On the Ghostscript side, pngalpha fills the background with an almost white and transparent color. I cannot figure out why it was done this way and what's wrong with using white transparent color. See pngalpha_fill_rectangle() function for details. The bug report is reassigned to the author of the pngalpha patch, rev. 3705. Customer field is cleared because it's reserved for commercial licensees.
Using "full white transparent" gives the same pixel value as gx_no_color_index. From memory, this caused problems, hence the pngalpha device uses almost white instead. I would need to test it to see if ghostscript allows you to set a pixel value to gx_no_color_index. The current behaviour shouldn't affect the final render, because the pixels are transparent, and so should take on the colour of the background. There will only be a problem if the final render is buggy and doesn't recognised transparent pixels. One possible kludge would be to redefine the copy page routine to convert the untouched pixels to full white transprent at the end.
At Russell's suggestion, I've changed the background color from FEFEFEFF to FFFFFFFF, which seems to work. r8846.