On Monday 02 March 2009 02:33:08 am Koji Otani wrote: snip > hvengel> Having taken a look at okular as an example of how applications > are coded I hvengel> see that they are interfacing to poppler through the > API defined in poppler- hvengel> qt4.h perhaps believing that this provides > a complete interface. Of course hvengel> the API for setting the output > profiles and for setting up the color hvengel> transforms is not exposed in > poppler-qt4.h. Okular basically does things in hvengel> about the same way > as qt4/demos/poppler_qt4viewer so this appears to be fairly hvengel> > typical of how many apps are/will be coded. > hvengel> > > There are 2 external APIs for poppler. They are Qt4 and Glib. > I mentioned only Glib in the previous mail, but as you wrote, it's > needed to add the API for setting profiles to Qt4. > And it's good to change sample programs to use this API.
I started looking at the Qt4 API since I work mostly in Qt and added wrapper functions for the CM API to the Qt4 Document class. This may not be the best place for this but I am just trying stuff at this point. But if Koji or someone else thinks these belong in another location let me know. I have also started working on making poppler_qt4viewer color management aware in that it should be able to use the X11 _ICC_PROFILE atoms if these exist. I have a preliminary version of this that is mostly working. Later on someone should also add similar code for Windows and OS/X. One issue I still have is that the transform is only being setup one time and it does not change if I move the app to another monitor (with a different _ICC_PROFILE atom) or change the atom on the current screen and then reopen the document. I have it setup to get the X11 atom and call the setDisplayProfile() wrapper when ever a document is opened. So I have to restart the app to get it to pickup the changed profile. I removed the "do only once" code from setupColorProfiles() but this did not fix the issue. Perhaps Koji or someone else more familiar with the code has some idea why this is happening. Also the current version of my X11 atom code may not work on a XRandR 1.2 machine (IE. using a XRandR 1.2 video driver). I will post patches once I have the code cleaned up and I have resolved the only once issue. I may even take a shot at adding some XRandR atom code. I don't have anyway to test this however but if someone had an XRanR 1.2 machine and wants to test this please let me know. The current X11 atom code has been tested on an xinerama machine and works other than the once only issue. I also noticed that setupColorProfiles() is being called from GfxState(). This is the reason that apps like okular are picking up the default profiles and using them. Watching what it does it appears that user apps only need to call setDisplayProfile() to setup the correct output profile as part of opening the document and setupColorProfiles() will happen automatically. Is this correct and is this how it should act? snip > If no display or output profile is specified, current code uses > littele cms's built in sRGB profile.(see GfxState.cc: line 305) OK I see it now. The actual logic to use the RGBProfile is on lines 1498 and 1499. I didn't see that since it was so isolated from where the main code for setting this stuff up is located. Perhaps this should be located in the area around line 305 so that it is near where all of the other code that sets up CM is located? I think this would make it easier to maintain. One more thing that probably needs to be looked at. The current code is setting up a simple cmsSetErrorHandler() but there is no change being made to the cmsErrorAction(). There are a significant number of non-compliant profiles in the wild. Marti Maria (the LCMS author) has told me that he has done random samples and perhaps 25% of the existing profiles are in some way non-compliant with the ICC standard (none of those were produced with any of the open source tools that can produce profiles) and perhaps 1% to 2% will cause LCMS to abort because of problems that are bad enough that it can not continue (using little endian numbers where the standard calls for big endian numbers is not uncommon and can cause lcms to abort). This means that applications opening profiles using lcms will on occasion terminate ungracefully unless additional steps beyond calling cmsSetErrorHandler() and cmsErrorAction() are taken to prevent this. The solution is rather ugly but I can supply some example code. It appears that lcms version 2 will be easier to deal with in this regard but it will not be available for some time. Hal _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
