<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> On Monday, February 07, 2011 06:46:21 AM Leonard Rosenthol wrote: > On Mon, Feb 7, 2011 at 9:00 AM, Kai-Uwe Behrmann <ku.b@gmx.de> wrote: > > Am 07.02.11, 08:52 -0500 schrieb Leonard Rosenthol: > > On Sun, Feb 6, 2011 at 2:32 PM, Jan-Peter Homann > > > >> <homann@colormanagement.de>wrote: > >> As the printer profile is only defined through choosing the > >> media-setting > >> > >>> in the printing UI, a print preview is best implemented as function of > >>> the > >>> print UI (and not of an application creating complex PDF files) > >>> > >>> But how would the print UI get the "data" to be able to > >>> present/preview > >> > >> it? > >> Who generates the data? In what format? With what color settings? > > > > The print data is to be printed by the UI (CPD). A preview is already > > there, just without any colour management at the moment. Poppler currently does not have all of the hooks it needs in the Qt4 or GTK interface code to handle creating color managed rasters. I created a patch set to implement these hooks as well as updating the Qt4 example app to support CM for the display device about a year ago for the Qt4 wrapper. But the patches never made it into the main code base. The code needed to put these hooks in place is fairly simple as these things go (most of my code ended up in the example app) so I am not sure why this has not been done yet. Currently poppler will use sRGB as the default output RGB color space. To change this with the current poppler code programmers need to make calls to the base library which is normally hidden behind the widget set interface code which is where this should be exposed. That is a normal Qt4 app using poppler should only include and make calls to the Qt4 wrapper but since the Qt4 wrapper does not expose the CM functionality the calling app now needs to include the base headers and make calls to it if it needs to do CM. > > I guess CPD uses > > eigther Ghostscript or libpoppler to rasterise the preview. The CPD currently uses poppler to do the rasterizing. > > Which means the app generates a PDF and sends it to them for > rasterization...(which is fine with me) - To confirm things that is how it works. > but that seems to be NOT what > Jan-Peter wants... In some ways it makes things simpler since everything is now a compound document and all of the other cases are gone. For simple raster documents (a jpeg image for example) the app would simply imbed this into the PDF and pass it to the CPD for printing which would then hand it to CUPS. The CPD would render it for the display to do the preview and CUPS would render it for the printer. Since most to the widget sets support creating PDF files for output most of the things needed on the app side are already in place. It is mostly a matter of having everything wired up correctly. Hal </body></html>