Hi Guys,
That's Marti Maria, lcms author.
I would be glad to know which functionality you miss in lcms2. I tried hard to make lcms2 complete enough to be a superset of lcms1 but is quite probably I left something.
Regarding icc34.h, I would avoid that because licensing issues and more importantly because portability issues. All yous should need is lcms2.h and maybe a couple of #defines for tag names. Again, please let me know about the individual problems you would have.
(specifically cmsReadRawTag and cmsWriteRawTag don't do what we want),
Ops, so I did something wrong. These functions were in the API to implement mscms and JDK APIs. Could you please elaborate what the issue is?
Thanks again for using lcms.
Best regards Marti.
El 04/06/2013 0:48, Detlef Riekenberg escribió:
Hans wrote on Monday, 3. June 2013 at 10:30
On Sun, 2013-06-02 at 22:49 +0200, Detlef Riekenberg wrote:
try2: import the unchanged icc34.h from the lcms (v1) dev. package. (Do we need to add a Wine LGPL licence header for icc34.h?)
The plan is to remove this include, when changing Wine to use the new getter/setter functions of lcms2 (After the release of Wine-1.6)
My plan was to switch to lcms2 soon *after* the release of Wine 1.6.
My plan was to find a way to increase the user experience and provide lcms2 support out of the box for the stable Wine release.
Alexandre, do you see a chance for lcms2 support for Wine-1.6 (out of the box)?
I studied the API some more and my conclusion is that while it doesn't have all we need (specifically cmsReadRawTag and cmsWriteRawTag don't do what we want),
rc1 for lcms2 v2.5 was just released: http://www.littlecms.com/lcms2-2.5rc1.tar.gz What does Wine need from lcms / for cmsReadRawTag and cmsWriteRawTag? I added lcms-user@lists.sourceforge.net for this mail.
we can avoid importing the icc34.h header.
Hans, you found a way to change Wine to use getter/setter functions while still linking to lcms v1 and than switch to lcms2? Great! Please confirm, that you think, that this is a working transition variant. (I must admit, that I didn't studied the lcms2 API deep enough).
I'm not in favor of adding temporary workarounds. If distributions want to drop support for lcms1 in 1.6 I'd suggest that they backport the patches.
Adding icc34.h is a variant for a transition to lcms2 without much effort, while knowing, that this work, but doesn't look beautiful.
Fletching out our mscms header (similar to a stripped down icc34.h), to allow our current code to compile without icc34.h and link to lcms2 is another possible transition variant.
Should we spend that time/effort, when we expect, that the added code is no longer needed after updating Wine to use the lcms2 getter/setter functions?