Am 04.10.08, 11:44 -0700 schrieb Hal V. Engel: > handle it at the application level (like today). The sad part about this is > that ghostscript already has some CM capabilities thanks to Graeme and the > ghostscript team is in the process of implementing complete support. A PDF > to > raster CUPS filter based on ghostscript instead of poppler would likely have > had full CM support long before most users systems had been converted to a > PDF > based printing work flow and all of these systems would have had CM by > default > at that point as part of the printing system. > > The real question is what do we do about it? I have also been in contact > with > the printing community about this and there seems to be little interest in > converting to ghostscript for either the CPD or the new CUPS pdftoraster > filter. In addition poppler is widely used in various viewers such as Evince > and Okular which means that the problem is more wide spread than just these > new printing work flows. It could very well be a good idea to try to work > with the poppler team to implement CM in the poppler library since this would > correct this issue across a wider range of situations for users. For some We have a real commitment from the Ghostscript community. So I would at the moment not solely focus to a non standard conforming pice of code. Some parts of the previous printing architecture discussion I must have missed. About a final decision for Poppler I would have to (re-)read. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org