Summary: | pngalpha device doesn't write full white background | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Wilfried Hennings <wh_ng> |
Component: | Other Driver | Assignee: | Russell Lang <gsview> |
Status: | NOTIFIED FIXED | ||
Severity: | major | ||
Priority: | P4 | ||
Version: | 8.62 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- |
Description
Wilfried Hennings
2008-07-04 02:04:42 UTC
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. |