[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[edmund ronald]

Robert,

 Gutenprint is not perfect, however it's pretty good. I've never met a
perfect piece of software.
 I would say that there is ample proof by now that if any precisely
defined functionality *needs* to be added to Gutenprint the developers
are able to do so.

 Of course, the word *needs* refers to user requests. So I would
analyze the software according to 3 indices:

1. -  Reliability: Can Gutenprint be deployed *by its users* in a way
such that it performs predictably on demand ?
2. -  Accessibility: Can Gutenprint be conveniently deployed  by a
significant fraction of its intended userbase ?
3. -  Features: Does Gutenprint embody the features necessary to
complete the job required by its intended users ?

I would say that at the moment 1. is still doubt because there is no
evidence of non-regression across versions, and no way to be sure of
the state of the system at a given point in time, but if evidence of
stability were brought then 1 would be easily assured. 2 desperately
needs to be worked on. 3 is ok, if one accepts that final renderings
should be created by domain experts who will be linearizing and
profiling with instrumentation, and thus final rendering quality is
not the responsibility of the core programmers.

So, I think that work on (2) accessibility will bring in domain-aware
users who will then indicate if necessary which features are necessary
and prioritize them for you. Achieving (1) reliability has never been
a problem in the open-source community although it appears to be
difficult in Redmond. As for point (3) features, having come so far,
it seems probable that the developers will be able to continue
matching the essential needs of print-makers, provided they keep
focused on core functionality. Writing parameter files for various
inks and papers is not part of the core job of programmers and should
be handed off as quickly as possible.


Edmund
>
> OK, this is actually helpful here -- the key being that you believe
> the core driver does have the necessary facilities, and we have to
> figure out how to expose them appropriately.  Thanks.
>
>
> I will see what I can do with this, but I don't think it can be solved
> overnight.
>
>
>    As you and others have pointed out, profiles and device links can
>    iron out a lot of issues. It's really getting necessary for users
>    to be let loose on this thing and deal themselves with inks and
>    linearisation, rather than spending forever deciding which arcane
>    feature should be buried in the C code at the next revision.
>