[argyllcms] Re: Argyllcms 1.0.1 packaged in fedora-devel
- From: "Hal V. Engel" <hvengel@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 27 Jul 2008 14:18:30 -0700
On Sunday 27 July 2008 12:44:33 pm Frederic Crozat wrote:
> On Sun, Jul 27, 2008 at 9:15 PM, Hal V. Engel <hvengel@xxxxxxxxxxx> wrote:
> > On Sunday 27 July 2008 11:25:32 am Frederic Crozat wrote:
> >> On Sun, Jul 27, 2008 at 8:11 PM, Hal V. Engel <hvengel@xxxxxxxxxxx>
> >> wrote:
snip
> > I would much rather that there was a set of
> > shared libraries with a stable API but that is not the current situation
> > and there is nothing I an do about it other than figure out how to work
> > my way around it.
>
> The job of a distribution is not to split appart all kind of software
> and rewrite them from scratch
> just because they are not in the best form we think they should.
I totally agree. That was part of my point and it would be unrealistic for me
or anyone else to expect the distros would do this. Before I can use the
ArgyllCMS libraries in any other way they have to be available in a form that
using them as shared libraries makes sense. This is currently not the case.
This is not an issue that belongs to the distros but it is one that affects
them.
>
> My teasing was more to point LProf has its own set of issues ;)
Yes I know. But you did pick the wrong example since lcms/LProf was an almost
exact comparison to libusb/ArgyllCMS. But I think it was worth while pointing
out why the ArgyllCMS/Lprof and libusb/ArgyllCMS cases are much different and
not comparable.
snip
>> If I provide you with a patch can you make it part of your distro(s)?
>
> Well, I don't know what issues your patches would fix, why it was
> refused upstream (Graeme libusb
> patch was not refused upstream, there was just lack of maintainance on
> libusb for years)
Marti is concerned that if he adds this API extension that he will be sued by
Apple in spite of the fact that Apple has never taken legal action against
anyone else who has similar functionality in their code and there are many
applications that do this some of them from companies with very deep pockets
(X-Rite and ColorVision among others) (I am not advocating that Apple sue
anyone over this no matter how deep their pockets only that are are way more
attracive targets for this than Marti).
What is fixed - see next section.
> and if it could
> cause regression on other software (first patch from Graeme was
> causing regression on some logitech keyboard,
> which is why I had to remove it).
There is an existing API for adding tag data to profiles. My code extends
this to add support for VCGT data (so it adds a new tag to the list of
supported tags). All of the existing calls are unchanged and the code paths
for adding the existing tags are unaltered. It should not cause any
regressions and existing code should continue to work although it may need to
be recompiled.
At this point I don't have a patch but I will need to create one soon since I
am currently using lcms 1.16 as a base and I will need to port this to lcms
1.17 at some point. Having a diff relative to 1.16 will help with that
porting effort. Actually I would expect a patch based on a 1.16 diff would
apply to 1.17 fairly cleanly.
I think there is also a patch against 1.14 or 1.15 that was part of xcalib
that extended the API for reading tags to include VCGT data that might also be
useful to someone (I don't need it) that would make for a more complete VCGT
functionality if it were paired with my changes.
>
> But I'm not sure this mailing list is the best place to discuss this.
> Maybe openicc ?
Perhaps or maybe the lcms-users list. Actually I vote for the lcms-users
list. That way Marti will see what is going on. I will prepare a patch for
1.17 since most distros are now using 1.17 and I will let you know when it is
ready off list. This will likely take a few weeks. At that point we can
decide if this needs any additional public comment.
Hal
Other related posts:
