<!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 Friday, May 13, 2011 12:20:20 AM Michael Sweet wrote: > On May 12, 2011, at 11:52 PM, Graeme Gill wrote: > > ... > > > >> So no, I don't want users printing targets from arbitrary applications > >> that have no notion of color management. Instead I want to see > >> applications that are specifically written to print targets, measure > >> them, and produce profiles that can be used by arbitrary applications. > > > > Nearly all existing color profiling tools assume that a normal > > test chart printing process can involve using a normal application > > (like Photoshop) to print the chart. Taking away this capability > > and not providing any other means of achieving this necessary > > step (never mind negating the possibility of application color > > matching on the assumption that there is no justification for it), > > flies in the face of reality. > > > > If this is the way Apple sees it, no wonder there are a lot > > of angry Color professionals out there. I certainly wouldn't > > want to see any of the Linux systems to go down this route. > > Please. I said: > > I don't want users printing targets from arbitrary applications that have > no notion of color management. > > Photoshop (and other professional graphics applications) definitely has a > notion of color management. Thus I would expect it (and other professional > graphics applications) to support printing target images. > > However, I would not expect a UI control in the regular print dialog to > enable a target (color management disabled) printing mode for, say, > Firefox which *can* print images but doesn't have any real notion of color > management. Actually Firefox has had some "notion of color management" since at least version 3.5 (It might have been a little earlier than 3.5). This is limited to monitors and the internal CMM is flawed and lacks support for ICC V4 profiles and profiles that use a LUT (unlike when Firefox was using LCMS). There are more and more open source apps that are CM aware although most of these are enharently graphical in nature. So we are seeing things like Blender (3D modeling program for animation and gaming) developement (V2.5) with some CM support. I wouldn't try to print a profiling target from Blender since I don't think it is a good fit for this purpose but there are many other open source apps that at the very least have some CM hooks/awareness ranging from web browsers and PDF readers to high end graphics software such as GIMP, Scribus and Blender. On the other hand if the print UI's "target printing mode", and perhaps some other "high end" CM, functionality required the calling app to ask for this to be visible to the user I think that we should be able to get most of the apps that are of interest for printing targets or doing app side CM (IE. GIMP, Kate, InkScape, CinePaint and so on) to add a call to turn these UI features on since it likely involves adding or modifying a single line of code if correctly designed. But this implies that we can get both a working print UI and app(s) that inable the advanced CM features part of the UI at the same time to have a working solution. This may be the difficult part since we don't have dirrect control over any of this stuff. Hal</body></html>