<!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 21, 2011 01:18:09 PM Alastair M. Robinson wrote: > Hi :) > > On 21/02/11 19:30, Chris Murphy wrote: > > Why does it seem necessary? You're saying poppler would need to render to > > sRGB and then do a hand off to what> > > > > to do the conversion to CMYK? > > We're talking about the Poppler-based pdftoraster filter that will be > part of Ubuntu Natty. Pdftoraster uses Poppler to rasterize the PDF. > > If the printer's profile is RGB, then Pdftoraster asks Poppler to render > directly to the printer's profile (how much notice Poppler takes of that > request I'm not yet sure!). I tested some time ago using a modified version of the Qt4 demo app that comes with poppler. I added code to grab the ICC_PROFILE X11 atom when a file is opened and then called poppler to set that as the destination profile. I found that if I set the atom to a test profile that swaped the red and green channels and put this in the X11 ICC_PROIFLE atom that poppler was in fact using the profile since the colors were very messed up which is what should have happened if the test profile was being used. If I changed the profile in the X11 atom to a normal RGB profile and opened another PDF in the test app it would still use the test profile and not the profile in the X11 atom. I had trace code in the test app that would dump information about what was happening to the console and it was clearly picking up the new profile and making the call to poppler to change the profile. If I restarted the test app it would get the correct profile atom and the PDF would be correctly rendered. So poppler does take notice of the request the first time but not on subsequent calls to change the output profile. > > If the printer's profile is CMYK then pdftoraster asks Poppler to use > its default rendering (i.e. to sRGB), then pdftoraster handles the > conversion to CMYK. > > > The issue is both the source space L* going to 0, compared to the > > destination space L* going to something more than zero, and the lack of > > Black Point Compensation to use with RelCol. When both of these are > > true, Perceptual rendering should be used. > > In this context BPC would be available, but I don't see any reason not > to use Perceptual when converting a flat sRGB raster to a printer's > profile? > > > Even if a printer is described by an RGB output device profile, the L* > > will not go to 0 for any real device with a properly built profile. So > > the issue of intent is the same. Default rendering to print space needs > > to be either RelCol+BPC or Perceptual. > > Agreed, however, when the printer's profile is RGB, Pdftoraster doesn't > need to do its own conversion, so rendering intent then becomes a > Poppler issue. > > All the best > -- > Alastair M. Robinson > _______________________________________________ > openicc mailing list > openicc@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/openicc </body></html>