If it doesn't make sense, then there's no need to accept it. I'll discuss the access of internals with the author of LCMS.c
However for the tag/reading writing yes the Kodak lib allowed you to manipulate this as raw data, but the problem is that following this model, probably by design, the same is exposed at the Java API level, so we need to support raw byte access. And I don't see why both approaches can't co-exist in lcms, although adding the raw approach would be a new API. -phil. Marti.Maria wrote: > > Hi Phil, > > Thanks for the patch. > > I was, however, wondering why you need this patch since the > functionality to modify tags is already in the library. And after > inspecting your LCMS.c module, I can see the author is doing heavy use > of undocumented low-level functions. > > Accessing things like the LPLCMSICCPROFILE structure instead of using > the cmsHPROFILE handle is not a good choice > because it breaks compatibility. This code is not going to work with > lcms2.0, for example. All the function pointers in this > struct (read, seek and so) are supposed to be lcms internals, and this > is the reason why you need the patch, you are accessing > the tags in the hard way, doing a seek and then reading the tag data > *directly* from the ICC file. > > I can understand why you do it this way instead of using cmsReadXXX(), > you need the raw, uncooked data because the > previous cmm did work on such way. On the other hand, lcms does some > processing and converts the profile data to > intermediate objects, so it is easier for the user. One example may be > the LUT structure. > > Unfortunately, both approaches can't coexist. Using lcms logic, you read > and write lcms objects and the library does all work > on parsing and serializing those objects. To read tags, use > cmsRead<whatever>(), to set and modify tags, use cmsAddTag(). > This works very well, allows you to edit profiles and is fully > qualified. For editing the profile as a RAW file you can use lcms > internals, but this may (and certainly is going to) change across releases. > > Kind Regards > Marti > > > > > > > Phil Race wrote: >> Hi, >> >> OpenJDK uses little cms. But in order to pass TCK (compatibility >> compliance needed to call >> it Java), littlecms needed minor modifications to support API to write >> tagged data elements. >> >> http://cr.openjdk.java.net/~prr/littlecms/ >> >> Can these be pushed into 1.18 by the maintainers, before it goes >> final, so we can more >> easily keep in sync with the latest ? NOT the new file LCMS.c, just >> the small mods to >> lcms.h and cmsio0.c >> >> I think it may have been RedHat that created the original version of >> this patch >> and its been used in this form in the "6-open" release that's shipping >> on Redhat now. >> >> -Phil. >> >> ------------------------------------------------------------------------------ >> >> >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Lcms-user mailing list >> Lcms-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/lcms-user >> >> >> > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
