[Openicc] Linux CM ideology... Print preview

[Hal V. Engel]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110207/be58fcf9/attachment.htm>